On 24 Dec 2003 15:30:42 -0800, Thomas Bushnell, BSG <xxxxxx@becket.net> wrote:

> felix <xxxxxx@call-with-current-continuation.org> writes:
>
>> Not only that. It allows the *implementor* maximal flexibility, which
>> I consider more important in this case. Allowing a form to be a function
>> may tempt users to do weird stuff like taking it's address, etc.
>
> That's exactly the flexibility I thought we should give the user.
>
> The intereface will be used an awful lot more times than it is
> implemented.  The mere convenience of the implementor isn't worth
> much.

This has nothing to do with convenience - the important fact
is to remove the possibility of subtle bugs in code that
works with one or two implementations, but not in others. Believe me, you
*don't* want to to debug FFI code, that bombs,
just because the user (rightfully) didn't anticipate all kinds
of memory-management schemes (moving/non-moving, etc.)

>
>> Remember: on this level (FFI) things can get extremely fragile and
>> tricky.  The user of an FFI should be *forced* to use it's forms in
>> a straightforward and simply manner.
>
> Ha ha ha ha.
>
> Programmers will quickly probe every corner of the interface; if it's
> so fragile that you can't specify the meaning of the forms, but have
> to rely on them being used "straightforwardly", then you are nowhere
> near ready to specify an interface.
>

Exactly for that reason I propose to simplify the interface, and
to remove space for dirty tricks and to specify the meaning of the
forms rigorously.

cheers,
felix