[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Declaring Common Nodes and Accessors in P-classes
Hi Evan,
> So is this idea a reasonable one? Is it something that would be difficult
> to implement? Or are the problems that this type of feature would address
> just minor inconveniences in other people's minds?
I will let others comment on this interesting idea, but the main problem
I see, with this approach, is that it breaks backward compatibility,
e.g.:
Initial Grammar
---------------
some_prod =
{some_alt} token another_token |
{another} token;
-> PSomeProd.getToken() is generated
Some Months Later...
--------------------
some_prod =
{some_alt} token another_token |
{another} token |
{yet_another_one} lets have some fun; /* unlikely names, I agree;-) */
-> Now, "token" is not common to all alternatives anymore, so it gets
"removed" from PSomeProd. In other words, PSomeProd.getToken() does not
exist anymore.
*****************
I agree with you that it would be nice to handle some cases like your
examples is a simpler manner. The solution to this, in my opinion,
resides in "automatice AST transformation". Your example would be
transformed into the following AST:
/* After trnasofrmation */
try_statement =
try block catch_clause* P.finally?;
So, for most simple cases, separate "parse-time alternatives" would
simply be combined into a unique alternative by the AST transformation
phase.
Etienne
--
Etienne M. Gagnon egagnon@j-meg.com
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/