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 */ ))


--- 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: 
Readable-discuss mailing list

Reply via email to