Java Doc for GroovyRecognizer.java in  » Scripting » groovy-1.0 » org » codehaus » groovy » antlr » parser » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Also, if the expression starts with a closure, it needs to have an explicit parameter list, in order to avoid the appearance of a compound statement. This is a hard error.

These rules are different from Java's "dumb expression" restriction. Unlike Java, Groovy blocks can end with arbitrary (even dumb) expressions, as a consequence of optional 'return' and 'continue' tokens.

To make the programmer's intention clear, a leading closure must have an explicit parameter list, and must not follow a previous statement separated only by newlines.

AST effect: Create a separate Type/Var tree for each var in the var list. Must be guarded, as in (declarationStart) => declaration.

(In the absence of explicit method-call parens, we assume a capitalized name is a type name. Yes, this is a little hacky. Alternatives are to complicate the declaration or command syntaxes, or to have the parser query the symbol table. Parse-time queries are evil. And we want both {String x} and {println x}. So we need a syntactic razor-edge to slip between 'println' and 'String'.) TODO* The declarationStart production needs to be strengthened to recognize things like {List foo}. Right now it only knows how to skip square brackets after the type, not angle brackets. This probably turns out to be tricky because of >> vs. > >. If so, just put a TODO comment in.

An expression statement can also be a command, which is a simple method call in which the outermost parentheses are omitted.

Certain "suspicious" looking forms are flagged for the user to disambiguate.

Returned AST is [INDEX_OP, indexee, ELIST].

A map constructor is an argument list enclosed in square brackets, with labels everywhere, except on spread arguments, which stand for whole maps spliced in. A colon alone between the brackets also forces the expression to be an empty map constructor. Examples: [:], [a:1], [a:1,b:2], [a:1,*:m1,b:2], [*:m1,*:m2] (The m1, m2 must be a map or null.) Values associated with identical keys overwrite from left to right: [a:1,a:2] === [a:2]

Some malformed constructor expressions are not detected in the parser, but in a post-pass. Bad examples: [1,b:2], [a:1,2], [:1]. (Note that method call arguments, by contrast, can be a mix of keyworded and non-keyworded arguments.)

If the methodCallArgs are absent, it is a property reference. If there is no property, it is treated as a field reference, but never a method reference.

Arguments in the (...) can be labeled, and the appended block can be labeled also. If there is a mix of unlabeled and labeled arguments, all the labeled arguments must follow the unlabeled arguments, except that the closure (labeled or not) is always a separate final argument. Labeled arguments are collected up and passed as a single argument to a formal of type Map.

Therefore, f(x,y, a:p, b:q) {s} is equivalent in all ways to f(x,y, [a:p,b:q], {s}). Spread arguments of sequence type count as unlabeled arguments, while spread arguments of map type count as labeled arguments. (This distinction must sometimes be checked dynamically.) A plain unlabeled argument is allowed to match a trailing Map or Closure argument: f(x, a:p) {s} === f(*[ x, [a:p], {s} ])