help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Writing a function/macro in Elisp that generates a function at runti


From: Toby Cubitt
Subject: Re: Writing a function/macro in Elisp that generates a function at runtime
Date: Tue, 28 Oct 2008 11:38:20 +0100
User-agent: Thunderbird 2.0.0.17 (X11/20080929)

Barry Margolin wrote:
> In article <mailman.2216.1225168079.25473.help-gnu-emacs@gnu.org>,
>  Toby Cubitt <tsc25@cantab.net> wrote:
>> I'm trying to write a function in Elisp that generates a function at
>> runtime, but hitting the limits of my Lisp abilities. Here's a first
>> attempt at the kind of thing I'm trying to do:
>>
>> (defun wrap-insert-function (insfun)
>>   `(lambda (new-data old-cell)
>>      (setf (cell-data old-cell)
>>            (funcall ,insfun new-data (cell-data old-cell)))
>>      old-cell))
[snip]
>> The problem is, because it's quoted, the `setf' macro never gets
>> expanded by the byte-compiler. And that's no good, because the cl
>> package where `setf' is defined shouldn't be loaded at runtime, and
> 
> To do that you'd need lexical closures, but Elisp doesn't have them.  
> Since you're not generating the function until runtime, there's nothing 
> to compile at compile time.

I can start to see how to do it with lexical closures. (How many times
have I wished for them in Elisp! Bring on the lexbind branch...). But is
there really no way to do this without closures? That seems strange. The
above definition works fine, except for the setf issue. As you say, the
run-time generated function obviously can't be compiled, because it
doesn't exist at compile-time. But that's not what I asked for. I want
the setf macro to be *expanded* at compile time into the setf method for
`cell-data', and there *is* enough information at compile-time for that.

I had another go, and came up with the following attempt (I can hear the
Elisp experts whincing already - I know it's ugly!)

(defmacro wrap-insfun-2 (f-2)
  (let ((comma-f `(nil ,f-2)))
    (setcar comma-f ',)
    (macroexpand-all
     `(lambda (new old)
        (setf (cell-data old)
              (,comma-f (cell-data new)
                        (cell-data old)))))))

(defmacro wrap-insfun-1 (f-1)
  `(eval (backquote ,(macroexpand-all `(wrap-insfun-2 ,f-1)))))

(defun wrap-insfun (insfun)
  (wrap-insfun-1 insfun))

This works as long as `wrap-insfun-1' is not byte-compiled (I don't
completely understand why it fails when byte-compiled, but I guess it's
because `backquote' does't work on the byte-compiled expansion of
`wrap-insfun-2'.)

I was trying to have macros generate the body of the wrap-insfun
function, so that I could force setf to be macro-expanded when compiled.
 Getting macros to generate code containing a backquote construct seems
to be tricky, I guess because backquote expansion gets confused by the
commas that are supposed to be part of the generated code, hence hiding
this inside `comma-f'.

Is generating a backquote construct possible using macros, in a robust
way that byte-compiles properly, and without the ugly hack of making use
of Emacs's internal old-style backquote implementation as I've done? Or
is this simply impossible? Or is Elisp lacking some Lisp feature that
would allow this? (reader macros?)


> You don't need to generate a function on the fly for this.  Do something 
> like this:
> 
> (defun insert-with-function (insfun new-data old-cell)
>   (setf (cell-data old-cell)
>         (funcall insfun new-data (cell-data old-cell)))
>   old-cell)

Hmmmm...the simplest ideas are always best. This does sound like a
better approach. Thanks!

I'm still curious about the above macro shenanigans though, since it's
pushing at the boundaries of my understanding of Lisp and I'd like to
understand these issues more fully.

Toby




reply via email to

[Prev in Thread] Current Thread [Next in Thread]