Re: RM and abstract syntax trees

On Oct 31, 8:57 pm, David BL <davi..._at_iinet.net.au> wrote:
> On Nov 1, 12:36 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
>
>
>
> > On Oct 31, 6:20 pm, David BL <davi..._at_iinet.net.au> wrote:
> > > On Oct 31, 11:55 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
>
> > > > If we are using nested structures, then the structure itself
> > > > provides the integrity.
>
> > > Exactly, that's what I was trying to say. My somewhat vague notion
> > > is that the RM representation loses that simplicity because it is *too
> > > flexible* - hence the need for complex integrity constraints
>
> > Sure.
>
> > It is a general engineering truism that a solution designed for
> > some specific narrow purpose may be better *at that purpose*
> > than something general purpose.
>
> > So it's no particular surprise that a structure of heterogeneous
> > trees will model an application (parsing) of heterogeneous
> > trees.
>
> > We might prefer a general solution still, for general reasons.
> > And I think we will also find that at least some queries are
> > going to be easier with a relational approach even so.
> > Off the top of my head ... oh, I dunno. Dump all the symbol
> > names or something.
>
> If it's indeed true that RM is too flexible for certain sub-problems,

That would not be how I would put it.

> it would seem that from the perspective of RM those sub-problems where
> better niche solutions exist should be treated as opaque domain types.

That's how I would foresee union types working within the RM. However as I mentioned lately I have no confidence that this is actually an approach with any value.

Your analysis of this problem domain, while definitely the right idea, is not yet the right execution. What needs to happen is the whole enchilada, scanning, parsing, semantic analysis, and either interpretation or compilation, needs to be done both ways. I have always imagined comparing the job in ML and in a relational language I am working on.

Marshall Received on Thu Nov 01 2007 - 07:21:33 CET