This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
When you say that SCHEME_GC_PROTECT "registers the <n> variables (lvalues) with the garbage collector" you mean, I believe, to say that it adds them to its root set? This would protect the variables, and anything reachable from them, from GC, regardless of whether they are reachable from any other scheme variable. When you say that SCHEME_GC_UNPROTECT "removes the block's protected values from the garbage collector's list" you mean, I believe, to say that it removes them from its root set? They would still be protected from GC if they are still reachable from anything in the remaining root set. If this is what you mean, then I don't think there is a problem with it except that maybe the wording should be clearer abut the visible consequences. If something else is what you mean, then more words should be used to explain exactly what the visible consequences of making these calls will be. Is there a rationale for the number 12 in the definition of SCHEME_DECLARE_GC_PROTECT? It seems an odd choice when it's just as easy to protect a single freshly-allocated scheme vector of arbitrary length. Bear