[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (none)

In article <SIMON.90Feb7120454@viking.cs.tu-berlin.de> simon@opal.tu-berlin.de (Simon Leinen) writes:
$In article <9002051741.AA03862@heike.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
$This is why Lisp (or Scheme) programmers change a definition like
$	(define fac (lambda (n)
$	  (if (= n 0)
$	      1
$	    (* n (fac (- n 1)))))) ; tail-call to *, but not to fac
$into the less obvious, but more efficient
$	(define fac (lambda (n)
$	  (letrec ((fac-aux (lambda (n acc)
$	             (if (= n 0)
$	                 acc
$	               (fac-aux (- n 1) (* n acc)))))) ; tail-call to fac-aux
$	    (fac-aux n 1))))
$Unfortunately, most existing compilers don't perform this optimization

"Unfortunately"?  I wouldn't want the compiler to perform this
optimization, for if you unwind the *-calls, you'll find the
non-tail-rec version does (* n (* n-1 (* n-2 ... 1))), while the
tail-rec one does (* 1 (* 2 (* 3 ... (* n 1)))).  The optimization
hinges too much on the commutativity of * for my comfort.

$     Today I asked a professsor and a doctor here at UniDo but both
$     couldn't help me.
$Don't expect any professor in this country to be able to help you.
$Lisp wird in Deutschland einfach nicht ernstgenommen.

(I guess you mean Scheme rather than Lisp, since none of the (other)
Lisps bother even about tail-call optimization, not to speak of the
optimizations that Holger and you speak of.)

I thought Elk was Made in Germany.  So schlimm kann es doch nicht

$Viele Gruesse und happy LISPing,

It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.