Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Sat, Sep 8, 2012 at 12:27 PM, David Kastrup <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel