[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Couple things...

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

On 24 Dec 2003 15:30:42 -0800, Thomas Bushnell, BSG <tb@xxxxxxxxxx> wrote:

felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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

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.