13 comments

[ 2.8 ms ] story [ 42.7 ms ] thread
Thus, yet again, sort-of-validating Greenspun's 10th Rule.

I'm not complaining... just observing :).

As much as I love a good Greenspun invocation, I don't think this really counts:

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

isn't about the inevitability of literally implementing a Lisp interpreter.

It's about something more abstract. see: http://c2.com/cgi-bin/wiki?LevelsOfGreenspunning

Mostly agreed. Which is why I said "sort-of-validating".

... so that I would be technically correct. Which, as we all know, is the best kind of correct. (Source: Futurama)

It's still got a good shot at validating Zawinski's Law of Software Envelopment.

> Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

I will now write all my comment in Kanjis. It's too beautiful.
Why does the foldl function use a while loop?
I think it's just manual tail-call optimization?
Why not? map, fold/reduce are not necessarily implemented as the textbook says.
Certainly not. The foldl is a part of the TypeScript program that implements the Lisp.

By the way, as for "while" in the implemented Lisp, it is defined with recursion and will be executed with tail-call optimization. See

  (defmacro while (test &rest body)
    (let ((loop (gensym)))
      `(letrec ((,loop (lambda () (cond (,test ,@body (,loop))))))
         (,loop))))
in the const prelude of lisp.ts (http://www.oki-osk.jp/esc/typescript/lisp/lisp.ts.html).
Thanks for this information.

My point was more that map and reduce do not inherently require a recursive implementation and can be implemented directly as loops.

I don't follow closely TypeScript: is tail-call merging done when compiling to Javascript or is the Javascript runtime responsible for this behavior?