[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 27 Dec 2003 22:54:45 -0800, Thomas Bushnell, BSG <tb@xxxxxxxxxx> 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