Parse trees and syntax

[Hans-Dieter Dreier]

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------13F1A99FBFA04C159A283A39
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Shall we write a text parser/deparser immediately?  That is, a converter
> to the USSID (Ultra Source Syntax Independent Distribution =) ), or just
> go straight to the UPPID (Ultra Program Platform Independent
> Distribution) at first?

What do you mean by  "Program Platform Independent"?

>
>
> >   ParseNode
> >     Expression
> >   ...
>
> This is a very C-ish tree.
>
> For example, the logical and bitwise operators.  I think you should
> really have two types, boolean and bitpattern, and an "and" on both of
> those types.  If you're dealing with integers, bitwise operations are
> undefined if you want to hide the implementation of integers.  Things
> like two's complement addition would still be available on bitpatterns
> as that is a bitpattern operation.

I'd omit most of it for a start. Just implement the very minimum.

> Also, you've included n-ary subscript, presumably for arrays.  I feel
> that we should remove this sort of prefential treatment for special
> types.  The advantage is that user-defined types can use this notation.
> This can be done in two ways.

Do we need it for a start? I don't think so. Can it be fitted in later? Most
likely.

> Later we can write a translator from our old tree format to the new tree
> format.
>
> But I have a more radical way up my sleeve which I'm still thinking
> about (and would take top long to put into words at this stage).
>
> > in if( X ) and also a pointer to a statement Y in if( X ){ Y; }
> > Statements would have pointers to the next statement to be executed
> > after itself.  What does everyone think about this layout?
>
> I tend you think a block would have a list of statements rather than a
> linked list structure.  I.e. the parse tree can have a potentially
> unlimited number of children.  So basically the children are any
> sequence rather than an inline linked list which implements the
> sequence.

These concepts are equivalent. Having the linked list collapsed conserves
memory in the parse tree but probably needs more memory during construction,
and is not so easy to change at edit time as a linked list. If a statement
would have a pointer to the next statement, that would effectively turn the
statement delimiter into an infix operator (like +), which would require no
special treatment / this is why I'd prefer a linked list (or rather: the
same format as any other infix op).

> Also, you haven't put any modularisation features in yet.  Perhaps this
> was intentional, but we can't really bootstrap without modularisation.

Why not? I don't think a minimalistic compiler need to be so big. I admit we
would have to tackle this pretty soon.



--------------13F1A99FBFA04C159A283A39
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans-Dieter Dreier
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Hans-Dieter Dreier
n:              Dreier;Hans-Dieter
email;internet: Ursula.Dreier@ruhr-uni-bochum.de
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------13F1A99FBFA04C159A283A39--