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

[Rob Warnock]

Raffael Cavallaro <raffaelcavalla ro@pas-d'espam-s'il-vous-plait-mac.com>:
+---------------
| "George Sakkis" <ge***********@ gmail.comsaid:
| If you mistakenly select an extra parenthesis or omit one, it's
| the same thing.
|
| Because you can't mistakenly select an extra paren or omit one in a
| lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
| don't manually select s-expressions. You put your cursor/point at one
| paren and you tell the editor - with a keystroke or a mouse click - to
| find the matching paren and select everything contained between the two.
+---------------

And for any of you who are rejecting this because you don't want to
learn or use Emacs, Raffael's point is even true in the Vi family of
editors ("nvi" & "vim", at least). The "y%" command yanks (copies)
everything through the matching paren into the anonymous buffer;
"d%" deletes likewise [and saves in the anonymous buffer]; "p" (or "P")
pastes after (or before) the current location. All can be prefixed
with a buffer ("Q-register") name for more flexibility.

Lisp's parens really *do* make editing ever so much easier!
-Rob

-----
Rob Warnock <rp**@rpw3.or g>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 [phone]

[Paddy]

On Dec 13, 8:39 am, [e-mail] (Timofei Shatrov) wrote:

On 12 Dec 2006 18:03:49 -0800, "Paddy" <paddy3...@nets cape.nettried to confuse
everyone with this message:

There are a lot of people that use Wikipedia. I think some of them
might want to learn to program.

I think you misunderstood the goal of Wikipedia. It is not to teach people
programming.

You think wrong. Wikipedia articles get searched and links get
followed. Its good
for some of those to link to articles on Python.

>

I make it easier for them to find
Python by helping to maintain Python within Wikipedia.

If someone wants to find Python, he types "Python" in the search bar and works
from there. He certainly wouldn't end up in "doctest" article.

If someone is looking up comments or testing, then they might well end
up reading
the doctest article. And why not!

Does Lisp have similar?
Is the Lisp community as welcoming?
Do you have to think yourself a genius to join the club?
Is Lisp approachable?

>

Some people dislike Wikipedia which is fine. Some people dislike
Wikipedia and deliberately sabotage it, which is vandalism.

Writing vanity articles about non-notable things is not much better.

Should I have asked you first ;-)
- Paddy.

[Slawomir Nowaczyk]

On Wed, 13 Dec 2006 02:41:29 -0500
Raffael Cavallaro <raffaelcavalla ro@pas-d'espam-s'il-vous-plait-mac.comwrote:

#On 2006-12-12 19:18:10 -0500, "George Sakkis" <ge***********@ gmail.comsaid:
#>
# If you mistakenly select an extra parenthesis or omit one, it's
# the same thing.
#>
#Because you can't mistakenly select an extra paren or omit one in a
#lisp-aware editor.

Sure I can! I think you misunderstood what George said.

(unless (eq 1 2) (if (eql 2 3) (x)) (y))

How is the editor supposed to know whether I want to cut/paste the
s-expression starting with "if" or the one with "eql"?

#Whether its a commercial lisp IDE or emacs, you don't manually select
#s-expressions. You put your cursor/point at one paren and you tell
#the editor - with a keystroke or a mouse click - to find the matching
#paren and select everything contained between the two.

Oh, you mean you have never seen a Python environment which could mark
the current block of code?

--
Best wishes,
Slawomir Nowaczyk
( Sl************* **@cs.lth.se )

Truth is stranger than fiction, because fiction has to make sense.

[Juan R.]

ti********@gmai l.com ha escrito:

FWIW, Python documentation consistently uses the jargon:

() parentheses
{} braces
[] brackets

That matches North American conventions, but occasionally confuses an
international audience (for example, the English call parentheses
"brackets" or "round brackets").

There's also a long tradition in both mathematics and computer science
of using "bracket" as a generic term for any syntactic device used in
pairs.

Brackets are unequal paired syntatic delimiters used for packaging.
Quotations marks "string" or exclamation marks ¡Esto es español! are
used in pairs but not are brackets.

A natural convention is brackets = ( ), [ ], { }, < >

( ) parentheses or round brackets
{ } braces or curly brackets
[ ] box or square brackets
< chevrons or angle brackets

A English calling "brackets" or "round brackets" to the parentheses is
doing nothing wrong, but brackets are not parentheses.

In mathematics the braces are also often called brackets and again that
is not wrong.

[Kay Schluehr]

Juan R. schrieb:

Kay Schluehr wrote:

You mean a universal language adapter? I guess this is always possible
using alpha conversion but I don't believe this leads to theoretical or
practical interesting solutions but is just a limit concept.

Not familiarized with you terminology. I think that i would call that a
universal language composer.

I mean if there exists some theoretical limitation to composionality of
two directly collapsing languages (G1, T1) and (G2, T2) via a
unambiguous modification (e.g. 'renaming') to a third one (G2', T2'),
unknown to me. I mean some theoretical limitation in the sense of known
theoretical limitations to proving theorems in closed formal systems.
After all proving a formal theorem is not very different from
enhacement of a language.

But proving the theorem might be trivial and the implementation
useless. It's like saying you want "universal composition" of two
geometric objects e.g. two manifolds M1, M2 and I write down M3 = M1 x
M2. This is always feasible but this is just not the right kind of
thing in many occasions.

I want to give a practical example. The Python grammar defines a
compound_stmt rule by:

compound_stmt: for_stmt | while_stmt | if_stmt | ...

Now you might add a switch_stmt to G1 and a repeat_stmt to G2

G1: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |...
G2: compound_stmt: for_stmt | while_stmt | if_stmt | repeat_stmt |...

What you actually want in G3 is

G3: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |
repeat_stmt |...

