|Should this be done in Bison or by post-processing of the AST? email@example.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? firstname.lastname@example.org (Joachim Durchholz) (2007-11-09)|
|Re: Should this be done in Bison or by post-processing of the AST? email@example.com (eyeris) (2007-11-12)|
|From:||Joachim Durchholz <firstname.lastname@example.org>|
|Date:||Fri, 09 Nov 2007 15:18:14 +0100|
|Organization:||1&1 Internet AG|
|Posted-Date:||10 Nov 2007 16:35:31 EST|
> 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.
[some_name: if ...]
lots of text with possibly unclosed [if]s
[end some_name] -- implicitly closes any unclosed constructs
Just a suggestion.
Return to the
Search the comp.compilers archives again.