[antlr-interest] Re: Semantic predicates that aren't & hoisting
John D. Mitchell
johnm-antlr at non.net
Fri Mar 11 12:48:01 PST 2005
>>>>> "David" == David Jung <jungdl at ornl.gov> writes:
[...]
>> Well, if you're going that far, why not go whole hog to e.g., Lisp or
>> even a pure functional language? You'll get a much cleaner, more
>> consistent, and (mostly likely) a more powerful solution.
> The language has some functional features already - functions can be
> marked 'pure' which disallows side-effects. That also means that pure
> functions with const args can be computed at compile time and result in
> further const values. Types, being first-class values, are just literals
> assigned to variables. If the variables are const then static type
> checking can be performed on the type, otherwise the types are dynamic
> (but everything is still strongly typed - with the exception of the 'any'
> type). Hence, pure functions that operate on types and are called with
> const types in initializers allow something like Java/C++
> generics/templates (strong, static, parameterized types). If such a
> function isn't pure then the type is dynamically generated instead (using
> java.lang.reflect).
Ah, the kitchen sink approach. :-? :-)
[...]
> program : expr EOF ; expr : ifExpr | addExpr ; ifExpr : "if" expr "then"
> expr ; addExpr : condExpr ( (PLUS | MINUS) expr )? ; condExpr: callExpr (
> GTHAN expr )? ; callExpr : primaryExpr ( LPAREN RPAREN )? ; primaryExpr :
> exprList | constant | IDENT ; exprList : LCURLY ( exprListOrStmt )*
> RCURLY ; exprListOrStmt : (RCURLY)=>exprList | expr SEMI ;
The syntactic predicate doesn't make sense -- it should be LCURLY, right?
The use of RCURLY will never match the (well-formed) input and so the
recursive match of exprList is forced to go through the *second*
alternative (which requires the semi at the end).
Have fun,
John
More information about the antlr-interest
mailing list