Re: [Opencxx-users] test build failure: Ubuntu Dapper Amd64/libtool

[Stefan S. <se...@sy...>]

skaller wrote:
> On Mon, 2006-07-24 at 14:14 -0400, Stefan Seefeld wrote:
>> skaller wrote:
> 
>> Right. Elsa uses some interesting alternative approach (retaining all possible
>> parse subtrees until at a later stage of semantic analysis the wrong ones can
>> be eliminated).
> 
> Actually it prunes them as it goes, it applies a whole lot
> of nasty heuristics to try to prune branches ASAP. 

Right, ASAP. Some disambiguation requires type analysis, and as this is done
in a phase following parsing, the AST resulting from parsing still may contain
alternatives (see http://www.cs.berkeley.edu/~smcpeak/elkhound/sources/elsa/doc/design.html#ast_build).

>> However, Synopsis, given its history, shares with OpenC++ one particular feature:
>> the input data are fully preserved, thus making it particularly easy to write
>> a 'minimally intrusive' and non-lossy source-to-source translator, since, after
>> local modifications are applied to the parse tree / buffer, the latter is
>> reserialized to a file.
> 
> In other words it generates an actual parse tree, rather than
> an abstract syntax tree?

Exactly. OpenC++ generates a parse tree, and does everything else in a secondary
pass. However, it doesn't preserve alternatives resulting from ambiguous syntax,
but rather uses some heuristics to 'guess' the right interpretation of the syntax...
which may fail.

Synopsis on the other hand does construct a symbol table during parsing, and thus
can disambiguate on-the-fly (much like g++ actually).
The result is still a parse tree (using a cleaned up and enhanced version of OpenC++'s
own PTree design), and all higher level representations (such as AST) are then built
by traversing the parse tree, symbol table, and type repository (once completed).

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...