bison-patches
[Top][All Lists]
Advanced

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

Re: [RFA] GLR parsing


From: Akim Demaille
Subject: Re: [RFA] GLR parsing
Date: 28 Jun 2002 10:34:09 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

>>>>> "Paul" == Paul Hilfinger <address@hidden> writes:

>> We should to unify this.  We still have some freedom on locations,
>> and we probably want to escape from macros, and use some new
>> %directives instead.

Paul> Sounds fine to me.  But I think I'd better put this off until
Paul> your "we probably want [something like X] ..." changes to "we
Paul> will do X".

My problem is that I often lack partners, and there are choices I
don't feel comfortable making alone.  That's part one of the problem.
Part two is that backward compatibility makes the initial decision
incredibly important.

This results in long delays before releasing :(

I think the next release will be 1.99 or 1.98, and write in huge
letters ``the interfaces are to be evaluated by _you_, and based on
the feedback, it might change in the near future''.  And then have 2.0
be the final point.


Paul> Correct.  Apparently, at least some other GLR implementors do
Paul> the same.  I figured that, at least for this initial
Paul> implementation, it was going to be hard enough getting things
Paul> working without worrying about additional trickiness that was
Paul> not terribly important in practice. 

I understand this.

Paul> I was also somewhat worried (perhaps unnecessarily) about the
Paul> interactions of this sharing and the calculation of semantic
Paul> values.  This was because I sort of had this idea that at some
Paul> point, I'd like to introduce semantic actions that are always
Paul> executed immediately upon reduction, even when in GLR mode.
Paul> They might be used for particularly simple cases (for
Paul> efficiency) or where semantic actions somehow had to affect
Paul> parsing or lexing.

Yes, this sounds like a good idea.

In addition, maybe trying to maximally share the stacks would incur a
greater penalty in most cases.  I mean, I guess your code is faster on
``deterministic'' input.

Paul> Besides, you sounded so disappointed at being deprived of the
Paul> fun of doing GLR from scratch, that I thought it would be nice
Paul> to leave you a project (:->).

:) :) :)


>> Hm, don't we want something more ``typed''?  These are
>> state_number_t, right?  Even if it's only typedef'd to unsigned
>> int, reading state_number_t makes it much easier to follow.

Paul> Well, yes, "we" do, but this is pervasive problem in this part
Paul> of the code, is it not?  Perhaps a general "typing sweep" is
Paul> called for?

I started!  There is symbol_number_t etc.  But we need more, I agree.
Nevertheless, I meant to say that new bits could avoid making the old
mistakes.

>> | +void | +merger_output (FILE *out) | +{ | + int n; | +
>> Maybe we can move this out from bison, and have M4 do?

Paul> I guess I don't entirely understand.  This function is modeled
Paul> on actions_output.

... which is not very nice too.   But anyway, having the base code
work is the most important step, then we can clean up if needed.

Paul> I have incorporated your other comments, and will check in soon.

Gosh, I feel gooooooood! :)



reply via email to

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