Creating functions "on the fly"
DANIEL HENRIQUE ALVES LIMA
Thanks for help in "set key/value..." problem.
I have a new question :
I'm using a book about "Commom Lisp". There's a section in this book
about "dynamic creation" of functions. For me, a example like this won't
be run (at least, i couldn't run it under emacs) :
(defun make-add-function (factor)
(function (lambda (x) (+ x factor))))
(funcall (make-add-function 3) 2)
But in the book there are similar examples. The problem is :
"factor" (in lambda body) isn't being evaluated ("not evaluate" seems to
be the correct procedure in this case) and the Lisp interpreter seems to
treating "factor" as a parameter (like "x")...
Now, i don't know if this piece of Lisp code is correct (and the
problem is emacs interpreter) or if it isn't. Is there any way to
generate functions on the fly ?
-----------------------------------------------------------
| ________ |
| o | __ | Daniel Henrique Alves Lima , RA:970482 |
| _O | |__| | Ciencia da Computacao 97 / Unicamp |
| ____/\ |___WW___| E-mail : 970...@dcc.unicamp.br |
| __/ / || |
| || |
| || |
| ____________||___________________________________________ |
-----------------------------------------------------------
Martti Halminen
> I'm using a book about "Commom Lisp". There's a section in this book
> about "dynamic creation" of functions. For me, a example like this won't
> be run (at least, i couldn't run it under emacs) :
>
> (defun make-add-function (factor)
> (function (lambda (x) (+ x factor))))
>
> (funcall (make-add-function 3) 2)
<snip>
> Now, i don't know if this piece of Lisp code is correct (and the
> problem is emacs interpreter) or if it isn't. Is there any way to
> generate functions on the fly ?
That piece of code works quite nicely in a Common Lisp system.
If nobody has told you, Emacs Lisp differs in several major points from
Common Lisp. There is a compatibily mode, which adds some CL constructs
to it, but it can't help too far.
Get a real Common Lisp; you can (and probably should) use Emacs for
programming with it; just run CL as an inferior process to Emacs.
--
Frederic Brunel
> (defun make-add-function (factor)
> (function (lambda (x) (+ x factor))))
>
> (funcall (make-add-function 3) 2)
> Now, i don't know if this piece of Lisp code is correct (and the
> problem is emacs interpreter) or if it isn't. Is there any way to
> generate functions on the fly ?
Emacs doesn't use lexical scoping but dynamic scoping... In this case,
the 'factor' variable is not captured by the lambda.
Erik Naggum
| I'm using a book about "Commom Lisp". There's a section in this
| book about "dynamic creation" of functions. For me, a example like
| this won't be run (at least, i couldn't run it under emacs) :
Why are you using Emacs Lisp when you have a book on Common Lisp?
| -----------------------------------------------------------
| | ________ |
| | o | __ | Daniel Henrique Alves Lima , RA:970482 |
| | _O | |__| | Ciencia da Computacao 97 / Unicamp |
| | ____/\ |___WW___| E-mail : 970...@dcc.unicamp.br |
| | __/ / || |
| | || |
| | || |
| | ____________||___________________________________________ |
| -----------------------------------------------------------
Drop this.
#:Erik
--
Does anyone remember where I parked Air Force One?
-- George W. Bush
Jonathan BAILLEUL
>
>
> I have a new question :
>
> I'm using a book about "Commom Lisp". There's a section in this book
> about "dynamic creation" of functions. For me, a example like this won't
> be run (at least, i couldn't run it under emacs) :
>
> (defun make-add-function (factor)
> (function (lambda (x) (+ x factor))))
>
> (funcall (make-add-function 3) 2)
>
> But in the book there are similar examples. The problem is :
> "factor" (in lambda body) isn't being evaluated ("not evaluate" seems to
> be the correct procedure in this case) and the Lisp interpreter seems to
> treating "factor" as a parameter (like "x")...
> Now, i don't know if this piece of Lisp code is correct (and the
> problem is emacs interpreter) or if it isn't. Is there any way to
> generate functions on the fly ?
>
First, I suggest you get a full ANSI Common Lisp implementation before
further developments (CMU/CL, ACL, CLISP...).
Well, what is the precise purpose of creating functions 'on the fly'?
If the aim is to simply generate functions, the normal way is to use
macros.
e.g: (defmacro nil! (var)
`(setf ,var nil))
, which can be used like:
> (setf x 5)
> (nil! x)
> x
nil
Macros do not evaluate their arguments, they carbon-copy the code
provided as argument inside their body without evaluation. So, as
macro-expansion occurs at compile-time, all the data influencing the
expansion must be fixed at compile-time.
If, in the other hand, you actually want to dynamically declare
functions during the evaluation of a program, you might use other ways I
never considered yet.
I never really thought about case studies of that kind, and I'd be happy
to learn some if someone is inspired...
--
----------------------------
Bailleul Jonathan
DEA Informatique
LaBRI, Universite Bordeaux I
Robert Monfera
> Well, what is the precise purpose of creating functions 'on the fly'?
Maybe just learning. On my very first encounter with a Lisp system, I
found it very inspirational that code can generate code (I did not know
about macros then, and I did not have to, and macros are mostly for
compile-time effects).
> If the aim is to simply generate functions, the normal way is to use
> macros.
> If, in the other hand, you actually want to dynamically declare
> functions during the evaluation of a program, you might use other ways I
> never considered yet.
> I never really thought about case studies of that kind, and I'd be happy
> to learn some if someone is inspired...
You can do very interesting performance micro-optimizations, like
capturing variables thus avoiding access:
(defmethod change-foo (x)
...
(let ((y (frob x)))
(defmethod bar (z)
(declare (optimize speed (safety 1)))
(baz y z))))
Combine this with variable declarations to best effect. For example, if
you can compile the from and to values into a loop, it will be faster.
This works only if compilation time is insignificant relative to the
gains.
Robert