From: Nicolas Edel on
On Nov 2, 7:24 pm, "Captain Obvious" <udode...(a)users.sourceforge.net>
wrote:
>  NE> 1. Why ?
>
> Because macros work at macroexpansion time, NOT
> runtime.
>
>  NE> 2. How to use macros for generating the lambdas ?
>
> You can use macro to generate a code which generates lambda,
> for example.

Ok, so I use macro to generate code and then invoke the compiler at
runtime.
What is best practice for this: eval or compile ? Do they have similar
meaning in this context ?


(defun foo (predicate value)
(eval `(function (lambda (x)
(maybe ,predicate (eql x ,value))))))

or

(defun foo (predicate value)
(compile nil `(lambda (x)
(maybe ,predicate (eql x ,value)))))


:Nicolas
From: Pascal Costanza on
Nicolas Edel wrote:
> On Nov 2, 7:24 pm, "Captain Obvious" <udode...(a)users.sourceforge.net>
> wrote:
>> NE> 1. Why ?
>>
>> Because macros work at macroexpansion time, NOT
>> runtime.
>>
>> NE> 2. How to use macros for generating the lambdas ?
>>
>> You can use macro to generate a code which generates lambda,
>> for example.
>
> Ok, so I use macro to generate code and then invoke the compiler at
> runtime.
> What is best practice for this: eval or compile ? Do they have similar
> meaning in this context ?
>
>
> (defun foo (predicate value)
> (eval `(function (lambda (x)
> (maybe ,predicate (eql x ,value))))))
>
> or
>
> (defun foo (predicate value)
> (compile nil `(lambda (x)
> (maybe ,predicate (eql x ,value)))))

The semantics are the same. Which one is better depends on context. If
you use these functions only one or two times, or so, it's not
worthwhile to compile them, because compilation creates a considerable
overhead by itself. If you use them more often, then compilation is
worthwhile (although I recently heard that in, say, ECL or GCL,
compilation is almost always prohibitive).

You can also say (coerce '(lambda ...) 'function), and let the CL
implementation itself decide.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Nicolas Edel on
On Nov 3, 9:31 am, Pascal Costanza <p...(a)p-cos.net> wrote:
> > Ok, so I use macro to generate code and then invoke the compiler at
> > runtime.
> > What is best practice for this: eval or compile ? Do they have similar
> > meaning in this context ?
>
> > (defun foo (predicate value)
> >       (eval `(function (lambda (x)
> >                (maybe ,predicate (eql x ,value))))))
>
> > or
>
> > (defun foo (predicate value)
> >       (compile nil `(lambda (x)
> >                       (maybe ,predicate (eql x ,value)))))
>
> The semantics are the same. Which one is better depends on context. If
> you use these functions only one or two times, or so, it's not
> worthwhile to compile them, because compilation creates a considerable
> overhead by itself. If you use them more often, then compilation is
> worthwhile (although I recently heard that in, say, ECL or GCL,
> compilation is almost always prohibitive).
>

At that time, I don't know if they will be used often. But if they are
to be used in a context such as packet filtering, there will be a slow
startup time but this will be runtime efficient. I wanted to learn how
to make this now to avoid problems at experimentation time.

>
> You can also say (coerce '(lambda ...) 'function), and let the CL
> implementation itself decide.
>

Nice, indeed. But before I let the implementation decide by itself, I
would like to know if there are fundamental differences when calling
eval and compile in this context.

:Nicolas
From: Barry Margolin on
In article
<b4f59fea-7673-4a75-91f4-ca3983a24eb0(a)k17g2000yqb.googlegroups.com>,
Nicolas Edel <nicolas.edel(a)gmail.com> wrote:

> On Nov 3, 9:31�am, Pascal Costanza <p...(a)p-cos.net> wrote:
> > > Ok, so I use macro to generate code and then invoke the compiler at
> > > runtime.
> > > What is best practice for this: eval or compile ? Do they have similar
> > > meaning in this context ?
> >
> > > (defun foo (predicate value)
> > > � � � (eval `(function (lambda (x)
> > > � � � � � � � �(maybe ,predicate (eql x ,value))))))
> >
> > > or
> >
> > > (defun foo (predicate value)
> > > � � � (compile nil `(lambda (x)
> > > � � � � � � � � � � � (maybe ,predicate (eql x ,value)))))
> >
> > The semantics are the same. Which one is better depends on context. If
> > you use these functions only one or two times, or so, it's not
> > worthwhile to compile them, because compilation creates a considerable
> > overhead by itself. If you use them more often, then compilation is
> > worthwhile (although I recently heard that in, say, ECL or GCL,
> > compilation is almost always prohibitive).
> >
>
> At that time, I don't know if they will be used often. But if they are
> to be used in a context such as packet filtering, there will be a slow
> startup time but this will be runtime efficient. I wanted to learn how
> to make this now to avoid problems at experimentation time.
>
> >
> > You can also say (coerce '(lambda ...) 'function), and let the CL
> > implementation itself decide.
> >
>
> Nice, indeed. But before I let the implementation decide by itself, I
> would like to know if there are fundamental differences when calling
> eval and compile in this context.

No semantic differences, just performance differences. Compile will
create a compiled function, eval will create an interpreted function in
some implementations.

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Tobias C. Rittweiler on
Barry Margolin <barmar(a)alum.mit.edu> writes:

> Nicolas Edel <nicolas.edel(a)gmail.com> wrote:
>
> > Nice, indeed. But before I let the implementation decide by itself, I
> > would like to know if there are fundamental differences when calling
> > eval and compile in this context.
>
> No semantic differences, just performance differences. Compile will
> create a compiled function, eval will create an interpreted function in
> some implementations.

COMPILED-FUNCTION-P will return T on the first kind, but NIL on the
other kind! That's as big semantical change as you can get. ;-)

-T.