Hi Christophe,

> Even if I did not face this problem, this is counter-intuitive to me.
> I guess that there are serious reasons for this behaviour.

Yes, indeed. It goes down to the core of how Lisp's evaluation mechanism
works. It is not an implementation issue.


If you look in old Lisp textbooks, you sometimes find a definition of
Lisp in terms of itself. It usually boils down to (as translated to
PicoLisp):

   (de eval (Exe)
      (cond
         ((num? Exe) Exe)
         ((sym? Exe) (val Exe))
         (T (apply (car Exe) (mapcar eval (cdr Exe)))) ) )

The important thing is the last line: (apply .. (mapcar eval ..))

'apply' and 'eval' go hand in hand. 'apply' expects a list of evaluated
arguments, and passes it to the function in (car Exe).


In PicoLisp, this behavior is exactly the same. The internal difference
is only in implementation, where in PicoLisp (as opposed in other Lisps)
each normal function takes care of evaluating its arguments itself (by
calling an internal 'eval') instead of expecting to get passed already
evaluated arguments. This is faster and more flexible, but as a drawback
'apply' has to revert this internally, and auto-quote the already
evaluated arguments.


But your issue would be the same in every Lisp. Common Lisp avoids
FEXPRs and FSUBRs for that reason, and favours macros, but you have
exactly the same problem if you try to apply a macro to a list.


As a rule, it doesn't make sense to write a library function as an
FEXPR, as in

   (de <xml> Lst
      ... )

A FEXPR is always a terminal stop. You can use FESPRs only at the top
level of a program. There they are convenient, because you don't need to
quote the arguments. But you cannot use them in any useful way, by
calling them from other functions (because you cannot pass arguments
through, being received from the higher levels of your program), let
alone 'apply' them.

(Note that the 'apply' family of functions is much larger, it includes
also all the mapping and filtering functions, in general all functions
that have a 'fun' argument in the reference)


> OK, so what are my options? I'd say:
> 1) try to write a king of «apply» that would work for me,

No. As I tried to explain, this cannot be solved by changing 'apply'.


> 2) rewrite <xml> so that it evaluates its args, then quote the args in
> my calls to it.

Exactly! I would do:

   (de <xml> (Lst)  # See also "lib/xm.l" and "lib/xml.l"
      ... )

and then provide also a quoting function

   (de <xmlq> Lst
      (<xml> Lst) )

giving a convenient frontend function.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to