array handles and non-local exits

["Neil Jerram" <neiljerram@googlemail.com>]

2008/9/15 Ludovic Courtès <ludo@gnu.org>:
>
> "Neil Jerram" <neiljerram@googlemail.com> 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