Email list hosting service & mailing list manager

Couple things... felix (22 Dec 2003 17:51 UTC)
(missing)
(missing)
(missing)
Re: Strings/chars Tom Lord (24 Dec 2003 04:47 UTC)
(missing)
(missing)
(missing)
Re: Couple things... felix (24 Dec 2003 11:43 UTC)
Re: Couple things... tb@xxxxxx (24 Dec 2003 23:30 UTC)
Re: Couple things... Michael Sperber (27 Dec 2003 18:46 UTC)
Re: Couple things... felix (24 Dec 2003 12:40 UTC)
Re: Couple things... Michael Sperber (26 Dec 2003 15:16 UTC)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
Re: Couple things... felix (04 Jan 2004 18:51 UTC)
Re: Couple things... Tom Lord (04 Jan 2004 22:13 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:18 UTC)
Re: Couple things... Tom Lord (05 Jan 2004 21:53 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:19 UTC)
Re: Couple things... felix (04 Jan 2004 18:42 UTC)
(missing)
Re: Couple things... felix (24 Dec 2003 12:01 UTC)
Re: Couple things... Jim Blandy (24 Dec 2003 16:29 UTC)

Re: Couple things... tb@xxxxxx 24 Dec 2003 23:30 UTC

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.

> 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.

Thomas