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

[André Thieme]

Paul Rubin schrieb:

Steven D'Aprano <st***@REMOVE.T HIS.cybersource .com.auwrites:

>Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

Macros let you write what amounts to functions that don't evaluate
their arguments. Think of the endless clpy wars over the ternary
conditional operator. You want to write something like

def ternary(test, iftrue, iffalse):
if test: return iftrue
else iffalse

but because of side effects, you don't want

a = cond(test, f(x), g(x))

to evaluate both f and g. That is trivial to do with a macro but
can't be done with a function.

I think you could do that with functional programming.
You can protect the evaluation by encapsulating the args in a function
object?
def f_Args(x):
return x

def g_Args(x):
return x
and then
a = cond(test, f, g, f_Args(x), g_Args(x))

if you adopt cond. But of course it is getting ugly.
So a macro can free you from this extra code.
André
--

[Bill Atkins]

greg <gr**@cosc.cant erbury.ac.nzwri tes:

JS******@gmail. com wrote:

>compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code.

There's no way you could compile Python to efficient
machine code just by macro expansion. You'd also need
some very heavy-duty type inferencing.

When I used to use Ruby a lot, I believed this line that the Ruby
community fed itself (and apparently Python feeds itself as well):
Ruby/Python has to be interpreted because it's too dynamic. This is
wrong, of course. A compiler shifts a lot of decisions that an
interpreter would have to make at runtime to compile-time. There is
no reason a dynamic language can't enjoy this efficiency. On the
other hand, if Python is doing a hash lookup on every function call,
as Alex Mizrahi claims, compilation may not do much to smooth over
such awkwardness.

Python is extremely dynamic, even more so than Lisp.
That's why compiling Python is hard, not because it
doesn't have macros.

Uh huh. "More so than Lisp"? Just making stuff up now?

Despite its dynamism, Lisp is quite compilable. For example, I can
redefine classes, functions, macros, etc. at runtime and compiled code
referring to the old code will still work. You are conflating
dynamism with interpretedness , and that's incorrect.

[Bill Atkins]

greg <gr**@cosc.cant erbury.ac.nzwri tes:

When moving a set of statements in Python, you
are usually selecting a set of complete lines,
cutting them out and then pasting them in
between two other lines somewhere else.

You're missing Ken's point, which is that in Lisp an s-expression
represents a single concept - I can cut out the second form of an IF
and know that I'm cutting the entire test-form. I don't have to
choose the correct "set of complete lines" to correctly move code
around.

Having edited both Lisp and Python code fairly
extensively, I can't say that I find editing
Python code to be any more difficult or error
prone.

How extensively?

On the plus side, Python makes less demands on the
capabilities of the editor. All you really need
is block-shifting commands. Bracket matching is
handy for expressions but not vital, and you
certainly don't need bracket-based auto-indenting.

Oh, please. So we should restrict the power of the languages we
choose just to make sure that our code can be edited in Notepad?

[Juan R.]

ph************* @gmail.com ha escrito:

Juan R. wrote:

ph************* @gmail.com ha escrito:

- Lisp is hard to learn (because of all those parenthesis)

I cannot understand why. It is like if you claim that packaging things
in boxes is difficult to learn.

HTML and XML have more brackets than LISP (usually double) for
structuring data and everyone has learned HTML.

I think maybe you missed the point I was making.

Yes i did, sorry

To make it clearer I'm saying that the arguments that are being made
over and over again against Lisp in this thread have been the
antithesis of my experience since moving from Python to Lisp.

I just prefer personal experience to popular misconceptions :-)

I often count 'parentheses' used in other approaches.

E.g. the LISP-based

