Neil Jerram <[EMAIL PROTECTED]> writes: > The main part of this patch is appended below, and I would appreciate > any comments that anyone may have
Looks very good to me. Please go ahead. Thanks! One (minor?) point I have is the term "lazy". I am not sure if it is the right term to use. It has meaning for people who already know lazy-catch, but I'd say it is not really descriptive of what it does. Something like "pre-unwind" handler might give a better hint of how it differs from the 'post-unwind' handler. Hmm, what I'm trying to say here that "lazy" is not some standard, established terminology, and if we come up with something better, we should feel free to change terminology. > One point is that I have removed the "SCM_API" from the declaration of > scm_i_with_continuation_barrier. My understanding is that > scm_i_with_continuation_barrier (like scm_i_* functions in general) is > a libguile-internal function and so does not need to be exported from > the libguile DLL in a Windows build (which is what SCM_API is for). Yeah. I have to say that I don't really understand the meaning of SCM_API. I mostly treat it is as a purely technical thing: you need to use it when you want code outside this DLL to call the function. I don't treat it as a way to document what is in the Guile API and what isn't. For example, a macro or inline function that is in the Guile API might expand into a call to a scm_i_ function. That function than needs to be flagged with SCM_API although it is not part of the API. I see no point in preventing people from calling internal functions as long as they know that they are internal. That's why I put SCM_API on all functions with global scope. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
