Re: [GLISS] why the hell all this fuss

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, Sep 8, 2012 at 12:00 PM, David Kastrup <address@hidden> wrote:
>> Han-Wen Nienhuys <address@hidden> writes:
>>
>>> On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup <address@hidden> wrote:
>>>>> There's one thing worth clarifying: when i say "syntax changes", i
>>>>> mean "changes in how user input looks like".  So a renaming of a
>>>>> command is a syntax change to me (despite the fact that no grammar
>>>>> rules change).
>>>>> That's probably confusing - what word should i use when i mean
>>>>> "changes in how user input looks like"?
>>>>
>>>> No idea.  What we have under the umbrella of "syntax discussion"
>>>> contains three things: lexical units, grammar and vocabulary, mostly
>>>> implemented in lexer.ll, parser.yy, and *.ly respectively.  In order to
>>>> keep syntax predictable, we want to be able to solve most problems just
>>>> by extending the vocabulary.  That means that lexical units and grammar
>>>> should be as generic, powerful, and simple as possible.  Specialized
>>>> lexical modes take power from the vocabulary.  We want to avoid them as
>>>> much as possible given our historic constraints.
>>>
>>> I completely agree with this. I have been giving some people a hard
>>> time in this discussion, but that is primarily for wanting to mess
>>> with either lexer.ll or parser.yy. As long as you don't that, I will
>>> not object fiercely to what syntax proposal anyone comes up with.
>>
>> Actually, is there a particular reason we are generating a C parser
>> rather than a C++ parser?  The implications regarding marking and
>> garbage collection of semantic values are rather awful.
>
> Right; all that should go away with guile v2 though, which uses Boehm GC

Wrong.  If the parse stack sits in an automatic or heap array, no
garbage collector in the world has a chance of knowing that values
beyond the hand-implemented stack pointer are stale, will never get read
again, should not be marked, and can be collected.

Believing in magic will only get us so far.

>> Probably historic because Bison did not use to come with C++ skeleton
>> files?
>
> Correct. The best we had was the pure_parser option.

Ok.  I'll probably change that after cross-checking with the
unfortunately non-orthogonal GLR parser option that might facilitate
moving the complexity for dealing with ambiguities from the grammar to
the parser generator.  Given the current grammar complexity, not an
option to be lightly discarded.

-- 
David Kastrup