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. 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. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
