On 27 Dec 2003 22:54:45 -0800, Thomas Bushnell, BSG <xxxxxx@becket.net> wrote:

> Oh come on?  Taking the address of a function is a normal, everyday,
> part of the semantics of C.  It would only seem a dirty trick to
> someone who also thinks functions as parameters is a weird, occulty,
> freaky thing.  Perhaps I have misunderstood, but then you need to say
> more than "Oh, come on."

Yes, you misunderstood. The point is not about taking function addresses
in general (and I'm surprised you're trying to stuff that down my throat),
but about doing things with an API that are clearly not always sensible in
the
context that API is used in. So lets talk about the technical side, in
the context of SRFI-50:

>
>> You, as a user, don't have to write that macro. The dirty tricks
>> that implementors have to play, when trying to conform to this SRFI,
>> might be unavoidable.
>
> It's hard to imagine any circumstance in which you cannot correctly
> write as a C function something that you can do as a macro.  Macros
> can be more efficient indeed (though not more efficient than inlined
> functions); but can you give me an example of something you can do in
> a functional macro that you can't do in a real function?

Inlined functions are IIRC not standard C, so lets forget about that, for
a moment.
The efficieny argument isn't that important really, even though it is
still applicable.

So, how abut passing hidden extra parameters? (like a current "arena")
Or expanding into inline-assembly (or other nonportable constructs like
"({...})", etc.) that has to do ugly things in the current stack-frame?
(Note that this is a different form of portability here - the C code
that uses SRFI-50 should be portable C, the expansion used by the macros
may not)
For more examples, see your systems's /usr/include.

>
>> It looks like you never designed and implemented a Scheme FFI.
>> That flexibility on the implementors side is important. *Especially*
>> if portability is required.
>
> I think you should explain the difficulty rather than just announce
> that your exalted position tells you the truth without deigning to
> explain it to mere mortals.

I just did. ;-)

>> People will do all sorts of weird things. So what?
>
> So it demonstrates that macros are not somehow less susciptible to
> weird things on the part of users than are functions.
>

That's not what I'm talking about. Macros simply give the implementor
more leverage. And that's important in this case. I invite you to implement
SRFI-50 for your favorite Scheme implementation and tell me about your
experiences.

cheers,
felix