[HTML [@:XMLNS http://www.w3.org/1999/xhtml]
[HEAD
[TITLE Test page]]
[BODY]]

is SLiP (Python)

html(xmlns="htt p://www.w3.org/1999/xhtml"):
head():
title(): "Test page"
body():

LISP-based:
5 (
5 )
1 @
1 :

Python:
4 (
4 )
1 =
4 "
4 :

[Kay Schluehr]

JS******@gmail. com schrieb:

Now, speaking as a scientist, permit me to make a small practical
suggestion: Why not just figure out a way to simplify some brand of
Python -- make parens (or whatever) optionally replace whitespace and
line breaks as syntax -- and then add a simple macro facility -- macros
are actually a very simple extension if you have homogenous syntax,
homogenizing your syntax to the point where macros are possible is the
hard part -- and just see what happens.

The problem is not so much to add a macro facility ( or source
transformer ) but to soften it and make the macro facility actually
*simple* to use. Note that you don't need to replace whitespaces. The
Python parser is LL(1) and whitespace is almost completely abstracted
away once the Python source was tokenized successfully ( there is
exactly one non-terminal in the Python grammar, the "suite" NT, that
uses INDENT and DEDENT as moral equivalents for left- and right parens
). Note also that a homogenous syntax is not that important when
analyzing parse trees ( on the contrary, the more different structures
the better ) but when synthesizing new ones by fitting different
fragments of them together.

There are two basic approaches. In one you start with a piece of source
code ( a template ) and enhance the source description slightly with
somewhat like template parameters that keep source fragments and expand
them. In this case you also need an unquoting mechanism or a way to
evaluate code within the template. The second approach acts with high
level wrappers of more low level source trees ( just like ASTs are high
level wrappers of concrete syntax trees in most languages ). In Python
one might even use operator overloading to hide the AST structure and
provide a more convenient syntax.

But this only describes the transformationa l aspect. The definitional
part is not less important. I try to consider a grammar description of
a full programming language as as script in an own little language (
actually it is and the grammars grammar is often just an EBNF grammar
description ). This however presumes that enhancing grammars to enhance
languages is a reasonable approach not just in a Lex-Yacc ( or ANTLR )
setting. The next question concerns compositionalit y of language
enhancements or composition of even completely independent language
definitions and transformers both on source and on binary level. While
this is not feasible in general without creating ambiguities, I believe
this problem can be reduced to ambiguity detection in the underlying
grammars.

One of two general things are
likely to happen: Either people will not use them, and they will
languish and die, and then at least you can say; "Been there, done
that" to the Lisp community. Or, more likely, the some subset of the
Python community will get it, and will figure out how useful they are,
although it might take some time. And then you might find yourself with
a wonderful new tool.

I think so too.

You might even get a compiler out of the deal, at
a pretty low cost, too! If you get macros, and get a compiler, I'm
pretty sure that you will have no problem winning over the Lisp
community, who would LOVE to have your extensive libraries, and that
you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)

Just a moment ago you called programmers of other languages "flies"
which I found annoying and now you offer LOVE in big letters? I don't
even think the "competitio n" to Ruby matters. Once an easy to use
metaprogramming system could be done for Python it could be ported with
some adaptions to other languages with more "complicate d syntax" ( non
LL(1) parsable ).

Kay

[Paddy]

On Dec 11, 2:17 pm, Bill Atkins <[e-mail] wrote:

"Paddy" <paddy3...@nets cape.netwrites:

JShra...@gmail. com wrote:

Python has to rely more on using the right algorithm...

This sound familiar: "Macros are dangerous!"

Yes. I changed my opinion on advocating Python having macros in one
of our long threads on the subject. Maintainance counts.Yes, it does, but that should take you to exactly the opposite

conclusion.

I won't duplicate the arguments against macros made elsewhere in the
thread.

>

"Compilers make you lazy."

This is new to me. In fact, for the compiled languages available to me.
Using them *first* would be the difficult choice.These are not real sentences, but if you're saying that compiled

languages make programming more difficult, then you're simply using
the wrong compiled languages. Lisp is a dynamic language that also
supports compilation to native code.

Lisp was not a compiled language available to me, and even after my use
of Cadence Skill, I would not consider Lisp for writing an extension
unless Lisp had a library close to what I wanted, and there was a good
way to link
Python to the compiled Lisp code.

>

Unlike Lisp, Python does not have a ubiquitous compiler. It is
therefore
made to interface nicely with compiled languages. Other compiledWhat on earth does this mean? You're saying that because Python

doesn't have a compiler, it can interface more easily to compiled
languages? That's nonsense.

No. I am saying that *because* it does not have a compiler, it has been
*made to* integrate nicely with compiled languages; and further, I am
saying that because some compiled language package maintainers see the
advantages of using dynamic languages, they support Python integration.

>
Further, most Lisp implementations support an interface to C that
doesn't require you to write and compile C code in order to use C
extensions in Lisp. Can Python do the same more "nicely" than Lisp?

Python does the same. It might well be nicer but I do not know how Lisp
does this.
http://docs.python.org/dev/lib/module-ctypes.html
http://www.boost.org/libs/python/doc/
http://www.python.org/pypi/pyobjc/1.3.5
(The last is used within Apple for some aspects of development).
The above list is not exhaustive

