|compiler and metadata, request opinions... email@example.com (cr88192) (2009-04-22)|
|Re: compiler and metadata, request opinions... DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-04-24)|
|Re: compiler and metadata, request opinions... firstname.lastname@example.org (cr88192) (2009-04-25)|
|Re: compiler and metadata, request opinions... DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-04-27)|
|Re: compiler and metadata, request opinions... email@example.com (cr88192) (2009-04-28)|
|Date:||Tue, 28 Apr 2009 22:46:54 -0700|
|References:||09-04-051 09-04-059 09-04-064 09-04-071|
|Posted-Date:||29 Apr 2009 05:16:36 EDT|
"Hans-Peter Diettrich" <DrDiettrich1@aol.com> wrote in message
> cr88192 schrieb:
>>> I'd use different frontends (parser...) for each language, each building
>>> an canonical AST. Where "canonical" means that the AST is understood by
>>> all following stages.
>> writing 3 parsers would mean maintaining 3 parsers, which is unecessary
>> since most of the syntax is common between the languages...
> Parsers usually have to deal with semantics (for disambiguation...) as
> well, in detail with context sensitive C-ish languages.
My parser does close to the minimum required to get the code parsed
(it handles declarations and typedefs, but little beyond
this). everything else goes into the AST, which in my case is
represented in an XML-based form (fairly similar to DOM). (I actually
prefer context-independent ASTs, but C can't be parsed in a
a lot of the rest of the issues (semantics, ...) are handled by the upper
compiler, which convert the AST's into the IL (an RPN-based IL I call
RPNIL). the ASTs recieved by the upper compiler are still mostly language
specific (apart from the large amount of comon features which exist between
the languages involved), and the upper compiler is aware which input
language is being used.
RPNIL no longer knows or cares what the input language is, as by the this
point the semantics are presumably normalized...
Return to the
Search the comp.compilers archives again.