[Top][All Lists]
[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! :)