help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to free symbols during error recovery


From: Laurence Finston
Subject: Re: How to free symbols during error recovery
Date: Fri, 8 Oct 2004 12:51:04 +0200 (MEST)

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.

>  > 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.

>
>  > Nor do I want want states and objects to be discarded in a way
>  > that's not under my control.  I also want to determine the position
>  > from which parsing is resumed.
>
> 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):

program: statement_list END

statement_list: statement_list  statement

Everything else reduces to `statement'.
The object passed to `yyparse()' as a parameter in my parser
is called `Scanner_Node scanner_node'.
`Scanner_Node' is actually a pointer type, declared as follows:

typedef Scanner_Type* Scanner_Node;

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.

While scanning, I also store the
position of newlines, so the position of the most recent
one, or the beginning of the stream, will be available.

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.

> 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.

Laurence




reply via email to

[Prev in Thread] Current Thread [Next in Thread]