Re: [GLISS] why the hell all this fuss

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, Sep 8, 2012 at 12:27 PM, David Kastrup <address@hidden> wrote:
>
>>>>>> 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.
>
> Can you clarify? Boehm GC should also be inspecting the stack for what
> might be pointers to memory that cannot be reclaimed.

It does not help.  If I have SCM stack[100] indexed by int stackpointer
with a current value of 42, Boehm GC has no way of knowing that
stack[43]..stack[100] will never get used again because every increment
of stackpointer will be accompanied with overwriting the respective
stack entry.

> See also
>
> http://www.gnu.org/software/guile/manual/html_node/Conservative-GC.html
>
> if your point is that some blocks will not be GC'd, then that is
> nothing new; pre-1.8 guile does not guarantee that, and in general
> conservative GC cannot guarantee that. Conservative GC is problematic
> if the heap is large compared to the address space; everything then
> starts looking like a pointer.

It also does not help with any stack implementation that does not clean
out cells as they become unused by virtue of the stackpointer moving
across them.

-- 
David Kastrup