Hacker News Reader

Comment by phoe-krk | Hacker News Reader

No, McCarthy's original Lisp didn't have numbers. See chapter 5 and the linked footnote 4 of [1].

I guess that the Lisp described by Graham does not describe any mathematical operations, since they aren't really required to construct a metacircular evaluator, which is the selling point of the whole article. You don't need numbers for purely symbolic processing; if absolutely required, you can emulate them using Church encoding. Or you could try and make your Lisp dialect practically useful, and extend it with numeric types and operations.

[1] http://lib.store.yahoo.net/lib/paulgraham/jmc.ps via http://www.paulgraham.com/rootsoflisp.html

View on HN

Church encoding is not the only option, since you already have pairs. So you can use base-1 list encoding, which is what lots of Kilo LISP programs do. Or you can implement natural numbers using lists of digits, which is still inefficient, but probably much faster than Church numerals.

Try this in kilo LISP:

  (load 'src//nmath)
  (times '(1 2 3) '(4))

    * (load 'src//nmath)
    ? undefined: null

You have to first load klsrc which defines objects required by src/nmath:

    * (load 'klsrc)
    t
    * (load 'src//nmath)
    t
    * (times '(1 2 3) '(4))
    (4 9 2)

If you build Kilo LISP using the Makefile, it will load "klsrc" and create the "klisp" image file from it. Without the image file the interpreter is not very useful!

Edit: If you cannot/will not use MAKE, just do

  (load 'klsrc)
  (suspend 'klisp)

After that you do not have to load klsrc any longer.

Right, I just compiled the C file with gcc -o kl kl.c and it seemed to work fine.

What does the times function?

Multiply.

ok, but why 2 * 4 produces a 9?

The list is a list of digits, which combine into a single number (that is: '(1 2 3) == #123). 123 × 4 = 492, so (times #123 #4)) unsurprisingly evaluates to #492 (a.k.a. '(4 9 2)).

A bit funky if you're coming from a Lisp that actually does have numbers that evaluate to themselves, but when it hits you it hits you :)

I wonder if there's any benefit in representing numbers as pairs forming a ring, with some pair arbitrarily designated as 0. This would only work for very small numbers due to being memory wasteful (although the implementation could try to optimize); but on the other hand, CAR/CDR become increment and decrement, and you get wraparound for free.

Reply on news.ycombinator.com