Any advantage in LISPs having simpler grammars than Python?

S

seberino

Is there any advantage to a language having a nice mathematically
compact grammar like LISP does? (or at least used to?)

Many have admired the mathematically simple grammar of LISP
in which much of the language is built up from conses IIRC.

Python's grammar seems complicated by comparison.

Is this anything to worry about?

Chris
 
G

Grant Edwards

Is there any advantage to a language having a nice mathematically
compact grammar like LISP does? (or at least used to?)

Yes. Grammars like LISP's make it easy for programs to
generate and read code. Grammars like Python's make it easy for
humans to generate and read code.
Many have admired the mathematically simple grammar of LISP
in which much of the language is built up from conses IIRC.

Python's grammar seems complicated by comparison.

People are pretty good at complicated grammars if they're well
designed (people seem to like grammars with a fair bit of
redundancy), and can be amazingly bad at simple grammars.
Is this anything to worry about?

That depends. Are you a computer program or a person? If the
former, LISP is definitely for you. If the latter, then I'd
recommend Python.

(And I used to write real-world apps in Scheme before I
discovered Python).
 
D

Douglas Alan

Terry Hancock said:
I think experienced Lisp programmers must learn to visually parse
the *words* in the Lisp program to determine the structure, but I
find that really unhelpful, myself.

Experienced Lisp programmers use indentation to visually parse the
program structure, just like Python programmers do for Python.
Experienced Lisp programmers learn to not see the parentheses when
they don't need to.

When I did a lot of Lisp programming, I often felt that it would be
kind of nice to have a version of Lisp that would infer many of the
parentheses from indentation, so that you could elide most of them.
But then again, the parentheses are very easy for an experienced Lisp
programmer to ignore, so such a change would have been a very hard
sell.

|>oug
 
T

Terry Hancock

Is there any advantage to a language having a nice mathematically
compact grammar like LISP does? (or at least used to?)
Many have admired the mathematically simple grammar of LISP
in which much of the language is built up from conses IIRC.
Python's grammar seems complicated by comparison.

Is this anything to worry about?

Certainly I'm not going to lose any sleep over it. ;-)

I think the cool thing about Lisp's tiny grammar is that it
proves you can make a grammar that small work. It's
minimalist to the extreme.

The trouble is, while it may be easy for the machine to parse,
it isn't the machine's clerical ability we are worried about!

Ultimately any such determination is aesthetic, so there will
inevitably be disagreement, but for some of us, at least, the
Python syntax is a much better balance between simplicity and
adequate discrimination and visual cues.

Perl, for example, is much further along on that spectrum -- it
has a large number of "punctuation" symbols (symbolic operators,
really). Lots of "visual cues", but it's not simple at all.

The nice thing about symbolic operators is that they are very
compact and very easy to distinguish from one another. The bad
thing about them is that they are not as easy to remember as
words, and they are very difficult to look up, compared to
words. Therefore, you have to "just know" what they mean.

Or rather -- learning them is part of comprehending the core
language, as opposed to something you learn as you go along.

Word symbols, like Python's keywords, standard library functions,
classes, and methods are easier to look up in the manual if you
get stuck. They also put user constructs on a much more even
footing with things built into the language. So -- I don't have
to write a PEP if I just want a useful feature I can implement
in a module. Using that approach, I can construct a "domain
specific language" in python or lisp. In a way, that's what all
modules do (at least they allow you to expand the vocabulary of
the language, though most leave the grammar alone).

Lisp gives you that kind of power to the nines. It lets you
rewrite the vocabulary, grammar, and whatever to get the job
done the way you want.

And then people use it. And that leaves you, as the end user, to
learn a new language for each application. And the extremely
limited grammar means that there are few visual cues to sort out
what is part of Lisp, what is part of a library, and what is your
own code. It's like a paper without hierarchical heading styles.
You can read it, but it's not as easy as one which is structured
with visual cues as to what is a heading, what is a section number,
what is emphasized, etc.

Some people apparently love Lisp, but I really could never get
over the nested parentheses making my eyes cross. ;-)

I think experienced Lisp programmers must learn to visually
parse the *words* in the Lisp program to determine the structure,
but I find that really unhelpful, myself.

Remember that you *can* represent your program with nothing but
two characters, "0" and "1" -- even simpler than Lisp. That
doesn't mean that that's the "preferred form for editing" it. ;-)

Cheers,
Terry
 
P

Paul Rubin

Douglas Alan said:
Experienced Lisp programmers use indentation to visually parse the
program structure, just like Python programmers do for Python.
Experienced Lisp programmers learn to not see the parentheses when
they don't need to.


The OP might find this interesting: http://www.norvig.com/python-lisp.html
When I did a lot of Lisp programming, I often felt that it would be
kind of nice to have a version of Lisp that would infer many of the
parentheses from indentation, so that you could elide most of them.
But then again, the parentheses are very easy for an experienced Lisp
programmer to ignore, so such a change would have been a very hard
sell.

"Super parens" were present in a few old Lisp dialects but these days
I think most Lisp programmers use editors that balance regular parens
automatically, so that when you type a closing paren, the editor
highlights the matching open paren or the cursor briefly visits it.
RMS first implemented this feature in the 1970's or so, and says that
within weeks of starting to use it, he lost the ability to count
parentheses manually. He inferred that since he lost the ability so
fast, counting parentheses must have been taking up a considerable
amount of his mental resources, which were now freed up for other
things.

