Re: compiler bug: let with name clash

On Wed, 1 Feb 2006, Yann LeCun wrote:

> The compiler expands macros at compile time, not at run
> time. Basically, as far as compiled code is concerned, Lush macros
> behave pretty much like C/C++ preprocessor macros (which also
> expands at compile time).
>
> There is no good way to fix this other than writing
> a brand new compiler that can handle code generation
> at run time.

>> To fix this the macro-expansion must be delayed until the bindings
>> are established.

I meant to say, the compiler should wait with the macro-expansion
until it has determined what local bindings exist--local bindings
may shadow macro definitions. In the example

(defun some-func (mysum)
   ((-idx1- (-double-)) mysum)
   (mysum 0))

the compiler can and should understand that the expression '(mysum 0)'
is not a macro call. Sorry for the confusion.

As for the relevance of this problem, the example looks rather
artificial--I tried to boil it down us much as possible. But I
ran into this problem repeatedly (e.g., I defined a little macro
'vec' that creates the expression of a vector given the coordinates
of two points; after that I suddenly couldn't compile libidx/idx-double
anymore since there is the expression '(vec i)' in function
idx-d1reverse...). Because lush has only a single global name space,
you will sooner or later encounter this problem.

Ralf



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642