[Openmcl-devel] dfsl/foreign function oddities

[Chris Curtis]

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

> Like I said, that scenario would explain the symptoms that you  
> describe;
> 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?

--chris