[Openmcl-devel] Weird code

[james anderson]

On 2010-09-10, at 22:25 , Gail Zacharias wrote:

> On Fri, Sep 10, 2010 at 2:27 PM, Ron Garret <ron at flownet.com> wrote:
>> I happened upon the following odd behavior while mucking with some  
>> reader macros:
>>
>> ? (set-macro-character #\m
>>  (lambda (stream c)
>>    (unread-char c stream)
>>    (let ((*readtable* (copy-readtable  nil)))
>>      (read stream))))
>> T
>> ? 'moo
>> MOO
>> ? (defun foo (a b) (#/sizeWithAttributes: a b))
>>> Error: Foreign function not found: X86-DARWIN64::MEMSET
>>> While executing: CCL::LOAD-EXTERNAL-FUNCTION, in process Listener 
>>> (6).
>>> Type cmd-. to abort, cmd-\ for a list of available restarts.
>>> Type :? for other options.
>> 1 >
>> ? (defun foo (a b) (#/sizeWithAttributes: a b))
>> ;Compiler warnings :
>> ;   In FOO: In the call to NEXTSTEP-FUNCTIONS:| 
>> sizeWithAttributes:| with arguments (A B),
>> ;     2 arguments were provided, but at most 0 are accepted
>> ;     by the current global definition of NEXTSTEP-FUNCTIONS:| 
>> sizeWithAttributes:|
>> FOO
>> ?
>>
>>
>> I tracked the problem down to the following code in lib/macros.lisp:
>> [...]
>> and in particular, to this line:
>>
>>         (memset (read-from-string "#_memset")))
>>
>> Is there a reason why read-from-string being invoked here instead  
>> of just doing, say, (let ((memset '#_memset)) ... ?  Or dispensing  
>> with the binding entirely and just doing (,#_memset ...) in the  
>> body of the LET?
>
> It's so that the side-effects happen at runtime rather than compile
> time.  But it's a bug that it's just using whatever readtable happens
> to be in force at the time.

but doesn't that bit of code already know what symbol it wants to  
resolve?
in which case, the question is, what is the intended benefit running  
it through the reader rather than calling load-external-function  
directly?