Alan Manuel Gloria:
> 2. "superlist" just calls the top-level "i_expr" repeatedly, creating
> a list of items, and terminating upon finding a *>, returning the
> yielded list.
I had originally done this, and I then switched over to a more complicated set
of productions. I've now recently switched back to that much simpler "sequence
of i_expr" semantic, and I think that's the "right" meaning. I've posted my
latest to the devel branch in our SourceForge git repository.
Sadly, there's an annoying tooling problem with treating superlist/restart
list/whatever as just a "sequence of i_expr", which is why I had switched from
the simple sequence to a more complicated set of productions. To make the
"sequence of i_expr" concept work, you have to be able to end a restart list on
the *SAME LINE* that it starts. Previously, an i_expr could *ONLY* end at the
end of a line (possibly preceded by ";", and given the exception of the special
case of splice). Because that was true, that made for a really clear potential
ending point for an i_expr (in the normal case). No big deal, you say, just
add a new branch in i_expr to allow "head empty". Well, yes, and I've done
that. However, once you do that, ANTLR generates a huge number of warnings
about various ambiguities.
As far as I can tell, the ANTLR warnings are technically correct but spurious.
There's a huge number of them, and they're painful to track through. But if I
understand them correctly, the issue is straightforward. If you allow "head
empty" to end an i_expr, that means that *any* sequence of one or more n_expr
on a line could end an i_expr, because any sequence of one or more n_expr can
be a head. So technically "a b" and "a" both match an i_expr if "head empty"
is allowed as an i_expr.
This is basically the same situation as the "trailing else" matching in many
programming languages. It's also trivially disambiguated, just like "trailing
else". In this case, if you are reading in a line, simply follow the longest
match, or the earliest matching branches in a production where more than one
case could match, to disambiguate the cases. In fact, ANTLR does this, and it
seems to work just fine.
What's *weird* is that I can't seem to get ANTLR to shut up about it when it
generates the grammar. ANTLR has a "greedy" option specifically to disable
warnings when you want it to disambiguate branches this way. But in this case
I can't seem to make ANTLR happy. That makes *me* sad, because I'd like as
much confidence as possible that the specification is right, and I've been
using ANTLR to help me gain that confidence. ANTLR's greedy option works in
other cases, so I'm not sure why it's ignoring me in this case.
That said, I think this "sequence of i-expression" semantic is pretty clearly
the right semantic. For one thing, the productions I come up with are simple
and clean. I haven't checked the action rules carefully yet, but my first try
at them seems reasonably right too. It seems to be easy to reason about and
produce the "expected results". Here's my current try, fixes welcome:
restart_tail returns [Object v]:
i_expr rt1=restart_tail {$v = cons($i_expr.v, $rt1.v);}
| RESTART_END {$v = null;} ;
restart_list returns [Object v]:
RESTART hspace* comment_eol* restart_tail {$v = $restart_tail.v;} ;
head returns [Object v] ...
| restart_list hspace*
(rest1=rest {$v = cons($restart_list.v, $rest1.v) ; }
| empty {$v = list($restart_list.v); } )
rest returns [Object v] ...
| restart_list hspace*
(rest2=rest {$v = cons($restart_list.v, $rest2.v);}
| empty {$v = list($restart_list.v);} )
i_expr returns [Object v]
: head ...
| empty {$v = monify($head.v);} /* "head empty" - RESTART_END next */ ))
...
Thoughts?
--- David A. Wheeler
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
Readable-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
