Hi Tomas, hi all,

On Sat, Oct 10, 2009 at 10:09:16AM +0200, Alexander Burger wrote:
> Hi Tomas,
> > >    Only functions which evaluate all of their arguments should be passed
> > >    to 'apply'. For other functions the result is undefined.
> > I still wonder whether this restriction is necessary?
> I think it is. This is a consequence of how 'apply' behaves (not only in
> picoLisp): It takes a list, and passes it to another function. This list
> contains the final arguments, suitable for that function. That is, all
> items in the list are already "evaluated". If a function wants to
> evaluate its arguments individually by itself, or perhaps some of them
> not at all, it cannot control this because 'apply' already did the whole
> job.

Now the same question arose again in a personal mail to me. I feel I
have to elaborate more on that subject.

As I said, 'apply' is used to pass a list of _evaluated_ arguments to a
function. This might be too early for certain functions, which rather
like to first look at each argument and then decide whether to evaluate
it or not. Think of 'setq' (evaluating only each second argument), 'if'
(evaluating the second and following arguments based on the result of
the first argument), or 'and' (stopping evaluation when NIL is

So I would state an 'apply' rule as:

   If you can write

      A: (apply fun (list A B C D))

   then this should give the same result as

      B: (fun A B C D)

For example, if we do (setq A 1  B 2  C 3  D 4), then

   A: (apply + (list A B C D))

is equivalent to

   (apply + (1 2 3 4)

which corresponds to the 'apply' rule as

   B: (+ A B C D)

But for functions that do _not_ evaluate all their arguments, this rule
will not hold:

   A: (apply setq (list A 1 B 2))

is equivalent to

   (apply setq (1 1 2 2)

which would expand with the 'apply' rule to

   B: (setq 1 1 2 2)

and _not_ to the intended

   (setq A 1 B 2)

- Alex
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to