John Morrison <jm@...> writes:
> On Wednesday 13 October 2004 03:35 am, Nikodemus Siivola wrote:
>> Aha, gotcha. So presumably signalling UNKNOWN-FOREIGN-FUNCTION-ERROR or
>> some-such would solve this for you -- as then you'd be able to handle
> I think my problem is actually more fundamental than that (hey, be
> nice! :-). It's the fact that I don't know how to "use" a macro
> (e.g., define-alien-routine) that might signal an error (whether
> SIMPLE-ERROR or UNKNOWN-FOREIGN-FUNCTION-ERROR) during macroexpansion.
> Basically, my ugly eval+quote kludge (if I can so dignify it by
> calling it a kludge) delays macroexpansion until after the
> error-catching form becomes active.
> I have to think, or at least hope, that this (an error-signalling
> macro) is a Well-Known Problem with a Well-Known Solution.
> If I only knew what that Well-Known Solution was!
To be fair to you, I'm not sure that there is one, but in defence of
the alien interface (which does a lot of heavy lifting at compile-time
so that access to alien thingies doesn't completely kill performance)
it's not clear what could be done to mitigate this either. At least,
I think, in fact, that error-signalling macros are relatively rare
(except for trivial cases such as syntax or malformed-source errors):
and it may well be that the alien macros are bad and wrong in that
respect. (I also think that being utterly sure that the libraries are
loaded before you use DEFINE-ALIEN-ROUTINE might be your best bet in
the short term, because the alternative to error-signalling macros is
probably quite a lot of restructuring of alien code). It may be that
DEFINE-ALIEN-ROUTINE could be persuaded to do something like
(defmacro define-alien-routine (name ...)
(if (find-foreign-symbol name)
but that may not be a net win. I forget what macroexpand-time
computation define-alien-routine does (and I've just returned from a
conference, so my clarity of thought and of expression isn't at its
usual crystalline self...)
I hope this hasn't muddied the waters much more.