Re: Should this be done in Bison or by post-processing of the AST?

Joachim Durchholz <jo@durchholz.org>
Fri, 09 Nov 2007 15:18:14 +0100

          From comp.compilers
Related articles
Should this be done in Bison or by post-processing of the AST? drewpvogel@gmail.com (eyeris) (2007-11-08)
Re: Should this be done in Bison or by post-processing of the AST? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-11-09)
Re: Should this be done in Bison or by post-processing of the AST? jo@durchholz.org (Joachim Durchholz) (2007-11-09)
Re: Should this be done in Bison or by post-processing of the AST? drewpvogel@gmail.com (eyeris) (2007-11-12)
| List of all articles for this month |
From: Joachim Durchholz <jo@durchholz.org>
Newsgroups: comp.compilers
Date: Fri, 09 Nov 2007 15:18:14 +0100
Organization: 1&1 Internet AG
References: 07-11-028
Keywords: parse, AST
Posted-Date: 10 Nov 2007 16:35:31 EST

eyeris schrieb:
> My parser deals with this example just fine. However this language has
> a [endif all] command that closes all open [if] blocks.


Maybe redefining the problem is a good approach.
I'd suggest dropping [endif all]. With it, putting a piece of text
between [then] and [else] means you have to scan it for any occurrences
of [endif all], and replace that [endif all] with the proper number of
[endif]s. If your language has an [include 'filename'] construct, using
[endif all] would be outright dangerous.


You could use "named statements" to close multiple statements. E.g.
something like


      [some_name: if ...]
          lots of text with possibly unclosed [if]s
      [end some_name] -- implicitly closes any unclosed constructs


Just a suggestion.


Regards,
Jo

Post a followup to this message

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