RE: [Opencxx-users] design sketches

[Stefan S. <sse...@ar...>]

> From: SF Markus Elfring [mailto:el...@us...]
> Sent: October 22, 2004 15:31

> > As in the Clouseau API identifiers (strings) are helt by value
> > and not by reference, you can't simply modify the parse tree
> > *in place*. What Grzegorz and I discussed a while ago was a way
> > to access (and that includes modify) the underlaying structure.
> 
> Which identifiers do you mean? Is it needed in that design 
> that they behave as value objects? Why not in OpenC++?
> Are you concerned about the consequences on memory consumption?

no, I'm interested in in-place code manipulation, i.e. modifications
to the AST that propagate automagically down to the underlaying parse
tree / source code buffer.

> > > Do you think about a concrete class hierarchy for more 
> introspection?
> > 
> > I don't understand the question. As I said earlier, both the parse
> > tree as well as the symbol table (and assorted analyzers) provide
> > the means to introspect the code. the AST API would simply be
> > a convenient high level view on these two. There isn't any more
> > information that is not already available through the PTree and
> > the SymbolTable modules.
> 
> I assume that your understanding of a AST/ASG API might 
> result in a variant of a Clouseau API.

well, all AST APIs will have many similarities as they all model
the same domain.

> I think that you will need a couple of related classes for 
> your implementation. Have any plans become concrete enough so 
> that more details can be disussed?

not yet, no. My immediate goal is to finish the SymbolTable work
at least down to a degree that allows the parser to completely
disambiguate its input.

> Is the topic "token decoration" also on your approach?

Conceptually yes, as the work to be done is the same:
Get a token from the lexer, and if it is an 'Identifier' find out
whether it is a known symbol. If it is, choose the production rule
according to the symbol type. That's what all disambiguation is
about, no matter whether you describe it as 'token decoration' or
in different terms. I haven't looked closely into the keystone
parser but since it's written more formally in terms of bison,
I think a formal on-the-fly decoration of the incoming token
is a good approach. In our case the parser is hand-written so
there is no need to do it exactly the same way.

> > > Would you like to apply the design patterns "adaptor" or 
> > > "facade" like it is done in Keystone?

[...]

ok, yes, the goal being to decouple the submodules as well as
possible. Using a single entry point for the parser to access
the SymbolTable module looks like a good idea.

Regards,
		Stefan