merits of Lisp vs Python

[Mark Tarver]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

[Paul Rubin]

André Thieme <ad************ *************** *@justmail.dewr ites:

But there would be even more tokens, the lines going between the
nodes
in the trees, for example.

These are painted by the editor.

If you have to tell the editor where to put them, they are tokens.

[Paul Rubin]

André Thieme <ad************ *************** *@justmail.dewr ites:

How complicated ss it to say "cmp(a, b)" compared to "a cmp b"?

It gets worse when the expressions are nested.

So instead of
cmp(foo(a, b, c), bar(x, y, z)) you would prefer
foo(a, b, c) cmp bar(x, y, z) ?

Don't be silly. Some operators are more natural as infix and others
as functions. It's just like in natural language. People have an
innate ability to make such distinctions and it's fine for a
programming language to use it.

[Kirk Sluder]

In article <7x************ @ruckus.brouhah a.com>,
Paul Rubin <http://ph****@NOSPAM.i nvalidwrote:

Don't be silly. Some operators are more natural as infix and others
as functions. It's just like in natural language. People have an
innate ability to make such distinctions and it's fine for a
programming language to use it.

I don't think you can really make this case. In English, German and
Spanish noun-verb order is flexible to accommodate differences in
mood, tense, and emphasis:
"Add 2 and 2." imperative.
"The sum of 2 and 2" noun phrase.
"2 was added to 2." passive voice.

Personally, I've always preferred use the imperative to describe
basic math rather than the passive. This would seem to map better to
RPN than infix.

And on top of that, some languages are even more flexible in regard
to word order, preferring to communicate relationships through the
modification of noun stems. In such a language, "He* her- the ring+
gave," is just as valid as "Her- the ring+ gave he*" and "He* gave
her- the ring+." ("+/-/*" signifying modifications which do not
exist in modern English.)

At any rate, I find this argument to be weak given that English
doesn't always use the same word order. And English is just one
language out of hundreds.

[Paul Rubin]

Kirk Sluder <ki**@nospam.jo bsluder.netwrit es:

Personally, I've always preferred use the imperative to describe
basic math rather than the passive. This would seem to map better to
RPN than infix.

For writing down complicated, nested expressions too? That's very
unusual. E.g.

n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...

vs. the same thing in Lisp notation, and that's not even so complicated.

[greg]

Ken Tilton wrote:

McCarthy: "Is code also data in Python?"
Norvig: "No."

I don't think that was the right answer. He should have
said "Yes", and then shown McCarthy eval() and exec.

Code isn't quite as *convenient* to work with as data
in Python as it is in Lisp, but that doesn't mean it
can't be done.

(I agree that the proffered example was not an instance
of "code is data", though.)

--
Greg

[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<superclas ses>*
(<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

[greg]

Ken Tilton wrote:

I think your brain is stuck on flaming.

Sorry, I didn't mean to come across as flaming, far
from it. I'll take a deep breath before posting from
now on, I promise. :-)

I did explain the last little fun bit (where reverse code miraculously
got a case-specific "signed-value" parameter bound to exactly the right
bit of math structure).

I didn't mention that because it was addressed by
another poster. The signature of the user's reverse
function can be made extremely flexible if you have
the foresight to define it as something like

def reverse(resx, opnd, **kwds):
...

Then you can later change it to

def reverse(resx, opnd, signed_value, **kwds):
...

and any existing reverse functions will just absorb
and ignore the extra argument.

However, rather than add an ever-increasing number
of arguments to the signature, I think I would do it
a different way: pass a single object with attributes.
For the want of a better name, let's call it "env"
for "environmen t". The signature is then

def reverse(env):
...

and the body can refer to env.resx, env.opnd,
env.signed_valu e, or whatever else is required.

If this still doesn't cover the requirements, please
explain and I'll try to adapt it accordingly.

--
Greg

[greg]

André Thieme wrote:

(aif (timeConsumingC alculation)
(use it))

I think the answer is that you just wouldn't do
that in Python at all. Having magic variables
spring into existence in your local namespace
as a side effect of calling something is just
not Pythonic. (It is very Perlish, on the other
hand.)

The closest you might come is using the new
"with" statement like this:

with aif(timeConsumi ngCalculation() ) as it:
use(it)

where the object returned by aif(x) has an
__enter__ method that raises an exception which
aborts the whole with statement if x is None,
thus avoiding executing the body. But that's
so horribly convoluted that any sane programmer
would just write it out the straightforward
way to begin with.

There's a Haskell builtin called 'seq' which forces evaluation but
again I'm not sure precisely how to apply it here.

So in some languages that support functional programming one needs to do
extra work to get lazyness, while in Haskell one gets extra work if one
doesn't want it.

Sort of, but it's more so that you can write code
that does things like I/O in what looks like a
procedural style, even though it's still purely
functional. Read about "monads" if you want to
know more -- it's truly mind-expanding (and
possibly head-exploding:-) stuff...

--
Greg

[greg]

André Thieme wrote:

The thing with most (if not all) programming languages other than Lisp
is: these abstractions are leaky.
They have a low level knowledge leak. Users of aif need to know how to
pass in arguments. As you see he had do embed the code that needs execution
into a block (anon function) and then use this special syntax for x.

Yes, but all the standard looping constructs, etc.
in Ruby are expressed like this too. So it's
perfectly consistent with the rest of the language.
It's not something new that the user needs to learn
just to use this function.

This is even more evident in Smalltalk, where
*all* control structures, without exception, are
expressed in terms of code blocks, possibly
with parameters. And Smalltalk has no macros,
either, btw.

--
Greg

[greg]

André Thieme wrote:

So instead of
cmp(foo(a, b, c), bar(x, y, z)) you would prefer
foo(a, b, c) cmp bar(x, y, z) ?

Incidentally, someone once came up with an fiendishly
clever hack that lets you write things in Python like

foo(a, b, c) |kmp| bar(x, y, z)

i.e. effectively define your own infix operators. And
it doesn't even require a macro. :-)

(Finding the trick to implementing this is left as an
exercise for the googler.)

--
Greg