[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