[antlr-interest] Suggestion: syntactic sugar for generateAmbi gWarnings = false;

[mzukowski at yci.com]

Macros that are aware of the syntax of the language so they aren't just
processing strings.  In antlr they could inspect their subrule and reason
about lookahead sets, for instance.

http://www.ai.mit.edu/~jrb/jse/
http://www.brics.dk/metafront/

Monty

-----Original Message-----
From: Matt Benson [mailto:gudnabrsam at yahoo.com] 
Sent: Monday, June 16, 2003 11:07 AM
To: antlr-interest at yahoogroups.com
Subject: RE: [antlr-interest] Suggestion: syntactic sugar for generateAmbi
gWarnings = false;


Monty, since I'm ignorant, will you explain that idea?

-Matt

--- mzukowski at yci.com wrote:
> Seems like a good case for adding syntactic macros
> to ANTLR .g notation ;)
> 
> Monty
> 
> -----Original Message-----
> From: uprightness_of_character [mailto:andrei at metalanguage.com]
> Sent: Saturday, June 14, 2003 12:30 AM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Suggestion: syntactic
> sugar for
> generateAmbigWarnings = false;
> 
> 
> I have a number of rules in which the first rule
> that matches is the 
> one that's needed, and there's a final match for
> "everything else". In 
> a nutshell => generateAmbigWarnings = false. 
> 
> For example, consider you write a C-style
> preprocessor, and you 
> generate the code to get a macro argument.
> 
> The idea is, you need to read up to the first comma,
> but if there are 
> parentheses, curly braces, or square brackets, you
> will pair them 
> properly (commas are allowed inside). For example,
> "1 (2, a) 3" would 
> be a proper argument. 
> 
> I came up with the following rule:
> 
> fetch_macro_argument
>     : 
>     (
>         balanced_pars 
>         | balanced_curlz
>         | balanced_squares
>         | tok:~(COMMA | LPAR | LCURL | LSQUARE)
>     )*
>     ;
>     
> So, a macro argument can consist of a mixture of the
> following items - 
> any set of balanced parens, any set of balanced
> curly braces, any set 
> of balanced square brackets, or anything else that's
> not a comma.
> 
> Now I could have written this as:
> 
> fetch_macro_argument
>     : 
>     (options { generateAmbigWarnings = false; } 
>         : balanced_pars 
>         | balanced_curlz
>         | balanced_squares
>         | tok:~COMMA)
>     )*
>     ;
> 
> (Let me make a remark en passent, the most efficient
> code is actually 
> generated for the following:
> 
> fetch_macro_argument
>     : 
>     (options { generateAmbigWarnings = false; } 
>         : balanced_pars 
>         | balanced_curlz
>         | balanced_squares
>         | { LA(1) != COMMA}? tok:.)
>     )*
>     ;
> 
> But that's subject of another discussion.)
> 
> So anyway, I have two variants to choose from, and
> they are both more 
> verbose than I'd like. I'd like to propose defining
> the operator "||" 
> (as opposed to "|") to combine "short-circuit" rules
> - rules that obey 
> the "first wins" policy.
> 
> The notation is nicely consistent with the semantics
> of the "||" 
> operator, where the first condition that's true
> stops evaluation. 
> Also, the precedence would be lower that that of
> "||" - and that makes 
> sense for the grammar, because most of the time you
> want to match some 
> discriminating rules, followed by a more general
> one.
> 
> With that hypothetical operator I could write my
> rule simply as:
> 
> fetch_macro_argument
>     : 
>     (
>         balanced_pars 
>         | balanced_curlz
>         | balanced_squares
>         || tok:~COMMA
>     )*
>     ;
> 
> Whaddaya think?
> 
> 
> Andrei
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/ 
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/ 
> 
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/