[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/