[antlr-interest] [C target] [3.1.1] Deriving imaginary nodes from real tokens

Sven Van Echelpoel sven.van.echelpoel at empolis.com
Fri Dec 12 04:52:04 PST 2008


On Sat, 2008-12-13 at 00:09 +1300, Gavin Lambert wrote:
> At 23:49 12/12/2008, Sven Van Echelpoel wrote:
>  >Indeed it does, but the single argument case can never be a
>  >text, it is always a token, at least if I understand this
>  >correctly.
> 
> No, I believe you are mistaken there.
> 
>    -> FOO["bar"]
>    -> FOO[$bar]
>    -> FOO[$bar, "baz"]
>    -> FOO[FigureSomethingOut($bar, $baz)]
>    -> FOO
> 
> All of these are perfectly valid ANTLR syntax, and only the first, 
> third, and last cases are obvious to ANTLR.  

OK, I'm willing to believe you there, but this is the table I found on
page 189 of the ANTLR 3 book:

Imaginary Node Constructor Tree Adapter Invocation
T                          adaptor.create(T, "T" )
T []                       adaptor.create(T, "T" )
T [token-ref ]             adaptor.create(T, token-ref )
T [token-ref, "text"]      adaptor.create(T, token-ref, "text" )

It doesn't mention 1 and 4 (your list above), although 4 would work if a
token was returned. 

I just reasoned from the book and, as I did not try to generate Java
(beyond a toy application or two), I assumed that what was in the book
was correct. Still, no harm done, bar[ $b, "" ] works for me.

> 
>  >There are in fact two templates in AST.stg. There is one that
>  >does the right thing when a single argument is passed, while
>  >the other (which is unfortunately the one that gets invoked
>  >in my case) does not.
> 
> I haven't actually looked at the templates myself, so I'm just 
> going by what you've posted earlier, but this is how it looks to 
> me:
> 
> Template "createImaginaryNode":
>    - if two parameters, call createTypeTokenText, passing in a 
> type, a token, and some text.
>    - if one parameter, call createTypeText, passing in a type and 
> some text.
>    - if no parameters, call createTypeText, passing in a type and 
> the stringified type.
> 
> This template ought to (always!) be called by rewrites of the 
> forms shown above.
> 
> Template "createRewriteNodeFromElement":
>    - if two parameters, call createTypeTokenText, passing in a 
> type, a token, and some text.
>    - if one parameter, call createTypeToken, passing in a type and 
> a token.
>    - if no parameters, insert it directly.
> 
> This template ought to be called by rewrites of the following 
> forms:
>    -> FOO
>    -> $b
>    -> $b["foo"]
> 
Ah, I wondered why there were two forms of the template. Can you really
pass constructor arguments to nodes created from token references? Why
would you want to use the info of another token (I can buy the text), as
in the following 2 argument call:

-> $b[ $c, "c" ]

Maybe there are situations I cannot envision right now where this would
be useful. In any case, the examples with the token references you give
above only work with the semantics of createImaginaryNode and not
createRewriteNodeFromElement (3 would not work, as it needs a token
reference)

> (The first one I'm not entirely sure about; if it can produce this 
> then it'll only be if there was a FOO matched on the left side of 
> the rewrite.  If there couldn't be one then it'll definitely have 
> to use the first template instead.)
> 



More information about the antlr-interest mailing list