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 much.
This has nothing to do with convenience - the important fact is to remove the possibility of subtle bugs in code thatworks 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