merits of Lisp vs Python

[Ken Tilton]

greg wrote:
> Ken Tilton wrote:
> 
>> McCarthy: "Is code also data in Python?"
>> Norvig: "No."
> 
> 
> I don't think that was the right answer.

Norvig is a smart guy. He was talking to John McCarthy. He gave the 
right answer. :)

> He should have
> said "Yes", and then shown McCarthy eval() and exec.

No, in those cases the Python interpreter is still dealing with the 
code, not the user's application code. As a meta-developer (to coin a 
word) I want to be able to write code that takes apart other code I 
write to do useful things with it /without writing a parser for my 
chosen language/. I just found a bug in ACL that might be instructive.

The defskill macro I have been writing might be coded like this:

(defskill abs-value
    (category "Algebra I" "Real Numbers")
    ....)

(I am kinda mirroring defclass here, which looks like:

(defclass <name> <superclasses>*
   (<slot-defs>*)
   ...and then optional sub-specs each keyed by the first symbol..
   (:documentation "chya")
   (:metaclass...)
   (:default-initargs)))

Come to think of it, I might have made /my/ options :keywords just to 
make the resemblance stronger (and yes I am digressing into the bit 
about how Lispniks by convention stay recognizable with new syntax).

Anyway, I decided to do a little auto QA and add an assertion to make 
sure I did not inadvertently leave out the category option (long story, 
I am not usually so anal), so defskill starts like this:

(defmacro defskill (id &body skill-info)
   (assert (find 'category skill-info :key 'car))...

That is just normal list code. The macro signature destructures the code 
I write inside the defskill invocation into an id and a list of 
following code ("&body skill-info" says "bind the rest of the code to 
the local variable skill-info as a list"). the (find ... :key 'car) 
walks down the list taking the car (first) of each list and comparing 
against that which is being sought. Simple ol' Lisp.

I then expand the (somewhat) validated data/code:

      (loop with sub-id = id
              for (q . q-def) in skill-info
              collecting
              (ecase q
                (category <return desired Lisp code>)
         ...etc...)

q for "quality" or "attribrute". Not "o" for option. :) Again, using 
standard loop destructuring on the option code/data.

Y'all need to get over it: we really are writing code that eats 
code/data to produce code. Unaided by any parser other than the same 
destructuring mechanisms we use on data.

ken

ps. I forgot the bug. I coded in the end:

   (defskill |Absolute Value| ...etc..)

Where |absolute value| should be treated as a single symbol, and is by 
the ACL compiler. An interactive macroexpand, however, misses that that 
is one symbol and defskill (if you followed the Lisp) dies trying to 
take the car of the atom VALUE (a symbol). k