>

language users see the need for dynamic interpreted languages like
Python and maintain links Python such as the Boost Python C++
wrapper. IronPython for .NET, Jython for Java.
Lisp is its own interpreter and compiler, which should be a great
advantage, but only if you don't make the mistake of ignoring the
wealth of code out there that is written in other languages.

Um.

Yep.

- Paddy.

[Paul Rubin]

Bill Atkins <at****@rpi.edu writes:

There's no way you could compile Python to efficient
machine code just by macro expansion. You'd also need
some very heavy-duty type inferencing.

When I used to use Ruby a lot, I believed this line that the Ruby
community fed itself (and apparently Python feeds itself as well):
Ruby/Python has to be interpreted because it's too dynamic.

I don't think you can reasonably compile Python just by what we'd
usually call macro expansion. You need fancier compiler techniques.

Python is extremely dynamic, even more so than Lisp.
That's why compiling Python is hard, not because it
doesn't have macros.

Uh huh. "More so than Lisp"? Just making stuff up now?

Python is more dynamic than Lisp.

Despite its dynamism, Lisp is quite compilable.

Yes. Lisp is dynamic, but less so than Python. And not by
coincidence, Lisp is more compilable than Python.

For example, I can redefine classes, functions, macros, etc. at
runtime and compiled code referring to the old code will still work.
You are conflating dynamism with interpretedness , and that's
incorrect.

If you say foo.frob() in Python, that's supposed to look up 'frob' in
a dictionary hanging off of foo. You can modify the contents of this
dictionary any time you want. The Lisp equivalent would be some
generic function (frob foo) that you define with CLOS in the usual
way, but then there's some hashtable that lets you redefine frob at
any time by modifying it (i.e. just a normal hashtable that you poke
with setf, no special notification to the class system). This can
happen anywhere in the code, in another thread, or whatever. You can
even replace that hashtable with another hashtable. You can also
insert (at any time) a __getattr__ method into foo's class, that is a
user-supplied function that replaces the hash lookup.

This stuff is all quite hard to optimize the way CLOS can be
optimized. I'd like to hope Python tones down these aspects of its
dynamism as it continues to evolve.

[Marc 'BlackJack' Rintsch]

In <11************ **********@n67g 2000cwd.googleg roups.com>, Kay Schluehr
wrote:

Once an easy to use metaprogramming system could be done for Python it
could be ported with some adaptions to other languages with more
"complicate d syntax" ( non LL(1) parsable ).

FYI: Here's how Nemerle does macros: http://nemerle.org/Macros

I guess you can't really transform Nemerle into a completely different
language, but it is at least interesting to see such a feature in language
with a more complex syntax than Lisp.

Ciao,
Marc 'BlackJack' Rintsch

[Espen Vestre]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrites:

If you say foo.frob() in Python, that's supposed to look up 'frob' in
a dictionary hanging off of foo. You can modify the contents of this
dictionary any time you want.

You can redefine CLOS methods at run time any time you like, so this
doesn't make Python more /dynamic/ than CLOS. Maybe you should replace
"more dynamic" with "less managable", if that's what you mean?
--
(espen)

[Jan Dries]

Bill Atkins wrote:

greg <gr**@cosc.cant erbury.ac.nzwri tes:

>On the plus side, Python makes less demands on the
capabilities of the editor. All you really need
is block-shifting commands. Bracket matching is
handy for expressions but not vital, and you
certainly don't need bracket-based auto-indenting.

Oh, please. So we should restrict the power of the languages we
choose just to make sure that our code can be edited in Notepad?

Perhaps not. The use of a decent editor seems a fair requirement for any
language. But one of the things that I dislike about Java, .NET and to
some extent XML (XML Schema for instance), is that the only way to
really be productive in these languages/environments is to use tools
that generate or otherwise manage huge amounts of code for you based on
whatever GUI settings. If the language is so complex or verbose that you
can't really use it without a GUI tool, then why bother having a
language in the first place. Furthermore these tools are typically
expensive and to run comfortably they require more processing power and
memory than the lightweight ultra-portable type laptops that I like so
much can provide.

I can't speak about Lisp, but the great thing about Python, IMHO, is
that you can get quite far with not much more than Notepad. I find this
important because I find GUIs a very tedious and ineffective way to
describe whatever it is that I am trying to implement.

Perhaps I'm just getting old ...

Regards,
Jan