Re: How to free symbols during error recovery

[Laurence Finston]

On Fri, 8 Oct 2004, Akim Demaille wrote:

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

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

I've been assuming that when the `error' token isn't used
anywhere, `yyparse()' just returns 1 right away, without
popping states from the stack.  It just occurred to me that
this might not be the case.

Actually, it doesn't really matter, because with my
approach `yyparse()' will start again with a fresh stack
anyway. I'm optimistic that this will work, because
`scanner_node' contains an object
called `id_map_node' of type `Id_Map_Node' (In 3DLDF,
`_Node' types are always pointer types) that contains
objects of type `Id_Map_Entry_Node'.  These (C++) objects contain
the (3DLDF) objects declared by users in the 3DLDF input
files.  Therefore, when `yyparse()' returns 1, the state of
the parse up to the point where the last `statement' was
successfully reduced is completely represented in
`scanner_node->id_map_node'.

>
> 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'll have to look at how `%destructor' works.  If it's the
simplest way to solve my problem I will use it.

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

I don't have any yet, because I haven't started implementing
it.  I don't think it will have to be scattered too
much.  I only need to set the position of the last
successfully reduced `statement' in one place, and the
position of the newlines in `sub_yylex()' (which is called
by `yylex()').  The actual error handling code will be
outside of `yyparse()', in the loop that wraps it.

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

I don't understand.  I'm talking about destroying objects
when they are popped from the stack, which happens when
parse errors occur.  In other cases, I don't need a
destructor because, like Oliver, I take care of allocating
and freeing memory by hand.  If I'm missing something here,
please explain it.

I'm not qualified to talk about `%destructor' because I
don't know how it works yet.  At the moment, I'm working on
something else, so I'm not worrying about it.


Laurence