[antlr-interest] Porting from antlr 2.7.1 to 2.7.4

[Ric Klaren]

On Wed, Jul 07, 2004 at 02:09:02PM -0000, Sergey Bogdanov wrote:
> First, the issue, which is a completely new way to handle
> heterogenuous asts. 2.7.1 used c++ constructors to build and allocate
> new ast objects  which worked perfectly well.

Actually the old way was quite broken. Using all kinds of default
functionality like dupTree etc. was unreliable because of it. Also
automatic tree construction could fail in some cases.

> Now it looks like antler creates a registration table. As a result, every
> ast needs to be supplied with a 'factory' and 'initialization'. There are
> about 100 different asts in the application and making those changes is
> difficult.

Quite often some minor scripting can alleviate the pain of making many
similar changes.

> So, there are two questions:
>     1. is there a backwards compatibility mode?

No.

>     2. what was the reason for changing the way to handle heterogenous
> asts? Current mechanism looks like an overcomplicated one.

Because the old one was broken. I had two options fix it or remove it. Even
after the fix session I'd dub heterogeneous AST stuff as somewhat
experimental (I'd not be surprised if you'd run into surprises using it).

>     1. One difference I've fond was that 2.7.1 declared temporary asts
> and tokens no matter what. Therefore the following worked ok:
>     rule: LSQR ... RSQR! {#RSQR->...};
> Now, there is no declaration for RSQR temp if the bang is used and c++
> compilation fails. It is easy to work around by supplying an element
> id 'rsqr1:RSQR!' but this would be a good help if antlr at least
> warned that an undeclared element had been used in the action.

Due to the unwieldly interface between the action parser and the
codegenerator this is hard to implement in 2.7.x code. I would have loved
to prescan action code first for AST references and such but it would take
some serious work to do it.

>     2. It would be nice to automatically generate ANTLR_VERSION macro
> definition in the C++ code.

Would a macro in the support library suffice? Although adding macro's in
support lib and generated code is easy to add.

>     3. for the future antlr develpments bacward compatibility should
> be taken in account.

It usually is. I can understand that you're a bit upset about having to fix
a big load of AST classes but the old way was broken.

Cheers,

Ric
--
-----+++++*****************************************************+++++++++-------
    ---- Ric Klaren ----- j.klaren at utwente.nl ----- +31 53 4893755  ----
-----+++++*****************************************************+++++++++-------
  "I think we better split up."
  "Good idea. We can do more damage that way."
  --- Ghostbusters



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/