With automatic paren balancing, the parentheses in Lisp aren't really
bothersome. Lisp itself (to me at least) has gotten to feel clunky
and old-fashioned over the years. Of course, a new incarnation could
appear.

www.lemonodor.com is a good blog where Lisp geeks hang out. Lots of
interesting things (not just Lisp related) get posted there.
 
D

Douglas Alan

Yes, Lisp's syntax allows for a very powerful macro mechanism that is
extremely useful.
Yes. Grammars like LISP's make it easy for programs to generate and
read code. Grammars like Python's make it easy for humans to
generate and read code.

I find Lisp to be perfectly readable. In fact, in some ways I find it
to be more readable than any other language, including Python. I
like, for instance, the prefix notation, since then I can identify the
sort of expression that I am looking at without having to look ahead
into the expression.

For instance, if Python were to have been designed so that you would
write:

let myVeryLongVariableName = 3

I would have preferred this over

myVeryLongVariableName = 3

With the latter, I have to scan down the line to see that this line is
in an assignment statement.

(This problem is significantly worse in C++, where variable
declarations can be rather difficult to visually parse, unless all
classes begin with capital letters and nothing else does.)

No, not really. Not unless you want a powerful macro facility or you
want to programmatically analyze or manipulate your software.

|>oug
 
S

Simo Melenius

Grant Edwards said:
Yes. Grammars like LISP's make it easy for programs to
generate and read code. Grammars like Python's make it easy for
humans to generate and read code.

The above statement sounds too generalized to me. IMHO it's more of a
matter of preference, your mindset and what you're accustomed to.


br,
S
 
C

Carl Banks

Douglas said:
For instance, if Python were to have been designed so that you would
write:

let myVeryLongVariableName = 3

I would have preferred this over

myVeryLongVariableName = 3

With the latter, I have to scan down the line to see that this line is
in an assignment statement.

Interesting. I always found that the visual distinctness of non-Lisp
programs made it easier to scan. For example, in Python I could blur my
eyes such that I can't positively identify the letters, but could still
tell an assignment from a function call from a mathemetical expression;
not so easy in LISP where expressions are visually similar. Thus, a
line in Python would require less reading, and thus less effort. Or so
it is for me.

Apparently, I look at the whole line, whereas you look at only the
begining of the line when scanning. I suppose many LISPers do as well.
I guess which is less effort depends on whether you find it more
difficult to identify patterns whole line, or read an extra word.

Carl Banks
 
R

Ralf Muschall

Douglas said:
Experienced Lisp programmers use indentation to visually parse the
program structure, just like Python programmers do for Python.
Experienced Lisp programmers learn to not see the parentheses when
they don't need to.

True, and this is IMHO an advantage of lisp to python (both humans
and computers get something they are good at parsing, and mistakes
in the one can be corrected using the other).
When I did a lot of Lisp programming, I often felt that it would be
kind of nice to have a version of Lisp that would infer many of the
parentheses from indentation, so that you could elide most of them.

This is not necessary - just making them barely visible suffices.

(font-lock-add-keywords
'emacs-lisp-mode
'(("[()]" . somr-barely-visible-face)))

One can also use nil instead of the mode, wrap the thing into a
defun and use it as a hook (nil means "just the current buffer
whatever mode it is in").

Btw., vim seems to try to become a real editor - look at
http://wiki.alu.org/Vim_ECL

Ralf
 
D

Douglas Alan

Carl Banks said:
Interesting. I always found that the visual distinctness of non-Lisp
programs made it easier to scan. For example, in Python I could blur my
eyes such that I can't positively identify the letters, but could still
tell an assignment from a function call from a mathemetical expression;
not so easy in LISP where expressions are visually similar.

Hey, well I designed my own programming language "Drawl" that combines
the best of both worlds. A sample program in Drawl would look
something like this:

proc mostApplicableMethods (g args)
let appMethods = (filter [lambda (met) (mcProtoMetApp? met lex:args)]
(funMets g))
let nMets = (len appMethods)
if nMets = 1; appMethods
elif nMets = 0; %{}
else let retval = {}
for i in (range nMets)
let m1 = appMethods
for m2 in retval + appMethods[i+1..inf]
if (isCongruentTo? m2 m1); break
else (append list=retval ele=m1)
retval

This would correspond to the following Python code:

def mostApplicableMethods(g, args):
appMethods = filter(lambda met: isMcProtoMetApp(met, args),
funMets(g))
nMets = len(appMethods)
if nMets == 1: return appMethods
elif nMets == 0: return ()
else:
retval = []
for i in range(nMets):
m1 = appMethods
for m2 in retval + appMethods[i+1:]:
if isCongruentTo(m2, m1): break
else: retval.append(m1)
return retval

In Drawl all expressions are either functions calls that begin with a
"(" and are Lisp-like, or they are mathematical infix expressions.
Statements and macros, on the other hand, always begin with an
identifier that identifies the statement or macro. The exception to
what I just said is that statements and macros can be turned into
expressions by surrounding them with square brackets.

Too bad I never got around to actually implementing Drawl, though,
because we all know that what the world needs right now is another
programming language....

|>oug
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top