[Openmcl-devel] dfsl/foreign function oddities
enderx12 at mac.com
Fri May 13 21:33:02 UTC 2005
On May 13, 2005, at 3:02 PM, Gary Byers wrote:
> One potential source of confusion that sometimes leads to symptoms
> like those that you describe stems from the fact that #_ is a reader
> macro (and therefore does most of its work at read-time.). The act of
> reading #_foo has the (important!) side-effect of defining a global
> macro function on the symbol OS::|foo| as well as the effect of
> returning that symbol.
Argh. Yeah, somehow it's easy to forget that "reader macro" involves
> Like I said, that scenario would explain the symptoms that you
> I think that the manual actually tries to explain the issue, but
> the prose
> may be a little terse and cryptic.
Yep, right there in black and white, section 9.4.1:
"It's important to remember that the side-effect happens when the
form containing the reader macro is read. Macroexpansion functions
that expand into forms which contain instances of those reader macros
don't do what one might think that they do, unless the macros are
expanded in the same lisp session as the reader macro was read in."
So I've replaced the call to #___CFStringMakeConstantString with
(external-call "___CFStringMakeConstantString" ... ), and that seems
to work. I'm not sure why it needs all three underscores, but it
finds it. There is of course the limitation that the macro OS::|
__CFStringMakeConstantString| is not defined.
The next one on my hit list is #$noErr. The easiest workaround, it
seems, is to do *something* that calls #$noErr before the prebuilt
fasls get loaded, but that seems ugly to me. The alternative is in
the original source to do something like (defconstant +noErr+ #
$noErr), but that seems like a bit of a hack too.
Stylistically, what's the best solution here? Is it always a Bad Idea
to use the #$ and #_ forms in macros?
More information about the Openmcl-devel