Hi, "Neil Jerram" <[EMAIL PROTECTED]> writes:
>>>> and (2) I don't know of any other function that does a dynwind behind >>>> the scenes (IOW, let's not break the "rule of least surprise"). >> >> I meant "I don't know of a function that does a `dynwind_begin' >> *alone*" (of course there are plenty of functions that do >> `dynwind_begin' + `dynwind_end'). > > Yes, I see what you mean now. (The scm_dynwind_begin() being in > scm_array_get_handle(), and the scm_dynwind_end() being in > scm_array_release_handle().) Yes. >>> I think you're imagining a clear boundary here where there isn't one. >>> If needed, either the scm_dynwind would be inside >>> scm_array_get_handle, or it would be inside scm_uniform_vector_read. >>> Both of those are public libguile functions, so where's the >>> difference? >> >> The difference is that `scm_array_get_handle ()' is a low-level >> function. It may be used, say, in code that passes SRFI-4 vectors to C >> that implements "performance-critical" code. Adding consing in there >> wouldn't feel right. > > If you add in " and which can't possibly do a non-local exit " there, > I see your point. Exactly. >> Right, I hadn't thought about it, but as you mention, a dynwind in >> `uniform-vector-read!' will only affect soft port implementations. > > With that in mind, do you think we need to solve this now? I think > this is low impact, so for now I'm inclined just to raise a bug in > Savannah, containing our discussion so far, so that we don't forget > it. I submitted this bug: https://savannah.gnu.org/bugs/index.php?24292 (Oops I forgot "and dynwinds" in the bug title...) I would suggest that we drop that mention of dynwinds from the manual. Thanks, Ludo'.
