2008/9/15 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> "Neil Jerram" <[EMAIL PROTECTED]> writes:
>
>> Now, as it happens, the code doesn't actually implement what the
>> manual says, and in fact scm_array_handle_release() is currently a
>> no-op! But I believe the manual's intention is sensible, so it think
>> I think we should commit this patch as-is for now, and raise a bug to
>> track the fact that the array/handle API isn't fully implemented.
>>
>> What do you think?
>
> I'd prefer fixing the manual rather than `scm_array_get_handle ()',
> because (1) setting up a dynwind is "costly" (involves some consing),
Which implies that we should avoid it if not needed, which to me
implies that it makes sense to have it _inside_ the scm_array*
functions, because the implementation of those functions determines
whether it is needed. (Currently it isn't needed, because the
functions don't actually perform any reservation.)
> 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 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?
(It may also help to grep for scm_dynwind_begin, to see all current
uses; there are quite a few.)
> OTOH, it may be the case that people have been relied on the described
> behavior, in which case it would be wiser to fix `scm_array_get_handle ()'
> to conform to the manual...
Note that scm_array_get_handle can itself throw an error, and so can
the other APIs that return a handle to the caller. That suggests to
me that the scm_dynwind* stuff might have to be implemented inside
these APIs - because otherwise it wouldn't be covering all the
possible non-local exits.
On the other hand, it might be that all of the error cases are just
wrong-type-args, and so don't really count. I haven't checked them
all in detail yet.
One more observation: we should take care when adding occurrences of
scm_dynwind_begin (0) into code, because it prevents the enclosed code
from capturing its continuation, returning, and then calling the
continuation again later. In this case, I wonder if there could be
practical soft port implementations that would want to do this. (I
thought I had done it myself when writing (gui entry-port) for
guile-gui, but in fact that only uses a continuation as an escape
mechanism (i.e. for jumping back up the stack).) On the other hand,
if we use scm_dynwind_begin (SCM_F_DYNWIND_REWINDABLE), to allow a
continuation to be called again from outside, that raises the question
of what happens if the array in question has changed since the
continuation was captured.
In summary, I think this is all quite tricky, and I don't have a good
answer yet!
Regards,
Neil
