[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flush COMPILER-LET?



> I think the intended use is slightly different from the example you gave.
> Here's what I think of as a prototypical example...
> 
>  (DEFVAR *LOCAL-TYPE-DECLARATIONS* '())
>  
>  (DEFMACRO LOCAL-TYPE-DECLARE (DECLARATIONS &BODY FORMS)
>    `(COMPILER-LET ((*LOCAL-TYPE-DECLARATIONS* 
> 		     (APPEND ',DECLARATIONS *LOCAL-TYPE-DECLARATIONS*)))
>       ,@FORMS))
>  
>  (DEFMACRO TYPED-VAR (VAR)
>    (LET ((TYPE (ASSOC VAR *LOCAL-TYPE-DECLARATIONS*)))
>      (IF TYPE `(THE ,(CADR TYPE) ,VAR) VAR)))
>  
>  (DEFUN F (X Y)
>    (LOCAL-TYPE-DECLARE ((X FIXNUM) (Y FLOAT))
>      (+ (TYPED-VAR X) (TYPED-VAR Y))))
>  
> is equivalent to
> 
>  (DEFUN F (X Y) (+ (THE FIXNUM X) (THE FIXNUM Y)))

How about something like this:

   (defun f (z)
     (local-type-declare ((z fixnum))
       #'(lambda () (typed-var z))))

If I then evaluate (F 10), I may get something like this:

   #<%closure ((z 10)) ... more envs ... () (typed-var z)>

(TYPED-VAR Z) won't be expanded until I finally call this closure,
but by then the COMPILER-LET bindings have long since gone.

I think it was Cris Perdue who brought up this case in one of the
CL-Compiler meetings.

> You can do the same thing with MACROLET, but it feels quite awkward.

But it works.

> In my opinion, the only thing that makes COMPILER-LET feel bad is the
> stubborn refusal for interpreted-only implementations to do a semantic
> prepass. This is what forces you to do a special-bind at runtime. If
> COMPILER-LET did a special-bind only at conceptual compile time (i.e.,
> semantic pre-pass for interpreted code), it would not seem nearly so
> nasty because it wouldn't interfere unpredictably with runtime bindings.

What's required for the example above is for every interperter (not
just interpreter-only implementations) to do a semantic prepass.

-- Jeff