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... felix 24 Dec 2003 11:46 UTC

On Tue, 23 Dec 2003 11:12:04 +0100, Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> wrote:

>>>>>> "Thomas" == Thomas Bushnell <xxxxxx@becket.net> writes:
>
> Thomas> Um, in C a user definitely has cause to care.  Importantly, a
> function
> Thomas> can be used far more flexibly.  Allowing all the forms to be
> macros is
> Thomas> a pain.
>
> Felix will point out that allowing forms to be functions is a
> performance consideration.
>

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

cheers,
felix