Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"C-like" syntax for Lisp in less than 100 lines of code

59 views
Skip to first unread message

Alessio Stalla

unread,
Apr 18, 2010, 6:53:15 PM4/18/10
to
I have coded some simple syntax sugar to provide a vaguely "C-like"
syntax for Lisp, part as a proof of concept, part with the intention
of actually using it in a library. It's not meant to replace sexps but
just to be less scary for newbies AND to show that the syntax argument
against Lisp is just dumb. I'd never use it myself of course ;)

The syntax is based on the Lisp reader, with these simple rules:

, (comma) is considered whitespace.
expressions are separated by ;
( ) still delimit lists.
expressions consisting of multiple tokens are automatically wrapped in
a list. Expressions consisting of a single token are not listified, so
foo is read as a symbol while (foo) as a list.
foo { ... } is roughly like `(foo ,@(list ...)) i.e. the expressions
inside the braces are inserted in the outer expression.

That's pretty much all, and it turns out - surprisingly - to cover
many common expressions you can find in Lisp. Plus, reader macros
still work (though of course they don't understand the "C-like"
syntax).

An example:

with-output-to-string (str) {
print #\c str;
if (> foo 45) {
progn { print 3; print 4; }
print 5;
}
}

If anyone's interested, the code is here:
http://alessiostalla.altervista.org/software/c-like-lisp/cll.lisp

it's far from perfect; for example, braces inside lists are read as
literal characters. But, as a quick hack it came out pretty good,
imho.

Cheers,
Alessio

Slobodan Blazeski

unread,
Apr 19, 2010, 7:36:33 AM4/19/10
to
On Apr 19, 12:53 am, Alessio Stalla <alessiosta...@gmail.com> wrote:
> I have coded some simple syntax sugar to provide a vaguely "C-like"
> syntax for Lisp, part as a proof of concept, part with the intention
> of actually using it in a library.

Burn the witch.


grucidipo

unread,
Apr 19, 2010, 7:49:04 AM4/19/10
to

Perhaps you should find interesting Maxima, it is based in Lisp and
use a C-like syntax, you can define operators and obtain the desired
preference using left and right binding power. It also has a way of
declaring the type of the arguments in order to translate to lisp with
optimize for speed setting.

I have been doing google code-jam problems for improving my Lisp
skills and project euler, but I still find it easier to use python.
Emacs is better than idle, you can redefine functions on the fly with
alt-e ctr-e, in python you must copy and paste the function definition
in the shell (python repl).

I also think that the current thread about improving asdf could be
better used if used with maxima.

o.ja...@gmail.com

unread,
Apr 19, 2010, 11:14:05 AM4/19/10
to
Alessio Stalla wasn't be the first and won't be the last :), i did it
once too(http://www.lispforum.com/viewtopic.php?
f=20&t=300&p=2044&hilit=unlisp#p2044, just ftr, it sucks), i don't
think it is all that bad an idea, if it gets nubs to use lisp.. But we
don't want them using a dozen different ones.. Perhaps try emulate
something like Python closely..(Or just be plain compatible with
it :).)

> I also think that the current thread about improving asdf could be better used if used with maxima.

What do you mean? You mean Maxima should use (the newer)asdf? I don't
get why maxima isn't asdf-installable at this point.. (And multiple
asd files please.. for instance the alternate syntax should probably
be a separate package & system..

Peter Keller

unread,
Apr 19, 2010, 11:28:10 AM4/19/10
to
Alessio Stalla <alessi...@gmail.com> wrote:
> An example:
>
> with-output-to-string (str) {
> print #\c str;
> if (> foo 45) {
> progn { print 3; print 4; }
> print 5;
> }
> }

How would you write a macro to do a non-trivial code transformation in the
above syntax?

-pete

Alessio Stalla

unread,
Apr 19, 2010, 12:16:22 PM4/19/10
to
On 19 Apr, 17:28, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:

As I said, it's not intended to replace S-expressions: what I meant is
that you cannot use it to write macros cleanly. I believe that if you
know macros then usually you are also convinced that sexp-based syntax
is the most powerful one possible (to write macros). The main use I
intend to do of this syntax is to provide it to end-users of a library/
DSL who potentially don't care about Lisp and macros at all. Of course
the advanced users, or those who already know Lisp, won't have any
reason to use the dumbed-down syntax.
And, since the syntax outputs Lisp forms, you can more-or-less
trivially convert from "C-like" to Lisp by means of reading and then
printing the forms.
Again, if it's not clear, the sense of my post was not to promote the
syntax to lispers (which is stupid), but to show how, with relatively
few lines of code, you can build a "C-like" mock syntax on top of the
Lisp reader. Of course to be really C-like it should be more polished
and feature-rich - say, infix operators, [] to access arrays and hash
tables, other corner cases I'm not aware of, ...

Cheers,
Alessio

Alessio Stalla

unread,
Apr 19, 2010, 12:29:00 PM4/19/10
to
On 19 Apr, 17:14, "o.jas...@gmail.com" <o.jas...@gmail.com> wrote:
> Alessio Stalla wasn't be the first and won't be the last :), i did it
> once too(http://www.lispforum.com/viewtopic.php?
> f=20&t=300&p=2044&hilit=unlisp#p2044, just ftr, it sucks), i don't
> think it is all that bad an idea, if it gets nubs to use lisp..

I know I'm not the first ;) but I got struck by how simple it is to
pervert the reader :D and I wanted to share my impression.

> But we
> don't want them using a dozen different ones.. Perhaps try emulate
> something like Python closely..(Or just be plain compatible with
> it :).)

Python is harder to emulate using the Lisp reader because of
whitespace significance: I purposedly added the braces as an easy
device to form bodies of expressions, like often happens with macros.
Doing the same by parsing whitespace and keeping track of the
indentation level was overkill, considering I didn't really want to
cook up a full-blown parser but simply to use the reader by adding as
few parsing rules as possible. For the same reason, my syntax is not
really C-like because, for example, foo() is not a function invocation
with zero arguments but rather gets read to the form (foo nil).

Cheers,
Alessio

Peter Keller

unread,
Apr 19, 2010, 12:42:40 PM4/19/10
to
Alessio Stalla <alessi...@gmail.com> wrote:
> Again, if it's not clear, the sense of my post was not to promote the
> syntax to lispers (which is stupid), but to show how, with relatively
> few lines of code, you can build a "C-like" mock syntax on top of the
> Lisp reader. Of course to be really C-like it should be more polished
> and feature-rich - say, infix operators, [] to access arrays and hash
> tables, other corner cases I'm not aware of, ...

Ah, I understand the intention more fully now.

It really is a neat piece of code you wrote.

-pete

Tamas K Papp

unread,
Apr 19, 2010, 2:19:39 PM4/19/10
to
On Mon, 19 Apr 2010 08:14:05 -0700, o.ja...@gmail.com wrote:

> Alessio Stalla wasn't be the first and won't be the last :), i did it
> once too(http://www.lispforum.com/viewtopic.php?
> f=20&t=300&p=2044&hilit=unlisp#p2044, just ftr, it sucks), i don't think
> it is all that bad an idea, if it gets nubs to use lisp.. But we don't

I think that the intention of helping newbies may be laudable, but I
don't see the practical advantage. S-expressions (and macros) are
what makes Lisp powerful. With a C-like syntax, Lisp is not much
more powerful than a C-like language (with a few nice features thrown in,
eg Blub OO systems rarely ever come close to CLOS). The greatest help
one can give to newbies is help with learning CL as it is.

That said, it is a cool hack.

Tamas

Günther Thomsen

unread,
Apr 20, 2010, 11:43:14 PM4/20/10
to
On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote:
[..]

> I think that the intention of helping newbies may be laudable, but I
> don't see the practical advantage.
Indeed.

This comes up every now and then. I'm not sure whether this
parenthesis-paralysis is actually a real problem or an often-repeated
myth.
In any case, Dylan did away with the prefix-syntax and that wasn't
enough to make it popular (but of course, there might have been other
reasons or no reasons why it failed to gain popularity).

> S-expressions (and macros) are
> what makes Lisp powerful.  With a C-like syntax, Lisp is not much
> more powerful than a C-like language (with a few nice features thrown in,
> eg Blub OO systems rarely ever come close to CLOS).  The greatest help
> one can give to newbies is help with learning CL as it is.

Not sure about that. But why not start with a good book and classic
Scheme? Once through that, the student surely will be able to deal
with those parenthesis and can move on to CL, if so inclined.

>
> That said, it is a cool hack.

Sure. The Lisp world isn't lacking cool hacks though.

Tamas K Papp

unread,
Apr 21, 2010, 12:47:19 AM4/21/10
to
On Tue, 20 Apr 2010 20:43:14 -0700, Günther Thomsen wrote:

> On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]
>

>> S-expressions (and macros) are
>> what makes Lisp powerful.  With a C-like syntax, Lisp is not much more
>> powerful than a C-like language (with a few nice features thrown in, eg
>> Blub OO systems rarely ever come close to CLOS).  The greatest help one
>> can give to newbies is help with learning CL as it is.
> Not sure about that. But why not start with a good book and classic
> Scheme? Once through that, the student surely will be able to deal with
> those parenthesis and can move on to CL, if so inclined.

I started with Scheme instead of CL, thinking that since it claims to
be "smaller", it would be easier to learn. The language seemed very
clever and abstract, but I felt that it required to force my thinking
into particular patterns/solutions, which were not natural to me (eg
the books I have used insisted on doing pretty much everything with
tail recursion). Based on Scheme, I formed the impression that Lisp
is a clever but impractical programming language (I didn't know much
about CL). Fortunately for me, a year later I decided to give CL a
chance, and I was hooked instantly.

Based on my experience, I would be wary of recommending Scheme to
newbies. Also, I think that the two communities are a bit different.
I have yet to encounter a book for Scheme that is comparable to PCL.
Most books for Scheme I have seen seem to care little about the
language per se, and try to expand on a particular theme instead (eg
how to do everything using recursion, the joys of call/cc). Macros
are not really emphasized (eg in the Dybvig book, they get a very thin
chapter towards the end, which is a puzzle).

Tamas

Peter Keller

unread,
Apr 21, 2010, 1:10:57 AM4/21/10
to
Gunther Thomsen <guen...@gmail.com> wrote:
> This comes up every now and then. I'm not sure whether this
> parenthesis-paralysis is actually a real problem or an often-repeated
> myth.

I've hacked scheme for a long time and lisp for a little while. I believe
there is such a thing as parenthesis-paralysis.

After some careful introspection upon it over the years, I've come to
a belief about how it arises and presents.

It appears to me to happen because of two concepts:
1. Indention style
2. Destructuring bind, as performed by a human reading code. :)

Indention style, especially in lisp, is _extremely_ important and
emacs/slime is the only thing that culturally "does it correctly out of
the box".

Most editor's notion of auto-indention is that when you hit return,
you align with the first non whitespace character on the previous line
OR you just indent X columns. Combine this with a regular joe's idea of
indention being <tab>, and you have a disasterous situation. For example
suppose my tab stops are set to 4 in the following example. Every place
you see a . is where I hit tab.

Like:

(let ((thing 42)
. (stuff 99)
. (qux 100))

. (format t "Hi~%"))

Looks like crap doesn't it?

In other block structured languages, a simple tab is sufficient for code
readability. E.G. C:

void foo(void)
{
. int thing = 42;
. int stuff = 99;
. int qux = 100

. printf("Hi\n");
}

Notice, from a mental model of indention, I did the *exact* same
behaviour. I indented the bindings, left a space, then indented
the body. People use the same mental model of indention for similar
languages. This realization is the key to why people entering lisp for
the first time have such a hard time about it.

Let's take a look at the original poster's precipitating example. If
your tab stop is set to 2, then this is _exactly_ how you would type it
using a regular editor's default notion of indention.

with-output-to-string (str) {
print #\c str;
if (> foo 45) {
progn { print 3; print 4; }
print 5;
}
}

We can hypothesize that the original author's mental model of code
indention appears to follow to the default behavior of their editor
and that they write in block structured imperative languages more often
than not. I believe they view this indention model as "correct".

In C, C++, PHP, perl, Java, python, fortran 90, etc, etc, etc, this is
just fine and leads to pretty readable code. Specifically in python,
it is enshrined.

In Lisp (and somewhat scheme), the default behavior of the editor and/or
the mental model of indention is completely wrong. Why? reason number 2.

Humans use visual whitespace and alignments of similar boundary markers to
block off semantically related entities. This helps them to "destructure"
the forms into meaningful sections or elements.

The correctly indented lisp form for the above let form:

(let ((thing 42)
(stuff 99)
(qux 100))

(format t "Hi~%"))

You can see how the parentheses of the binding forms are aligned with
each other. The ( which "sticks out" is the demarcation of the beginning
of the binding list. The fact the (format ...) is indented to the left
states the bindings are over and this tells you this is the body of the let.

Another one, more complex in lisp (done with bad indention):

(do ((x 0 (1+ x))
. (y 10 (1- y))
. (z 0 (1+ z)))
. ((zerop y) (+ x z))

. (format t "Hi!~%"))

That is terrible, since the test condition vanishes into the step
forms. Get rid of the newline in the middle and it is a train wreck. The
problem is, this is how editors want to do it by default! I've seen the
modern generation of programmers lately. They use pico, notepad, gedit,
or kde/gnome whatever to write their code. The editors all do this ham
fisted autoindent behavior and can't really be taught otherwise. I can't
imagine that while writing lisp. I would go insane.

The correct do form:

(do ((x 0 (1+ x))
(y 10 (1- y))
(z 0 (1+ z)))
((zerop y) (+ x z))

(format t "Hi~%"))

The main problem is that culturally, lisp doesn't indent at the same
quanta of indention as other languages over the various semantic forms of
the language. Sometimes you need 1/4 of an indention, or 1/2 of one, or
a one space difference. Programmers, when presented with such a problem,
spend their time laboriously aligning parenthesis so everything looks
right--because their editor doesn't do it for them! If they don't
know what looks right to begin with, they simply self converge to a
self-consistent form of indention and write all their code in it.

The paralysis continues when, not having been grounded in the cultural
indention style of lisp or not having an editor that performs it
automatically, you start reading other people's code. If you get unlucky
and read a collection of people's code that never learned the correct
cultural style (each having their own style), then the destructuring
process gets amazingly difficult to do. You end up reading character
by character, parenthesis by parenthesis, trying to figure out where
semantic forms start and end. The most powerful visual/spatial recognizer
in your head (like 1/4 of your brain matter is devoted to it!) sits
completely idle!

I hacked my emacs/slime syntax coloring to be very detailed and show many
different classes of semantic ideas: comments, ANSI functions, macros,
special forms, type names, special variables, constants, etc, etc, etc to
all be color coordinated with each other using color theory to give me
insight into what I've written--and whether I'm writing it correctly!

The most important change I did was to make the parenthsis color nearly
the same as the background color. In a sense they vanish and I'm left
with the spatial blocks as an indention structure, which works just
fine. I can always resolve a specific parenthesis from the background if
I have to to disambiguate a form. Usually, if I screwed something up,
the indention level of my codebase goes wrong and it is pretty easy
to find where I missed a parenthsis.

Oddly, lisp is the only language for which I do this, all others are
just white text on a black background and I prefer it that way. Syntax
highlighting is distracting to me in non lisp languages. It is a
requirement for lisp!

After serious use of colorizing/indention system slime and my hacks
provided me, I occasionally find that looking at non-colorized, but
correctly indented Lisp, is hard. The parentheses make a visual heavyness
that is hard to ignore; I almost read it as ALL CAPS style yelling. If
I'm looking at non-colorized and non-culturally indented lisp, I revert
to the "hunt and peck" method of trying to destructure the semantic
forms in my head. It gets frustrating very quickly.

I honestly believe parenthesis-paralysis is real. The right editor will make
the paralysis completely disappear, the wrong editor will accentuate it.

Later,
-pete

Peter Keller

unread,
Apr 21, 2010, 2:02:52 AM4/21/10
to
Alessio Stalla <alessi...@gmail.com> wrote:
> with-output-to-string (str) {
> print #\c str;
> if (> foo 45) {
> progn { print 3; print 4; }
> print 5;
> }
> }

After really studying this piece of code. I would say that you should not
use it for newbies, or really at all.

Here is my reasoning:

In Bourne shell:

if [ x -gt y ]; then
echo "hi"
else
echo "bye"
fi

In C:

if (x > y) {
printf("hi\n");
} else {
printf("bye\n");
}

In perl

if (x > y) {
print "hi\n";
} else {
print "bye\n";
}

In python:

if x > y:
print("hi\n");
else:
print("bye\n");

in your dialect:

if (> x y) {
format t "hi~%";
format t "bye~%";
}

That would be the source of so many conceptual and concrete errors in
a piece of code as to make someone axe their computer into pieces and
regret the day they ever started programming. You'd be lucky if they
don't hunt you down with a dull sledgehammer to teach you a lesson. :)

Don't suggest a conventional meaning with your grouping symbols which
is totally inconsistent with the actual meaning in many other popular
languages.

Later,
-pete


Tim Bradshaw

unread,
Apr 21, 2010, 4:54:10 AM4/21/10
to
On 2010-04-21 04:43:14 +0100, G�nther Thomsen said:

> This comes up every now and then. I'm not sure whether this
> parenthesis-paralysis is actually a real problem or an often-repeated
> myth.

I think, though, that there are places where you want other syntaxes.
I'm very happy programming in Lisp's native syntax, but I'd find an
algebra system which required that (and I have used such) a pain to use.

Rupert Swarbrick

unread,
Apr 21, 2010, 4:56:13 AM4/21/10
to
Peter Keller <psi...@merlin.cs.wisc.edu> writes:

<snip... the real point of the post: sorry!>

> I hacked my emacs/slime syntax coloring to be very detailed and show many
> different classes of semantic ideas: comments, ANSI functions, macros,
> special forms, type names, special variables, constants, etc, etc, etc to
> all be color coordinated with each other using color theory to give me
> insight into what I've written--and whether I'm writing it correctly!
>
> The most important change I did was to make the parenthsis color nearly
> the same as the background color. In a sense they vanish and I'm left
> with the spatial blocks as an indention structure, which works just
> fine. I can always resolve a specific parenthesis from the background if
> I have to to disambiguate a form. Usually, if I screwed something up,
> the indention level of my codebase goes wrong and it is pretty easy
> to find where I missed a parenthsis.

Hi,

This sounds interesting to play with: did you stick the theming changes
you made into a file you could pass around? I've been lazy and tend to
stick with either the default emacs theme or a low contrast one called
zenburn. But it would be really interesting to have a look at one
designed by someone for use writing lisp!

About the actual point of your post, it's unfortunate that "modern" text
editors (gedit, kate, notepad++ etc.) lack the extensibility to turn
them into useful platforms for writing lisp. And your point about
indentation is exactly what's required (and difficult!). Fluffy brown
ubuntu theming and emacs don't really look beautiful together (yes, even
with emacs23) and emacs is _hard_ to get started with, which means that
even your average 1st year compsci student ain't gonna be using
emacs. Of course, that dooms them to a lifetime writing java for
ecommerce, but I guess they don't know that at the time.

Unfortunately, you're unlikely to convince a dedicated emacs user to
spend hours a week trying to make something like gedit better for lisp
because, well, there's emacs to use instead... Oh and, no, I don't know
a solution!


Rupert

Pillsy

unread,
Apr 21, 2010, 10:04:14 AM4/21/10
to
On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote:
[...]

> This comes up every now and then. I'm not sure whether this
> parenthesis-paralysis is actually a real problem or an often-repeated
> myth.

I'm increasingly convinced that parentheses are the fundamental reason
that Lisp isn't a lot more popular than it is. Syntax really matters
to people, and the reasons it matters are rooted in subjective
judgements about "prettiness" or "ease of reading". It so happens that
a lot of programmers hate the parentheses for subjective reasons that
simply don't apply to Lisp users because if they applied, we wouldn't
be Lisp users.

> In any case, Dylan did away with the prefix-syntax and that wasn't
> enough to make it popular (but of course, there might have been other
> reasons or no reasons why it failed to gain popularity).

Sure, but it was pretty much not marketed. Counterfactuals are tough,
but I've always thought that if Dylan, rather than Java, had been the
language that Sun decided to throw all that weight behind, today
everybody would be complaining about it because their boss makes them
use it.
[...]


> Not sure about that. But why not start with a good book and classic
> Scheme?

I think Common Lisp is an easier language to learn than Scheme, with
its richer set of imperative constructs and much better support for IO
and object orientation. Learning Scheme involves drinking a bunch of
Kool-Aid, and the good Scheme books are at least as much about selling
you that Kool-Aid as they are about teaching you a new language.

Cheers,
Pillsy

Tamas K Papp

unread,
Apr 21, 2010, 10:51:15 AM4/21/10
to
On Wed, 21 Apr 2010 07:04:14 -0700, Pillsy wrote:

> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote: [...]
>> This comes up every now and then. I'm not sure whether this
>> parenthesis-paralysis is actually a real problem or an often-repeated
>> myth.
>
> I'm increasingly convinced that parentheses are the fundamental reason
> that Lisp isn't a lot more popular than it is. Syntax really matters to

That's like saying that the requirement to engage in abstract thinking
is the fundamental reason that makes (serious) mathematics unpopular.
Maybe. But there is nothing you can do about it: you can't make it
"easier" without making it uninteresting.

Likewise, it does not really make much sense to talk about how popular
Lisp would be without parentheses. Speculations on how fundamental
the SEXP syntax is to Lisp (and why Dylan failed etc) aside, no one
has demonstrated the existence of an equally powerful Lisp with a more
"conventional" syntax, so what the experiment/counterfactual would be
is not clear.

If someone invented a Lisp without parenthesis that is as powerful as
eg CL, we would be able to talk about whether the parens make Lisp
unpopular. Naturally, I am not holding my breath :-)

Personally, I grew to like Lisp syntax. But maybe this is a
preference that is heterogeneous in the population: people who like the
syntax or are willing to tolerate it for the extra power become Lisp
programmers, the rest don't. Not much we can do about this.

> I think Common Lisp is an easier language to learn than Scheme, with its
> richer set of imperative constructs and much better support for IO and
> object orientation. Learning Scheme involves drinking a bunch of
> Kool-Aid, and the good Scheme books are at least as much about selling
> you that Kool-Aid as they are about teaching you a new language.

Agreed. I almost gave up on Lisp because I started with books on
Scheme. It was years later when I learned that there are people who
write practical programs in (heavily extended dialects of) Scheme.

Tamas

Pillsy

unread,
Apr 21, 2010, 12:59:34 PM4/21/10
to
On Apr 21, 10:51 am, Tamas K Papp <tkp...@gmail.com> wrote:
> On Wed, 21 Apr 2010 07:04:14 -0700, Pillsy wrote:
[...]

> > I'm increasingly convinced that parentheses are the fundamental reason
> > that Lisp isn't a lot more popular than it is.

> That's like saying that the requirement to engage in abstract thinking


> is the fundamental reason that makes (serious) mathematics unpopular.
> Maybe.

I don't think this is a good analogy. Programming languages provide
specialized notations, and Lisp, by specializing its notation to make
metaprogramming convenient, forgoes some other possibilities that make
doing other things particularly convenient.

> But there is nothing you can do about it: you can't make it "easier"
> without making it uninteresting.

I think there's an engineering trade-off between ease of
metaprogramming and provision of syntactic sugar. A smallish number of
languages and users gravitate towards the Lisp end of the spectrum and
a much larger group of languages users gravitate towards the
everything-else end of the spectrum, and there's virtually nothing in
the middle. There are only a few attempts, and if you only have a few
attempts, the whole class of languages is a lot more likely to get
wiped out for unrelated economic reasons (like Dylan) or unrelated
technical blunders (like Mathematica).
[...]


> If someone invented a Lisp without parenthesis that is as powerful as
> eg CL, we would be able to talk about whether the parens make Lisp
> unpopular.  Naturally, I am not holding my breath :-)

I think this sells CL short, because it has a lot of things beyond
parenthesized syntax that make it a worthwhile language. Any idiot can
write a Lisp---writing toy Lisp interpreters is a common exercise in
undergraduate CS classes---but writing a *decent* Lisp is much
harder.

Someone can break new and interesting ground in terms of allowing more
syntax while enabling structured manipulation of source code, but that
doesn't mean that they won't totally botch the rest of their language.
The cool syntactical possibilities are only going to go so far if your
IO and error handling mechanisms are completely busted and your only
implementation is a slow-like-molasses-on-Quaaludes interpreter.

> Personally, I grew to like Lisp syntax.  

I did too. Actually, I discovered that I liked it almost immediately.
OTOH, I find C-descended syntaxes to be very uncomfortable. Part of
the reason I'm so convinced of the role that personal preference plays
in this is that my own preferences seem to be so radically different
from most other programmers.

Cheers,
Pillsy

Tim Bradshaw

unread,
Apr 21, 2010, 1:08:20 PM4/21/10
to
On 2010-04-21 17:59:34 +0100, Pillsy said:

> I think there's an engineering trade-off between ease of
> metaprogramming and provision of syntactic sugar.

I think that's a good summary.

Tamas K Papp

unread,
Apr 21, 2010, 1:26:31 PM4/21/10
to
On Wed, 21 Apr 2010 09:59:34 -0700, Pillsy wrote:

> On Apr 21, 10:51 am, Tamas K Papp <tkp...@gmail.com> wrote:
>> But there is nothing you can do about it: you can't make it "easier"
>> without making it uninteresting.
>
> I think there's an engineering trade-off between ease of metaprogramming
> and provision of syntactic sugar. A smallish number of languages and

Good point.

>> If someone invented a Lisp without parenthesis that is as powerful as
>> eg CL, we would be able to talk about whether the parens make Lisp
>> unpopular.  Naturally, I am not holding my breath :-)
>
> I think this sells CL short, because it has a lot of things beyond
> parenthesized syntax that make it a worthwhile language. Any idiot can
> write a Lisp---writing toy Lisp interpreters is a common exercise in
> undergraduate CS classes---but writing a *decent* Lisp is much harder.
>
> Someone can break new and interesting ground in terms of allowing more
> syntax while enabling structured manipulation of source code, but that
> doesn't mean that they won't totally botch the rest of their language.
> The cool syntactical possibilities are only going to go so far if your
> IO and error handling mechanisms are completely busted and your only
> implementation is a slow-like-molasses-on-Quaaludes interpreter.

I agree. But I would argue that the other nice features of CL also
owe their existence and polished state to CL's extensibility, which
stems from SEXPS that you can easily manipulate with macros.

AFAIK in the beginning, Lisp was rather a crude language by today's
standards. But the very extensibility of the language made it an
extremely fertile ground for experimentation: different dialects
emerged, and people came up with nice solutions to common problems.
When CL was formed, it could just incorporate many of these - the
designers of CL had a lot to build on.

I am not aware of any other language family that would incorporate
facilities for experimentation with new features to the extent that
Lisp does. So I don't think that it is a mere coincidence that CL is
so well-polished: it all comes from Lisp's fundamental
extensibility/flexibility. Which has a lot to do with SEXPs+macros.

Best,

Tamas

Alessio Stalla

unread,
Apr 21, 2010, 1:52:24 PM4/21/10
to
On 21 Apr, 08:02, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:

Very good point! I hadn't noticed it because I'm accustomed to the
Lisp way, i.e., that most macros have one and only one body. In C and
similar languages, this is not the case; there are constructs with
multiple bodies, often separated by keywords.
I could try to work around this limitation - for example, having
{ ... } translate to (progn ...) and allowing multiple {}-bodies per
expression, as in

if foo { then-part; } { else-part; };

but I don't really want to do that; the syntax would become more
complicated, move further away from the underlying representation as a
Lisp form, and still not be surprise-proof (where's the else keyword,
for example?).

I guess the only way to solve the dilemma is to expose the syntax to a
number of C or Java programmers and see what they think. If the
majority thinks it's garbage, then better forget it and stick to
sexps. If they still find some value in it, it could be saved, maybe
with some modifications.

Thanks for your insight.

Cheers,
Alessio

Mario S. Mommer

unread,
Apr 21, 2010, 2:23:04 PM4/21/10
to

Alessio Stalla <alessi...@gmail.com> writes:
> On 21 Apr, 08:02, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
>> in your dialect:
>>
>> if (> x y) {
>>         format t "hi~%";
>>         format t "bye~%";
>> }
>>
>> That would be the source of so many conceptual and concrete errors in
>> a piece of code as to make someone axe their computer into pieces and
>> regret the day they ever started programming. You'd be lucky if they
>> don't hunt you down with a dull sledgehammer to teach you a lesson. :)
> Very good point! I hadn't noticed it because I'm accustomed to the
> Lisp way, i.e., that most macros have one and only one body. In C and
> similar languages, this is not the case; there are constructs with
> multiple bodies, often separated by keywords.
> I could try to work around this limitation - for example, having
> { ... } translate to (progn ...) and allowing multiple {}-bodies per
> expression, as in
>
> if foo { then-part; } { else-part; };
[...]

How about a Algol/Pascal/Ada parser? I mean, conceptually everything can
be expressed as prefix, and Pascal has a failry sane notation, is
reasonably small, and the bnf grammar as well as a bnf parser for lisp
can be had for 0 cost.

The real advantage of such a notation is to not have that to be the
showstopper. People sometimes look at S-exprs and say "no way", and that
was it. Having one with a good canonical syntax is nice to avoid bad
karma. I.e. if that little syntax of yours becomes official policy at
some big customer's shop, then at least it is not too braindamaged.

Pascal J. Bourguignon

unread,
Apr 21, 2010, 6:27:10 PM4/21/10
to
Pillsy <pill...@gmail.com> writes:

> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote:
> [...]
>> This comes up every now and then. I'm not sure whether this
>> parenthesis-paralysis is actually a real problem or an often-repeated
>> myth.
>
> I'm increasingly convinced that parentheses are the fundamental reason
> that Lisp isn't a lot more popular than it is. Syntax really matters
> to people, and the reasons it matters are rooted in subjective
> judgements about "prettiness" or "ease of reading". It so happens that
> a lot of programmers hate the parentheses for subjective reasons that
> simply don't apply to Lisp users because if they applied, we wouldn't
> be Lisp users.

We should tag "(this is a list)" in front of each primary school of the
world! :-)

--
__Pascal Bourguignon__

Peter Keller

unread,
Apr 21, 2010, 11:31:13 PM4/21/10
to
Rupert Swarbrick <rswar...@gmail.com> wrote:
> [-- text/plain, encoding 7bit, charset: US-ASCII, 44 lines --]

>
> Peter Keller <psi...@merlin.cs.wisc.edu> writes:
>
> <snip... the real point of the post: sorry!>
>
>> I hacked my emacs/slime syntax coloring to be very detailed and show many
>> different classes of semantic ideas: comments, ANSI functions, macros,
>> special forms, type names, special variables, constants, etc, etc, etc to
>> all be color coordinated with each other using color theory to give me
>> insight into what I've written--and whether I'm writing it correctly!
>>
>> The most important change I did was to make the parenthsis color nearly
>> the same as the background color. In a sense they vanish and I'm left
>> with the spatial blocks as an indention structure, which works just
>> fine. I can always resolve a specific parenthesis from the background if
>> I have to to disambiguate a form. Usually, if I screwed something up,
>> the indention level of my codebase goes wrong and it is pretty easy
>> to find where I missed a parenthsis.
>
> This sounds interesting to play with: did you stick the theming changes
> you made into a file you could pass around? I've been lazy and tend to
> stick with either the default emacs theme or a low contrast one called
> zenburn. But it would be really interesting to have a look at one
> designed by someone for use writing lisp!

I wrote up an extended blog post of the usenet post I wrote about
indention at:

http://pages.cs.wisc.edu/~psilord/blog/28.html

That post includes the color reasoning and emacs lisp which implements the
highlighter. I have a couple screenshots you can see of it. The emacs
lisp, is um, special, and by that I mean terrible. I don't know emacs
lisp and I'm surprised the Earth didn't implode from the sucking sound
of my .emacs file.

I have some other lisp related stuff in the lisp category on my blog,
but I don't have too many posts in that category yet. I just started
writing lisp seriously 6 months ago or so.

> About the actual point of your post, it's unfortunate that "modern" text
> editors (gedit, kate, notepad++ etc.) lack the extensibility to turn
> them into useful platforms for writing lisp. And your point about
> indentation is exactly what's required (and difficult!).

I am a staunch vim user, to say the least. However, after patches I
was giving back to various lisp projects were rejected with the reason
"format it in SLIME or else". I bit the bullet and simply learned emacs
for my Lisp IDE. I'm happy I did this.

Later,
-pete


Thibault Langlois

unread,
Apr 22, 2010, 4:10:17 AM4/22/10
to
On Apr 21, 3:04 pm, Pillsy <pillsb...@gmail.com> wrote:
> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote:
> [...]
>
> > This comes up every now and then. I'm not sure whether this
> > parenthesis-paralysis is actually a real problem or an often-repeated
> > myth.
>
> I'm increasingly convinced that parentheses are the fundamental reason
> that Lisp isn't a lot more popular than it is. Syntax really matters

I'm on the opposite side. I wish I had a sexp based syntax language
with the semantics of ANSIC.
If it was implemented in CL I would be able to mix them. A function
defined in the ANSIC package would obey the C semantics. When
compiling the CL compiler would automatically generate C syntax
equivalent, call gcc and generate the binding code.
If this approach was available for other languages (Java, javascript,
shell etc), I would have solved the syntax "problem" once for all. I
would never have to learn a different syntax for a new language. Sexp
is no-syntax it is so better than syntax A, B or C. What matters is
the semantic of the langugage. I am convinced that the ideal situation
described here would be actually better to teach programming. The
instructor could actually focus on the semantics of the language not
on the syntax.
Let's be crazy ! If I was a dictator I would require that every
programming language should offer a CL-compatible sexp based
syntax :-)

Tamas K Papp

unread,
Apr 22, 2010, 4:37:56 AM4/22/10
to
On Thu, 22 Apr 2010 01:10:17 -0700, Thibault Langlois wrote:

> On Apr 21, 3:04 pm, Pillsy <pillsb...@gmail.com> wrote:
>> On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote: [...]
>>
>> > This comes up every now and then. I'm not sure whether this
>> > parenthesis-paralysis is actually a real problem or an often-repeated
>> > myth.
>>
>> I'm increasingly convinced that parentheses are the fundamental reason
>> that Lisp isn't a lot more popular than it is. Syntax really matters
>
> I'm on the opposite side. I wish I had a sexp based syntax language with
> the semantics of ANSIC.
> If it was implemented in CL I would be able to mix them. A function
> defined in the ANSIC package would obey the C semantics. When compiling
> the CL compiler would automatically generate C syntax equivalent, call
> gcc and generate the binding code. If this approach was available for

Maybe you could try writing it and post here. It should not be too hard
I guess, C is a small language.

I had similar intentions with a subset of Fortran, but never got
around to it.

Tamas

Nick Keighley

unread,
Apr 22, 2010, 5:27:46 AM4/22/10
to
On 21 Apr, 05:47, Tamas K Papp <tkp...@gmail.com> wrote:
> On Tue, 20 Apr 2010 20:43:14 -0700, Günther Thomsen wrote:
> > On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]


> >> S-expressions (and macros) are
> >> what makes Lisp powerful.  With a C-like syntax, Lisp is not much more
> >> powerful than a C-like language (with a few nice features thrown in, eg
> >> Blub OO systems rarely ever come close to CLOS).  The greatest help one
> >> can give to newbies is help with learning CL as it is.

I genuinely think the parentheses *are* a barrier. I was put off Lisp
for years by the Lots of Irritating Silly Parentheses. (and then cam
back to lisp-like languages because I kept reading what a great
language it was and how it would change the way you thunk). OTH I
don't think hiding them helps. You've just got to grasp the nettle. An
editor that can count helps a /lot/.


> > Not sure about that. But why not start with a good book and classic
> > Scheme? Once through that, the student surely will be able to deal with
> > those parenthesis and can move on to CL, if so inclined.
>
> I started with Scheme instead of CL, thinking that since it claims to
> be "smaller",

me too. I was also hoping to embed scheme.

> it would be easier to learn.  The language seemed very
> clever and abstract, but I felt that it required to force my thinking
> into particular patterns/solutions, which were not natural to me (eg
> the books I have used insisted on doing pretty much everything with
> tail recursion).

I persevered. I think being more comfortable with recursion has been a
help. Though scheme's named-let doesn't really look like recursion...

> Based on Scheme, I formed the impression that Lisp
> is a clever but impractical programming language (I didn't know much
> about CL).  Fortunately for me, a year later I decided to give CL a
> chance, and I was hooked instantly.
>
> Based on my experience, I would be wary of recommending Scheme to
> newbies.  Also, I think that the two communities are a bit different.
> I have yet to encounter a book for Scheme that is comparable to PCL.
> Most books for Scheme I have seen seem to care little about the
> language per se, and try to expand on a particular theme instead (eg
> how to do everything using recursion, the joys of call/cc).

which book is that! "The Joy Of call/cc" is exactly what I've been
looking for (that and "So Which Bloody Macro Scheme Should I Use
Then?". Is there a "Hygenic Macros For Dummies"?)

>  Macros
> are not really emphasized (eg in the Dybvig book, they get a very thin
> chapter towards the end, which is a puzzle).

AOL


--

Scheme wanting to be considered a Lisp is like Robert E. Lee wanting
to
keep his commission in the United States Army.

Nick Keighley

unread,
Apr 22, 2010, 5:44:41 AM4/22/10
to
On 21 Apr, 15:51, Tamas K Papp <tkp...@gmail.com> wrote:
> On Wed, 21 Apr 2010 07:04:14 -0700, Pillsy wrote:
> > On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote: [...]

> >> This comes up every now and then. I'm not sure whether this
> >> parenthesis-paralysis is actually a real problem or an often-repeated
> >> myth.

in my experience it's real


> > I'm increasingly convinced that parentheses are the fundamental reason
> > that Lisp isn't a lot more popular than it is. Syntax really matters to

> > [people]


>
> That's like saying that the requirement to engage in abstract thinking
> is the fundamental reason that makes (serious) mathematics unpopular.
> Maybe.  But there is nothing you can do about it: you can't make it
> "easier" without making it uninteresting.

I think my problem is never understood *why* I had to tolerate the
pain. I don't know if they didn't say or if I didn't listen but Lisp
just seemed perverse to me. I've never been good at learning things
"because I say so" (I was a late reader as a child for similar
reasons).

> Likewise, it does not really make much sense to talk about how popular
> Lisp would be without parentheses.  

I see that now.


> Speculations on how fundamental
> the SEXP syntax is to Lisp (and why Dylan failed etc) aside, no one
> has demonstrated the existence of an equally powerful Lisp with a more
> "conventional" syntax, so what the experiment/counterfactual would be
> is not clear.

is it even possible to do something like Lisp's macros without SEXPs?


> If someone invented a Lisp without parenthesis that is as powerful as
> eg CL, we would be able to talk about whether the parens make Lisp
> unpopular.  Naturally, I am not holding my breath :-)
>
> Personally, I grew to like Lisp syntax.  

it's growing on me


> But maybe this is a
> preference that is heterogeneous in the population: people who like the
> syntax or are willing to tolerate it for the extra power become Lisp
> programmers, the rest don't.  Not much we can do about this.

try to explain the reason for the wierd syntax?

Look at the syntax the C++ template programmers live with to get
certain things done...

> > I think Common Lisp is an easier language to learn than Scheme, with its
> > richer set of imperative constructs and much better support for IO and
> > object orientation. Learning Scheme involves drinking a bunch of
> > Kool-Aid, and the good Scheme books are at least as much about selling
> > you that Kool-Aid as they are about teaching you a new language.
>
> Agreed.  I almost gave up on Lisp because I started with books on
> Scheme.  It was years later when I learned that there are people who
> write practical programs in (heavily extended dialects of) Scheme.

I'm still plodding the stoney scheme road...

CL always looked a bit of monster to me...


--

"Een schip op het strand is een baken in zee.
[A ship on the beach is a lighthouse to the sea.]"
- Dutch Proverb

[apparently very bad dutch]


Nick Keighley

unread,
Apr 22, 2010, 5:57:48 AM4/22/10
to
On 21 Apr, 23:27, p...@informatimago.com (Pascal J. Bourguignon)
wrote:


oddly I used to (when writing english (as a teenager)) deeply nest
parentheses,
I was much more tolerant of nested structures (than most people),
combining
this with my "lite" (never start an (unnecessary) new paragraph (a
stop (will do))
never start an (unnecessary) new sentence (a comma (will do))), I'm
surprised my
english teacher isn't now confined to some (padded) room drawing ()'s
on the walls
(with crayons). I also taught myself to stop doing this. perhaps if
I'd continued
Lisp would have made me less unhappy.

Nick Keighley

unread,
Apr 22, 2010, 6:00:35 AM4/22/10
to
On 22 Apr, 10:57, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:

> On 21 Apr, 23:27, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>
>
>
>
> > Pillsy <pillsb...@gmail.com> writes:
> > > On Apr 20, 11:43 pm, Günther Thomsen <guenth...@gmail.com> wrote:
> > >> This comes up every now and then. I'm not sure whether this
> > >> parenthesis-paralysis is actually a real problem or an often-repeated
> > >> myth.
>
> > > I'm increasingly convinced that parentheses are the fundamental reason
> > > that Lisp isn't a lot more popular than it is. Syntax really matters
> > > to people, and the reasons it matters are rooted in subjective
> > > judgements about "prettiness" or "ease of reading". It so happens that
> > > a lot of programmers hate the parentheses for subjective reasons that
> > > simply don't apply to Lisp users because if they applied, we wouldn't
> > > be Lisp users.
>
> > We should tag  "(this is a list)"  in front of each primary school of the
> > world! :-)
>

[layout de-googled]

Tim Bradshaw

unread,
Apr 22, 2010, 9:22:38 AM4/22/10
to
On 2010-04-22 10:57:48 +0100, Nick Keighley said:

> I also taught myself to stop doing this. perhaps if
> I'd continued
> Lisp would have made me less unhappy.

I don't think so, because the parenthesis in Lisp serve a very
different purpose (in "(if (< x 1) ... ...)", "(< x 1)" is not a
parenthetical remark which can be skipped on first reading).

Joshua Taylor

unread,
Apr 22, 2010, 11:05:38 AM4/22/10
to
On 2010.04.22 5:27 AM, Nick Keighley wrote:
> I persevered. I think being more comfortable with recursion has been a
> help. Though scheme's named-let doesn't really look like recursion...

I spent time with CL before Scheme, and I've always found that
named-lets seemed like a nice abbreviation for CL's LABELS, and it so it
did have the nice recursive feel to it. Since CL doesn't guarantee
tail-call optimization I end up writing an iterative version in CL.
I've found that writing the named-let or LABELS version first can help:
the DO-loop usually just falls right out of the named-let version. //JT

Raffael Cavallaro

unread,
Apr 22, 2010, 11:32:07 AM4/22/10
to

I think it should be qualified:

there's an engineering trade-off between ease of metaprogramming and

provision of built-in syntactic sugar.

I think the problem lisp faces with its parenthesized syntax is that
one needs to become fairly advanced at the language before one can
start *adding* the syntactic sugar one wants. As a result, newcomers
think they'll be doing the equivalent of manual inlining of dozens of
sets of parentheses forever if they use lisp.

The language needs to be sold macros-first if it is to have any chance
of convincing newcomers that fully parenthesized syntax is a good
thing. That means intro texts should start with examples of extremely
short, macro based code in lisp, the equivalent very long
c/c++/java/python/ruby, etc. version, and the fully macroexpanded lisp,
compared side by side.
--
Raffael Cavallaro

His kennyness

unread,
Apr 22, 2010, 11:45:28 AM4/22/10
to

What makes you think most other programmers would not have the same
result as yourself, viz. discover they like it almost immediately?

What I see is a conflation of opinion from a distance with actual
appreciation derived from experience. Talk about apples and orangutans!

kt

His kennyness

unread,
Apr 22, 2010, 12:09:09 PM4/22/10
to
Nick Keighley wrote:
> On 21 Apr, 05:47, Tamas K Papp <tkp...@gmail.com> wrote:
>> On Tue, 20 Apr 2010 20:43:14 -0700, Günther Thomsen wrote:
>>> On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]
>
>
>>>> S-expressions (and macros) are
>>>> what makes Lisp powerful. With a C-like syntax, Lisp is not much more
>>>> powerful than a C-like language (with a few nice features thrown in, eg
>>>> Blub OO systems rarely ever come close to CLOS). The greatest help one
>>>> can give to newbies is help with learning CL as it is.
>
> I genuinely think the parentheses *are* a barrier. I was put off Lisp
> for years by the Lots of Irritating Silly Parentheses. (and then cam
> back to lisp-like languages because I kept reading what a great
> language it was and how it would change the way you thunk).


...and thennnnnnnnnn? What was your, um, parensification curve (short,
long, asymptopic?) and where did it end (their invisible? you hate them?)?


kt

roland....@ruag.com

unread,
Apr 22, 2010, 12:44:45 PM4/22/10
to

>>>>> "Nick" == Nick Keighley <nick_keigh...@hotmail.com> writes:

Nick> On 21 Apr, 05:47, Tamas K Papp <tkp...@gmail.com> wrote:
>> On Tue, 20 Apr 2010 20:43:14 -0700, Günther Thomsen wrote:
>> > On Apr 19, 11:19 am, Tamas K Papp <tkp...@gmail.com> wrote: [..]

[snip]

>> Most books for Scheme I have seen seem to care little about the
>> language per se, and try to expand on a particular theme instead (eg
>> how to do everything using recursion, the joys of call/cc).

Nick> which book is that! "The Joy Of call/cc" is exactly what I've been
Nick> looking for (that and "So Which Bloody Macro Scheme Should I Use
Nick> Then?". Is there a "Hygenic Macros For Dummies"?)

The closest I came understanding call/cc was after reading Dorai Sitaram's
"Teach Yourself Scheme in Fixnum Days".
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html

As for macros, you might find something useful at
http://library.readscheme.org/

hope this helps
Roland

Duane Rettig

unread,
Apr 22, 2010, 2:42:00 PM4/22/10
to
On Apr 22, 3:00 am, Nick Keighley <nick_keighley_nos...@hotmail.com>

If you're looking for a computer language that feels like natural
language, Lisp is definitely not for you. Other programming languages
go to great lengths to provide the shortcuts and ambiguities that
natural languages provide, and with those ambiguities come
misunderstandings, where the speaker or writer says one thing and the
listener/reader hears another. This ambiguous communication is not
acceptable in a computer language, though many programmers search for
the ultimate language that can be "natural" and yet unambiguous.
Lisp's parens remove several major causes of syntactic ambiguity.

There are often several reasons why ambiguities work in natural
languages. The ideal reason, especially for spoken language, is
because there is interaction to disambiguate when communication occurs
(though often courses taught to perform "active listening" can get
very expensive). Sometimes correct communication is not the highest
priority; often the listener hears what he wants to hear, and so it
wouldn't have mattered what the speaker had said anyway. Also,
speaking in a precise way often causes the listener to lose focus or
interest, and that defeats the purpose of the communication anyway,
even if the listener wanted to understand what the speaker was saying.

It's good that you learned not to be so precise in your writing,
because that way you would lose your readers less often. It was
likely a process of feedback anyway, where you asked yourself "Why
aren't they listening to me?" and finally figured out the answer. But
a computer always listens to exactly what you have to say (or else is
considered broken) so that natural aversion you learn to speaking or
writing precisely doesn't apply in a computer language.

Use the right tool for the job. Natural language is not the right
tool for talking to a computer at the lowest level.

Duane

Alan Malloy

unread,
Apr 22, 2010, 3:07:17 PM4/22/10
to

Certainly it is *possible*. It wouldn't be nearly as concise or pretty,
but it could be done. In, for example, Java the compiler could:

1) Lex/parse everything into a syntax tree
2) Encode that tress as a hierarchical Java object
3) Compile all "macro methods", which take as their argument a reference
to the AST of the code they're being run on
4) Execute the macros, recursing as necessary
5) Recurse to step 3 if necessary; some macros may expand into further
macro definitions
6) Finally compile the macro-expanded code into a class file

This is so awkward as to be unusable, but it is hardly impossible.

--
Cheers,
Alan (San Jose, California, USA)

Alan Malloy

unread,
Apr 22, 2010, 3:12:59 PM4/22/10
to

Sure it is. It expands on the meaning of the if statement. Try writing
it as "If some condition (in this case, x < 1) holds, I'll do something
(this time, evaluate a sub-form); otherwise I'll do something else (as
it happens, evaluate a different sub-form)".

If your reader didn't care about the details, and just wanted to
understand that you were doing something conditionally, the sentence
above could be stripped of all parenthetical clauses without harm: "If
some condition holds, I'll do something; otherwise I'll do something else".

Pillsy

unread,
Apr 22, 2010, 5:17:41 PM4/22/10
to
On Apr 22, 11:45 am, His kennyness <kentil...@gmail.com> wrote:
> Pillsy wrote:
[...]

> > I did too. Actually, I discovered that I liked it almost immediately.
> > OTOH, I find C-descended syntaxes to be very uncomfortable. Part of
> > the reason I'm so convinced of the role that personal preference plays
> > in this is that my own preferences seem to be so radically different
> > from most other programmers.

> What makes you think most other programmers would not have the same
> result as yourself, viz. discover they like it almost immediately?

If that were the case, wouldn't we see Lispy syntaxes everywhere? Lots
of people are exposed to Lisp through intro CS courses or editing
Emacs configuration files, and writing a Lisp reader is pretty damned
easy. Even if people hate the dynamic typing or garbage collection,
they could still give their new languages all the parentheses you
could ever want.

Add to that people's #1 superficial complaint about Lisp is the
Legions of Irritating Stupid Parentheses, and I'm pretty sure I'm
right about this.

Cheers,
Pillsy

Tim Bradshaw

unread,
Apr 22, 2010, 6:14:03 PM4/22/10
to
On 2010-04-22 20:12:59 +0100, Alan Malloy said:

> If your reader didn't care about the details

Sorry, that's just silly. There are no cases where that form could
somehow be omitted without changing the meaning of the program (in fact
making it syntactically invalid). However the previous parenthetical
remark can be so omitted - and parenthetical remarks in written English
(such as this one) very often can.

Tamas K Papp

unread,
Apr 23, 2010, 3:27:19 AM4/23/10
to
On Thu, 22 Apr 2010 14:17:41 -0700, Pillsy wrote:

> On Apr 22, 11:45 am, His kennyness <kentil...@gmail.com> wrote:
>> Pillsy wrote:
> [...]
>> > I did too. Actually, I discovered that I liked it almost immediately.
>> > OTOH, I find C-descended syntaxes to be very uncomfortable. Part of
>> > the reason I'm so convinced of the role that personal preference
>> > plays in this is that my own preferences seem to be so radically
>> > different from most other programmers.
>
>> What makes you think most other programmers would not have the same
>> result as yourself, viz. discover they like it almost immediately?
>
> If that were the case, wouldn't we see Lispy syntaxes everywhere? Lots
> of people are exposed to Lisp through intro CS courses or editing Emacs
> configuration files, and writing a Lisp reader is pretty damned easy.
> Even if people hate the dynamic typing or garbage collection, they could
> still give their new languages all the parentheses you could ever want.

The good old argument of relying on the rationality of people. If X
is so good, why doesn't everyone use it? And consequently, if the
vast majority doesn't use X, there must be something wrong with it.

The sad truth is that the majority of people do not devote a lot of time
to exploring alternatives, they just use whatever they were taught, or
what others are using. They will use every excuse they can come up with
to rationalize this behavior.

The fact that Lisp is taught in intro CS courses is a serious handicap
for it IMO. AFAIK the vast majority of these courses use Scheme, and
use it to introduce some particular style of programming or a constructs
which are interesting to theoretical CS people. I would not be surprised
if the vast majority of CS students failed to see the point of these, and
even end up hating (or at least dismissing) the language. These feelings
might just focus on the most apparent superficial distinguishing mark of
Lisp: the parentheses.

> Add to that people's #1 superficial complaint about Lisp is the Legions
> of Irritating Stupid Parentheses, and I'm pretty sure I'm right about
> this.

As I said above, I think that the hatred of parentheses is just the
superficial focus of a problem that runs deeper. If I had to take one of
the intro CS courses I mentioned above, I would probably feel that if I
was subjected to an alien syntax, there should be some advantage to the
language to justify that. But usually there isn't, not in these courses.

I was not a CS major, but I was very excited that I could take CS courses
when I started at the university. I am a self-taught programmer, and I
thought that finally I could learn how to do it better. So I took the
intro course that CS students had to take. The Lisp part went like this:
Lisp is about lists and recursion. The only atoms Lisp has are integers,
which we manipulate. No mention of macros, CLOS, symbols, or even frickin
arrays.

The prof put up a factorial on the blackboard. Then a recursive function
for the Fibonacci series. These we analyzed. I recently found my notes
from that course when I was moving: the factorial wasn't even tail-
recursive! And naively done recursion is probably the dumbest way to
calculate Fibonacci.

This was the last CS course I ever took. I left it with the feeling that
Lisp has no point, it is a toy language for teaching recursion. It took
me about 8 years to look at Lisp again. I think that the vast majority
of students feel this way. There should even be a T-shirt: "I put up
with all those silly parenthesis, and all I got was theoretical CS toys."

Best,

Tamas

Nicolas Neuss

unread,
Apr 23, 2010, 5:09:43 AM4/23/10