merits of Lisp vs Python

Paul Rubin http
Mon Dec 11 08:25:12 EST 2006


"Alex Mizrahi" <udodenko at users.sourceforge.net> writes:
>  PR> the different macros being used.  But I think I understand one part of
>  PR> what was confusing me before: your call/cc macros depend on a
>  PR> nonstandard feature of some CL implementations.
> 
> no, it's standard Common Lisp. it's an ARNESI library. it's very standard --  

The ARNESI doc at:

  http://common-lisp.net/project/bese/docs/arnesi/html/Automatically_Converting_a_Subset_of_Common_Lisp_to_CPS.html

begins:

    By transforming common lisp code into CPS we allow a restricted form
    of CALL/CC. While we use the name call/cc what we actually provide is
    more like the shift/reset operators (where with-call/cc is reset and
    call/cc is shift).

I don't know what shift/reset are but the above says that call/cc in
the Scheme sense is not really implemented.  There are also a bunch of
limitations on what can be in the call/cc body, e.g. you can't use
unwind-protect.

Anyway, the nonstandard feature is tail call optimization, if you're
turning continuations into closures, and that's just for the simple
case of dealing with loops written in CPS.  E.g.: if you write

   (defun sum_to_n (n &optional (acc 0))
      ;; (sum_to_n n) computes sum of integers from 0 to n
      (if (= n 0)
             0
          (sum_to_n (- 1 n) (+ n acc))))

This function is properly tail recursive (unless I messed up) so with

   (sum_to_n 10000000000)

the CPS version is supposed to return the right answer if you wait
long enough.  It is not allowed to overflow the stack.  This is
guaranteed to work in Scheme but is not guaranteed in CL.  And as I
think we agree, with coroutines it gets even worse.



More information about the Python-list mailing list