You don't want to rename each statement and mangle each terminal of G2
although this might always be possible. Renaming also negatively
affects the transformer of G2 which precedes composition and is encoded
as Python source. It has to be refactored too when you rename a rule.

So one requirement on a system of composition rules is to drop alpha
conversion which is just a last resort. I guess in any *reasonable*
system of composition rules the question whether G1 and G2 are
composable is decidable and this can also be proofed at least for
certain classes of grammars that are not Turing complete languages by
themselves.

>

The practical problem with composing enhancements is that any two
extensions L1, L2 share a lot of rules and rely on their structure.
What if they don't just extend their host language L0 conservatively
but also redefine rules of L0? This is not just a theoretical problem
but it happens quite naturally if you want to adapt an extension
developed for Python 2.4 for working with Python 2.5. Here Python 2.5
is considered as just another particular extension. Obviously Py3K will
become an interesting testcase for all kinds of syntactical and
semantical transformations .

I would consider redefined-L0 to be L0'. I think that a concept of
namespaces could be also used for versioning-like conflicts:
L0v24:foo(), L0v25:foo(). The problem is that both versions may be
stored and managed during initial period of time. But in the long run
old libraries, extensions... would be updated to the new version.

Sure, but it's preferable to see how far one gets without name mangling
and other crutches.

[Rob Warnock]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrote:
+---------------
| CLTL2 is a model of precision and thoroughness compared
| with any document that's ever been written about Python.
+---------------

It's a great book, but one needs to be clear that CLtL2 is *not*
the same as the ANSI Common Lisp standard, but was the author's
best guess at the time as to where the standardization effort was
going after CLtL1. You may find the following useful in marking up
your copy of CLtL2 to be closer to the final standard:

http://cbbrowne.com/info/commonlisp.html#AEN10499
http://bc.tech.coop/cltl2-ansi.htm

But note the caveat therein:

A doctored CLTL2 is NOT the ANSI standard. In fact,
this FAQ has many known but minor omissions that are
too awkward to add with pencil to CLTL2.

The Common Lisp HyperSpec (CLHS), while also not the official
ANSI standard per se, was created from "the same" TeX input as
the ANSI standard (with permission from ANSI & X3), and is the
reference most CL programmers use:

http://www.lisp.org/HyperSpec/FrontMatter/index.html
http://www.lispworks.com/documentati...ront/index.htm

For a downloadable tarball of the whole thing, there's a link near
the bottom of this page:

http://www.lispworks.com/documentati...pec/index.html
-Rob

-----
Rob Warnock <rp**@rpw3.or g>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 [phone]

[Pascal Bourguignon]

Christophe <ch************ *@free.frwrites :

Robert Uhl a écrit :

>aa**@pythoncraf t.com (Aahz) writes:

>>Consider this: Lisp has had years of development, it has had millions of
dollars thrown at it by VC firms -- and yet Python is winning over Lisp
programmers . Think about it.

The argument from popularity is invalid. French units have overtaken
standard units,

Never heard of that French unit thing. Unless you talk about that
archaic unit system that was in use before the metric system was
created.

Who invented the metric system?

--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!

[Christophe]

jo************@ hotmail.com a écrit :

Bjoern Schliessmann wrote:

>Robert Uhl wrote:

>>Because it's the language for which indentation is automatically
determinabl e. That is, one can copy/paste a chunk of code, hit a
key and suddenly everything is nicely indented.

Cool, so in other languages I need to set block marks like () and {}
and also indent the code for readability, and in Python I indent
only. From my POV that's less work.

Try reading again. In Lisp, you use () and *your editor* automatically
indents according to the universal standard, or you leave it sloppy
until other folks reading your code convince you to get a proper
programming editor. Indentation does not get out of sync with semantics
because the editor virtually never misses parentheses that the Lisp
compiler sees. Expressions keep the same meaning even if you have to
start breaking them across lines, etc.

In Python, you group in your mind, and press indentation keys to make
it happen in your editor. The editor cannot help that much, because it
cannot read your mind. White space screwups in copy-paste cannot be
fixed by the editor automatically, because it cannot read the original
programmer's mind, and you have to fix it manually, and risk screwing
it up.

Call us when you have an editor that reads your mind and writes the ()
for you.

[hit_the_lights]

Paul Rubin schrieb:

Neil Cerutti <ho*****@yahoo. comwrites:

Is the above 'duck-typing' idiom considered very useful to a
Lisper? It seems logical to me that duck-typing works best in an
environment where it is ubiquitous. If users have to implement
accessors specifically to use your library, it is not as good as
if they had already implemented one as a matter of routine.

No, it's not as ubiquitious as in Python. I guess that has many
different reasons, probably many historical. IIRC Peter Seibel
writes in Practical Common Lisp that CLOS (and thus "defgeneric ")
was introduced late in the CL standardization process. That my be
one reason why it is not used extensively by the rest of the
standardized language.

It's a little more complicated than that, the classes involved have to
have special interfaces to tell setf/getf what to do, sort of a
compile time equivalent of __setattr__/__getattr__ if I remember right.

The code I've posted is all you need. You can specialize it for any
class (including numbers, functions, symbols etc.) you like.

In case of the lookup "($ a 0)" there is nothing done at compile
time, it's just a call of the generic function "$".

"(setf ($ a 0) 1)" is translated at compile time (setf is a macro)
to something like "(funcall #'(setf $) 1 a 0)".

[John Thingstad]

On Wed, 13 Dec 2006 03:13:26 +0100, Paddy <pa*******@nets cape.netwrote:

Not even close.

In my example above:
for a in y:
dosomethingwith (a)
y could be a lot of built-in types such as an array, list, tuple, dict,
file, or set.
- Paddy.

I was refering to the recursive Lisp example.
Did you even read the post?

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/