Re: How to free symbols during error recovery

[Akim Demaille]

>>> "Laurence" == Laurence Finston <address@hidden> writes:

 > On Fri, 8 Oct 2004, Akim Demaille wrote:
 >> >>> "Laurence" == Laurence Finston <address@hidden> writes:

 >> 
 >> No, rather it says when we stop throwing away symbols, hence error
 >> "stops" %destructor.  It does not trigger it.
 >> 

 > I meant that a parse error causes the destructor to be called,
 > possibly repeatedly, and it stops when a state is reached
 > corresponding to a rule containing an `error' token.  Even if this
 > behavior is predictable, I will probably not be able to predict what
 > state this is, so it's not under my control.

But you _don't_ have control!  Unless you do something I don't
know/understand.


 >> > I haven't considered using `%destructor' for my application,
 >> > firstly because I haven't gotten around to it, and secondly because
 >> > I don't think it will work for my parser.  I use a `%union'
 >> > containing a `void*' that can point to objects of various types
 >> > that are not all in a single class hierarchy, so writing a
 >> > destructor function would be complicated.
 >> 
 >> I don't understand the relationship here.

 > It's not possible to delete an object by calling `delete p' if `p' is
 > a `void*'.  I must first cast `p' to the type of the object, or to a
 > base type, if the class hierarchy has virtual destructors.  In order
 > to do this, I would have to store type information somewhere where it
 > would be accessible to the destructor, and I don't want to do this.
 > In general, I try to avoid relying on run-time type information, and
 > so far I haven't needed it.

But I guess the symbol type (%type) is enough.  And of course
%destructor takes this into account.  Rather *you* have to take this
into account.

%destructor { my_string_delete ($$); } string;
%destructor { delete $$; } object_type_1 object_type_2;


 >> I have not understood how you do that.  You can't unless you changed
 >> the parser.

 > No, I haven't and I don't plan to.  The GNU 3DLDF grammar contains
 > the following rules (I've left out the actions for clarity):

Thanks for the details.  Now I understand how you gain some form of
control.

 > Each time the rule `statement_list: statement_list statement' is
 > reduced, I plan to store the position in the current input stream
 > in a data member of `scanner_node'.  If a parse error occurs, this
 > is the last position where the parser succeeded in parsing a
 > statement.

This is not incompatible with %destructor: just don't give a
%destructor to statement_list.

 > When `yyparse()' returns 1, I can display context about the
 > position where the error occurred and allow the user to input and
 > delete tokens, in the way familiar to users of TeX, Metafont, and
 > MetaPost.  Then I can call `yyparse()' again to resume parsing.

Gee!

Don't you have a lot of code scattered in your grammar to support all
this?


 >> Here is the (up to date) doc.

 > Thanks .  I'll look at it when I get a chance.  I don't plan to
 > implement recovery from parse errors in GNU 3DLDF until after the
 > forthcoming release.

Again, I'm not taking _at all_ about error recovery :)