Why don't people like lisp?

[Andrew Dalke]

Peter Seibel:
> Okay, here's a Common Lisp version. Because Lisp functions take either
> keyword or positional arguments, I choose to make the generated
> functions use keyword arguments. But the variables are gathered in the
> right order, so take out the '&key' below to use positional arguments:

Cool code.  I like that it identifies some of the error locations.

>   * (funcall (compile-rpn "a b +") :a "foo" :b 2)
>   Error: `"foo"' is not of the expected type `NUMBER'

My Python code reports a line number for this.  I figured it
would be harder for simple Lisp code to do the same.  But
that's because I'm cheating; the Python stack trace normally
reports the line number so I get most of it for free.  I suspect
it would be more complicated if the spec said to report the
line number *and* character position of the operator which
failed.

(Not all that hard though; I can use a new object
class Add:
  def __init__(self, lineno, charpos):
     self.lineno = lineno
     self.charpos = charpos
  def __call__(self, left, right):
      try:
        return left + right
      except:
        ... report the error location ...

and make the code look like

  Mult(4, 2)(3.0, Add(1, 30)(a, 1) + 9.8)

but if I'm making a native Python function which doesn't
manipulate its own stack then it's probably for the speed,
and the above will be slow.)


In my reply to Erann Gat I noted that his eval approach
might exclude the possibility of using names like 'a)' as identifiers.
(I don't know if it does, because I don't know enough Lisp.)

My AST solution could easily be changed to support that
case, as well as variable like ";;b" and "#c" and ":d:".

I'll ask the same of you.  Does your code require that the
RPN names also be valid Lisp tokens?  If so, what happens
if it isn't?

(Looking at it, the key line is
>              ((not tok)               (return `(lambda (&key ,@(nreverse
variables)) (prog1 , at stack))))

but I don't know what @() does nor what happens if a "strange"
value is used as the list of keywords)

> And for grins here's the x86 machine code generated for the first
function:

I was never any good at Intel assembly, and I thankfully haven't
touched it in about 15 years.  I was trying to figure out if it
optimized the additions into 15**a, but I could see neither the
sequence 1, 2, 3, 4, 5 nor the value 15 (octal 17, hex F) anywhere
in the code.  Pointers?

                    Andrew
                    dalke at dalkescientific.com