Re: C Compiler in C++

>The C declarators reverse this. They put an already-known type above
>the type constructor and the name of the to-be-declared type or
>variable below. Whether this is good or bad is bait for a major flame
>war.


>But this inverted syntax cannot be applied consistently, because a
>tree node, while having as many children as you like, can have only
>one parent. So when you need to construct a new type out of more than
>one already-known type or value, it won't work. The only type
>constructor in C that uses this syntax style consistently is the
>pointer declarator, which only needs one already-know construct,
>namely, the referent type of the being-declared pointer type.


I guess I use a grammar where the declaration has a base, which is a
base-type (int, float, ...) or another declaration, and a declarator
(array, pointer, call). This lets declarations reduce in the correct order
for one-pass name resolution. I represent type by a linear thread through
the declaration, which which does run up through the declarator and down
through the base.


For example,
int a = 0, *b = malloc(2*sizeof *b), c[2];


looks something like the following (with nodes numbered in brackets
underneath).


DCLR
[15]
/ \
INIT []
[11] [14]
/ \ / \
DCLR \ DEF(c) \
[9] \ [12] EXPR(2)
/ \ \ [13]
/ * \
/ [8] EXPR(2*sizeof *b))
/ \ [10]
INIT DEF(b)
[6] [7]
/ \
/ EXPR(0)
DCLR [5]
[4]
/ \
BASE DEF(a)
[2] [3]
/
INT
  [1]


The reduction of [4] declares (a), [9] declares b before [9] uses it,
[15] declares (c).


Type threads run through the interesting nodes from DEF() up past DCLR,
terminating down the left side past BASE.


[3]->[1] for (a),
[7]->[8]->[1] for (*b),
[12]->[14]->[1] for (c[]).


This works. There may well be better ways.


--
mac the naïf

Return to the comp.compilers page.
Search the comp.compilers archives again.