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

RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?

351 views
Skip to first unread message

David Bakhash

unread,
Aug 8, 2000, 3:00:00 AM8/8/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> I'm interested in using significant indentation (like in Python)
> http://www.python.org
> to replace many parentheses in Lisp or Scheme programs.
>
> Has this been tried before? If so, what was the outcome?

I don't know how to respond to this post, and please, don't take
offense at anything I say.

The idea of using whitespace to alter the meaning of code is absurd.
I don't know how python continues to exist in its current state.
However, by altering the semantics of Common Lisp by using
indentation, you will surely lose.

one reason (that I'm sure someone will argue) is that lisp code is
itself data, and the reader simply doesn't care about whitespace
enough to handle this proposal. The resulting code will be a mess, as
will its rules, and doing quick-and-dirty stuff from the
read-eval-print loop (lisp prompt) will become annoying, though this
is the least of the problems I'm seeing.

When I first heard about Python and this indentation thing, I was
incredulous. But, of course, it turned out to be true. But the line
of thinking used for Python should never infect Common Lisp. I don't
think I've ever heard of a proposal for changing CL that's worse than
this, except a CL that required type decls, but even there, he had a
decent argument, which had to do with performance, but even that was
tenuous, since an implementation may choose to optimize based on
declarations, and it's hard enough to implement CL without these
optimizations.

In a nutshell, this idea is incompatible with CL for many reasons, and
if it ever happened, it would be disgraceful. I think it's great when
people look at some language feature like GC in CL and say "wouldn't
it be cool if we made a C++ like language that had this feature (hence
Java)", but _not_ when they take the crappiest "features" from other
languages and try to infect CL with them. This indentation-dependence
"feature" is surely the worst of all features I've ever heard of. How
people deal with it is beyond me.

Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> This proposal is an effort to find a middle ground between fully
> parenthesized Lisp and a language with a more explicit syntax. I
> think making indentation syntactically significant (like in Python)
> might help produce something living in that middle ground.

First off, I don't think I see what you mean by lisp having a less
explicit syntax. I have not seen a more _explicit_ syntax anywhere (I
think Scheme might be more explicit). To me, it's actually Python
which is not explicit (or, better said, whose semantics are less
implicit based on syntax).

While I admire your post, and you've given it lots of thought, and
have actually done more than just propose a high-level change
(i.e. "what about a indentation-dependent lisp"), but have given
examples and rules, I think you've failed to consider that just the
endless sea of parens deter many beginning Lisp programmers,
indentation rules deter many beginning Python programers. So,
syntactically, they both have these apparent downsides. But
experienced programmers in both languages claim that these features
are beneficial. How about doing away with the indentation garbage in
Python and replacing it with more parens? What's more important,
readability or writability? There's got to be a middle ground. To
me, that middle ground is common lisp with some considerate
indentation, which is very simple if you're using a decent editor.
I'm not implying that a C programmer would read current lisp more
easily than what you're suggesting, but that that's not the purpose of
lisp. the purpose is to be syntactically simple. the rules you're
suggesting do nothing more than obfuscate the rules of writing lisp
for the purpose of ridding the source code of some (not all) parens,
which _some_ people view as noisy.

also, paren-matching in editors is a helpful tool. this and other
editor hacks make lisp very usable, readable, and writable. being
able to write a single line of code that does a whole lot of stuff is
kinda cool, and I like it, and others probably do too. I realize that
what you're suggesting wouldn't disable that, of course, but allowing
both seems a bit problematic and confusing, as does turning on/off the
indentation feature.

dave

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
I'm interested in using significant indentation (like in Python)
http://www.python.org
to replace many parentheses in Lisp or Scheme programs.

Has this been tried before? If so, what was the outcome?

======= Small example =======

For example, how about:

; Doodle
define (doodle)
set-resdb "GUIdemo"
set-pattern #t
frm-popup 1100
lambda (event . args)
case event
(menu) (frm-return 'bye)
(pen-move pen-up)
draw (car args) (cadr args)
(pen-down)
move (car args) (cadr args)
else #f

Instead of:

; Doodle
(define (doodle)
(set-resdb "GUIdemo")
(set-pattern #t)
(frm-popup 1100
(lambda (event . args)
(case event
((menu) (frm-return 'bye))
((pen-move pen-up)
(draw (car args) (cadr args)))
((pen-down)
(move (car args) (cadr args)))
(else #f)))))

This example was taken from the LispMe (Lisp for the Palm) sample
code. http://www.lispme.de/lispme/

======= Some advantages =======

One advantage to such an approach it that it might make it easier to
compose Lisp on devices without keyboards. An indent-line button and an
unindent-line button would be useful in that case.

Significant indentation might make it easier for developers who don't
know Lisp well to understand a Lisp program's structure.

It might also allow experiences Lisp developers to read programs faster
because there is less high frequency "noise" in the text. Every
additional character on the screen takes more time for the eye and mind
to process. In practice, experienced Lisp developers will rely on the
indentation anyway -- as editors are used to count parentheses.

Such code will be faster to create. There is less typing, and no worry
about unbalanced parentheses. Indentation might be incorrect, but then
the mistake in the structure would usually be obvious on inspection.

Also, with significant indentation, indentation can not as often be
misleading as it can be with parentheses.

======= Some disadvantages =======

I'm sure people will point out lots. Send 'em on!

The major one is that this is non-standard and not available.

Also, it may confuse some people (novices?) as much as it clarifies
things to others.

======= Indentation rules =======

These are five rules for using indentation to replace parentheses.
They may look complex at first, but in practice I think they are easy to
understand from examples.

RULE 1: Everything on a line taken together is a list.

Example:

(+ 1 2)

becomes:

+ 1 2

RULE 2: At any point in a list, sublists may be indicated by creating a
new line that is indented by two spaces relative to the parent list.
However, one may also just leave sublists on the same line as the list
they are in, by using parentheses. Such sublists ideally should not wrap
across lines, but controversially they may if they are very long, in
which case everything until the next return after the closing parenthese
is considered as if it was on the same line.

Example:

(+ (* 3 4) (/ 2 3))

becomes:

+ (* 3 4)
/ 2 3

or:

+
* 3 4
/ 2 3

This is an acceptable conversion, but is strongly advised against:

+ (* 3
4) (/ 2 3)

This conversion is also legal, but also advised against:

+ (* 3
4)
/ 2 3

The reason these last two are advised against (besides being hard to
read) is that it then makes it harder to generate syntax errors based
purely on indentation.

RULE 3: Exception to rule 2: A line with one item by itself (and without
any indented sublists) is taken as a single item (not a list), unless it
is in parentheses (denoting a list). This is required because otherwise
there would be no easy way to indicate a symbol by itself.

Example:

(+ 1 (/ 2 3) f (my-function))

can become:

+
1
/ 2 3
f
(my-function)

It can also be represented as the equally valid:

+ 1 (/ 2 3) f (my-function)

Or as one of several hybrids:

+ 1
/ 2 3
f
(my-function)

Or:

+ 1 (/ 2 3)
f
(my-function)

Or:

+ 1 (/ 2 3) f
(my-function)

Rule 4: New syntax: use "..." and indentation to indicate a syntactic
list -- this is useful for list expressions starting with a list. One
can also just use "list" in some situations where the code is evaluated,
but the new operator is needed for constructing lists that are not
evaluated. The syntax "..." is a first try. A single character like "~"
might be better.

Example:

(let ((x 10) (y 20)) (* x y))

could become:

let ((x 10) (y 20))
* x y

Or it could become:

let
(x 10) (y 20)
* x y

Or it could become:

let
...
x 10
y 20
* x y

Note this last makes the structure of the variable assignment part very
clear, as it is basically a list of lists.

In general, one can then use "..." to start any list.

For example:

(+ 1 2)

can become:

...
+
1
2

"..." could also be used to start a line and is ignored as so:

... + 1 2


Rule 5: Blank lines (or with only white space) are ignored for purposes
of unnesting. (Comment lines may also contain leading blanks, although
I'm not certain on this.)

Example:

let
...
x 10

y 20

* x y

This is valid including the blank lines (which don't need to contain
spaces).

======= Choosing the amount of parentheses to reduce =======

Not all parentheses have to be removed -- some can be left for esthetic
reasons (keeping down the number of lines in the program). The example
"doodle" program given at the start could have even more parentheses
removed, at a cost of having more lines.

Example taken from the modified "doodle" example above:

(menu) (frm-return 'bye)

could become:

(menu)
frm-return 'bye

Note that the parentheses around "(menu)" can't be removed.

Or consider another fragment from a modified "doodle":

(pen-move pen-up)
draw (car args) (cadr args)

can be thought of as:

...
(pen-move pen-up)
draw (car args) (cadr args)

and then could be fully de-parenthesized as:

...
...
pen-move
pen-up
draw
car args
cadr args

Note that this re-parenthesizes back to Scheme as:

(
(
pen-move
pen-up)
(draw
(car args)
(cadr args)))

This is done by replacing each "..." with "(" and a matching ")"
elsewhere,
and by putting "(" and ")" around each line with two or more elements.

======= A smart parser =======

Note that a smart parser would allow lines to start with a "'("
combination, and would then expect a closing parenthese somewhere else.

For example:

(cons '(a b) '(c d))

could become:

cons
'(a b)
'(c d)

Although of course this could also be:

cons
quote
a b
quote
c d

Ideally one would indicate at the top of a file one was using this
convention, say with ";--indentation-significant--" or some such
directive.

It would seem one could easily convert back and forth between the two
standards with a smart editor, and always store the code with the
parentheses if desired.

If regular Lisp/Scheme parsing was simultaneously allowed, the following
would be ambiguous:

+
(+ 1 2)
+ 3 4

This is because it would not be clear whether the second line was to be
seen as a list with one element (a list of +, 1 & 2) or simply a list of
+, 1 & 2.

Thus, I think one would need to turn this mode of indentational parsing
on and off entirely.

One might however decide to allow "[ ]" or "{ }" or something like "(-:
:-)" to override this mode, in which case the parser would expect a
matching token, and interpret everything between those tokens using
conventional Lisp parsing rules.

======= More issues to consider =======

One issue is that parenthesization is redundant when you use
indentation.
You have to use indentation to make a program readable. So Lisp
programmers are already following more or less this indentational
convention.

Another way to look at it is, in practice, a Lisp coder is already doing
these rules implicitly as part of the conventional indentation process.
So this approach just loses some of the extra burden of worrying about
quite a few of the parentheses, which are syntactically redundant if
proper indentation is in place.

Another issue is that even though "LISP" stands for List Processing, in
reality you program in Lisp by creating Lists of Lists etc., which are
in effect trees. Indentation is a natural way to indicate tree
structure.

Yes, people put down Lisp saying it stands for "Lots of Infernal Stupid
Parentheses". Rather than be defensive, here is an approach that might
do something about what much of the world perceives as a difficulty in
reading and writing Lisp code.

Making indentation significant works for Python.
Why not make it work for Lisp too?

While some people can't get past significant indentation in Python
(citing for example occasional difficulty cutting and pasting code from
newsgroup posting or mail sent with old mail clients) and stick with
Perl, etc., the ones who do get past the unfamiliarity with
indentational syntax almost uniformly like it and say it is a feature
that aids program readability. Learning from Python's mistakes (tabs
are allowed and they are expanded inconsistently on various systems) I
would suggest always requiring two spaces per level of indentation.

I'm not going to say this wouldn't take some getting used to for
experienced Lisp hackers. Also, while I think these rules handle all
possible cases, even if they handle only 95% of typical Lisp code, the
mode could be turned off for those uncommon cases and then back on
afterwards.

======= Psychobabble justification =======

Some level of complexity in any task exists. It can often be pushed
around however, or refactored into different chunks. Sometimes, a
refactoring of compelxity will fit more naturally onto what most human
minds do well. Thus, sometimes, overall complexity of a cognitive task
can be reduced by breaking it into two tasks, each perhaps being fairly
complex, but neither as complex as the original task. Thus, sometimes,
the total complexity (as measured in learning time perhaps) from summing
the tasks has increased, yet, the overall difficulty experienced by a
person doing the total task is lower, because there is no step which is
beyond easy comprehension or learning.

This is because the human mind is quirky that way. This is in part
because of the way people learn and perceive things in "chunks", where
those chunks have a natural level of complexity. Cognitive George A.
Miller coined the phrase "the magic number 7 plus or minus 2" for
describing easily chunkable things. For example, it is easier to
remember a seven digit phone number than a fifteen digit number. He
understood later there is more to chunking than that. Short term memory
can hold perhaps 3 to 4 things, and rehearsal memory (repeating things
over and over) can hold perhaps 2 to 5. Together these let you run about
seven digits (each digit itself a chunk) through your mind while you
dial a seven digit telephone number. Of course, once you can "chunk" the
phone number, you can retrieve it from long-term memory. Still, it is
easiest to build these chunks if they are made of parts with a certain
low level of complexity that fits into short term and rehearsal memory
limits (where the data needs to be before it can get into long term
memory). I think the rules and limits for chunking may different
somewhat depending on the task being verbal, visual, auditory, tactile,
and so on, but the general principals of cognitive limits and chunking
almost always hold.

I think these indentational rules and Lisp parenthesization might be
such a case. These rules decompose the Lisp code reading and writing
tasks into more manageable (simpler) pieces that are easier to do
correctly. They do this by creating two less connected chunkable two
tasks -- indenting the structure correctly and then writing simpler
parenthesized code for some lines of the structure. So, the rules add
some complexity and learning curve to formatting and reading Lisp code
but with the advantage of making each subtask a little easier to do.
That indentational rule complexity combined with the reduced complexity
of coding simpler parenthesized expressions may in the mind's additive
calculus produce less total complexity to think about when programming
in Lisp than the total complexity experienced when doing a single
somewhat more complex task (than either of the indentational programming
tasks) of defining all structure solely with parentheses.

Note that people might also use this point to argue for the value of
hybrid languages with more syntax than Lisp (like Python or Smalltalk or
C). I nonetheless like Lisp's ability to use structure to denote what
other languages use syntax for, and think there is a lot of beauty and
power there. This proposal is an effort to find a middle ground between


fully parenthesized Lisp and a language with a more explicit syntax. I
think making indentation syntactically significant (like in Python)
might help produce something living in that middle ground.

======= Some more examples =======

Here are some simple examples:

(+ 1 2)

becomes:

+ 1 2

or:

+
1
2

A slightly more complex example (in Scheme):

(define (f-to-c fahrenheight) (* (- fahrenheight 32) (/ 5 9)))

can become:

define (f-to-c fahrenheight)
* (- fahrenheight 32) (/ 5 9)

Or, alternatively, using more indentation to denote sublists:

define (f-to-c fahrenheight)
*
- fahrenheight 32
/ 5 9

Or going even further (perhaps too far for esthetics?):

define
f-to-c fahrenheight
*
- fahrenheight 32
/ 5 9

======= Conclusion =======

Lisp uses structure to replace much of what other languages do with
syntax.
Understanding the physical tree structure of a Lisp program is paramount
to determining what it does. Why not let that structure be defined
syntactically by indentation as an option?

Any comments? Have I missed something technical that makes indentation
unworkable? Obvious it faces an uphill battle for social acceptance and
implementation into specific Lisp and Scheme systems.

If people think this idea is interesting and has no obvious technical
flaws, I may proceed to try and see if I can get this to work in
DrScheme.
http://www.cs.rice.edu/CS/PLT/packages/drscheme/index.html

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the GPL'd Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

David J. Cooper

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> I'm interested in using significant indentation (like in Python)
> http://www.python.org
> to replace many parentheses in Lisp or Scheme programs.
>
> Has this been tried before? If so, what was the outcome?
>

> ======= Small example =======
>

...

>
> Lisp uses structure to replace much of what other languages do with
> syntax.
> Understanding the physical tree structure of a Lisp program is paramount
> to determining what it does. Why not let that structure be defined
> syntactically by indentation as an option?
>
> Any comments? Have I missed something technical that makes indentation
> unworkable? Obvious it faces an uphill battle for social acceptance and
> implementation into specific Lisp and Scheme systems.
>
> If people think this idea is interesting and has no obvious technical
> flaws, I may proceed to try and see if I can get this to work in
> DrScheme.
> http://www.cs.rice.edu/CS/PLT/packages/drscheme/index.html
>


If you are going to try to get this to work in something, why not try
getting it to work in Emacs Lisp? I would think that to operate in
this mode you would want to be able to have a buffer you could with a
keychord switch between fully parentesized and significantly indented
representations. The Emacs compile command could simply convert to
parentesized mode before actually compiling, and files would also be
saved out in fully parenthesized mode by default (so they can be
compiled normally).


-dave


--
David J. Cooper Jr, Chief Engineer Genworks International
dco...@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com

Michael Hudson

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
David Bakhash <ca...@alum.mit.edu> writes:

> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>
> > I'm interested in using significant indentation (like in Python)
> > http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
>

> I don't know how to respond to this post, and please, don't take
> offense at anything I say.
>
> The idea of using whitespace to alter the meaning of code is absurd.
> I don't know how python continues to exist in its current state.

From an experienced Pythoneer: don't knock what you don't know.
Please. Have actually programmed in Python? Have you actually found
it's dependence on whitespace a problem (other than the "ooh this is
different therefore it's bad" response)? With a half-decent editor
you really shouldn't have any difficulties (hmm, now where have I
heard that defense before...?).

It has to be said, I agree with you in that I don't think this idea
would work for Common Lisp.

Just your daily dose from the anti-bigotry squad,
M.

--
C is not clean -- the language has _many_ gotchas and traps, and
although its semantics are _simple_ in some sense, it is not any
cleaner than the assembly-language design it is based on.
-- Erik Naggum, comp.lang.lisp

Christian Lynbech

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
I haven't read through all of your proposal, but a few things spring to
mind.

- one of the points of the syntax of lisp is that it makes it very
easy to parse; since devices without keyboards probably also are
short on other ressources, increasing the complexity in central
components may be the wrong way to go.

- devices withput keyboards typically also have very small
screens. Using whitespace rather than syntactic markers would spread
the code out more (geometrically speaking) and that may lose you
more than gained.

- why would you want to *program* on such a device? I can see the need
to write applications in lisp to be used on a small device, but I do
not think I would ever like to do any substantial programming on
it. If you only need to do small fixes or edit some conffile,
dealing with the parentheses wouldn't be so bad.

Any particular application that would need user interaction could of
course do things to cut down the necessary typing, but then it would
be something decided on an aplication-by-application basis. And one
thing that could help there is that most interactive applications are
somewhat line oriented in nature and this is a strong help when
designing the interface.

One such example is the Scheme Shell, which tries to go some way in
order to remove some of the parentheses. An URL is:

http://www.swiss.ai.mit.edu/ftpdir/scsh/


---------------------------+--------------------------------------------------
Christian Lynbech | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J
Fax: +45 8675 6881 | email: c...@ericssontelebit.com
Phone: +45 8675 6828 | web: www.ericssontelebit.com
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)


Rainer Joswig

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
In article <3990E003...@kurtz-fernhout.com>, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> I'm interested in using significant indentation (like in Python)
> http://www.python.org
> to replace many parentheses in Lisp or Scheme programs.
>
> Has this been tried before? If so, what was the outcome?

It has been done several times. The Symbolics Lisp machine
has for example an infix reader. Several parsers for
different syntaxes have been developed over time.
Dylan is a kind of a Lisp-dialect with a different syntax.
Lisp2 was such an effort. Etc. Etc.

Hardcore Lisp hackers usual love the prefix
parentheses-based Lisp syntax. The thing is that
Lisp systems have extremely good editor support
for Lisp expression manipulation. The killer is if you
have stuff like mouse copy/paste - nothing else comes
near to edit complex expressions very fast.

--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de

Paul Foley

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
On 08 Aug 2000 21:34:52 -0400, David Bakhash wrote:

> The idea of using whitespace to alter the meaning of code is absurd.
> I don't know how python continues to exist in its current state.

This is rather unfair. The use of indentation as the block structure
delimiter in Python is very nice, and works well *for Python*, although
it seems to be a fairly common source of frustration for C or Perl
users who want Python to be indistinguishable from their pet language.
[Python isn't the only language that uses indentation this way, BTW]

It's absurd *for Lisp*; I couldn't agree more.


[It seems to be a common misunderstanding among non-Lispers that Lisp
uses parentheses in much the same way as C uses braces, or Python uses
indentation. But this is wrong. The closest thing Lisp has to C's
braces is probably LET (what we're really talking about is PROGN, but
{...} in C also introduces a new local variable scope). But there's
no "closing brace" or "END-LET" -- it's implicit in the structure of
the code, just like the block-ending "outdentation" in Python.]

--
Nomina stultorum in parietibus et portis semper videmus. -- Cicero

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Philip Lijnzaad

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to

Paul> On 08 Aug 2000 21:34:52 -0400, David Bakhash wrote:
>> The idea of using whitespace to alter the meaning of code is absurd.

(well, whitespace in Lisp has *some* meaning, in that its absense from Lisp
code quickly renders it meaningless to humans ...)

>> I don't know how python continues to exist in its current state.

Paul> This is rather unfair. The use of indentation as the block structure
Paul> delimiter in Python is very nice, and works well *for Python*,

I concur.

Paul> It's absurd *for Lisp*; I couldn't agree more.

Well, there is clearly a connection here: most Lispers are very uncomfortable
reading Lisp code that is not indented properly. And proper Lisp indentation
ends up being not entirely dissimilar to what Python uses. So calling it
'absurd' is too strong as far as I'm concerned. But I also concur that using
whitespace-structuring inappropriate for Lisp; it doesn't by you anything.

Philip
--
When C++ is your hammer, everything looks like a thumb. (Steven Haflich)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk \ European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Rainer-

Thanks for the reply. Some comments below.

Rainer Joswig wrote:
>
> In article <3990E003...@kurtz-fernhout.com>, Paul Fernhout
> <pdfer...@kurtz-fernhout.com> wrote:
>

> > I'm interested in using significant indentation (like in Python)
> > http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
>

> It has been done several times. The Symbolics Lisp machine
> has for example an infix reader. Several parsers for
> different syntaxes have been developed over time.
> Dylan is a kind of a Lisp-dialect with a different syntax.
> Lisp2 was such an effort. Etc. Etc.

I hadn't though of these in this context. You're right.

But I might add, the two I know of (Symbolics infix and Dylan) are
attempts to put C/Pascal like syntax on Lisp. And poking around on the
web, it looks like Lisp2 does the same.

While these are attempts to substitute syntax for structure, I think
these have a very different look and feel to what I propose here.

In my proposal, the exact same tokens are always used as in a fully
parenthesized version. The only major difference is the replacement of
many parentheses by significant indentation. (And "..." in some cases).
In practice, the code would look almost the same except for lots of
parentheses at the edges of lines removed.

So, if I may rephrase the question more specifically, anyone know of an
"indentationally significant" Lisp or Scheme?

> Hardcore Lisp hackers usual love the prefix
> parentheses-based Lisp syntax. The thing is that
> Lisp systems have extremely good editor support
> for Lisp expression manipulation. The killer is if you
> have stuff like mouse copy/paste - nothing else comes
> near to edit complex expressions very fast.

You have a good point. (Although again, I am not proposing changing the
prefix based order of tokens -- just the "edge" parenthesization.) And
obviously, requiring building new editor support in Lisp or Scheme
development environments for indentation is a major difficulty of the
proposal -- assuming such support can ever be as good for indentation as
for parenthesization.

Many people say of Python, "well if indentation is significant, how do I
copy and paste code?"

I think the answer is that when you copy and paste and code -- be it
Lisp or C or whatever, you still need to make the indentation work out
to make the code readable. Often as not this is done by hand. Yes, some
editors could pretty print the code after cut and paste, but for short
things typically one may fix it up by hand, especially if you don't
always agree with the pretty-printer.

Editors designed to support indentation usually have block indent and
block dedent commands. This makes the procedure of copying code more
like: "cut", "paste" and then "block indent/dedent to desired nesting".

For example, Python's "IDLE" development editor
http://www.python.org/idle/
supports this sort of block indent and dedent. Just select the code and
line it up as needed with a few keyboard commands.

> Rainer Joswig, Hamburg, Germany
> Email: mailto:jos...@corporate-world.lisp.de

Thanks again for the comments.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Christian-

Thanks for the reply, especially to commenting on issues for Lisp/Scheme
on handheld devices. Some comments below.

Christian Lynbech wrote:
>
> I haven't read through all of your proposal, but a few things spring to
> mind.
>
> - one of the points of the syntax of lisp is that it makes it very
> easy to parse; since devices without keyboards probably also are
> short on other ressources, increasing the complexity in central
> components may be the wrong way to go.

This is a very good point I hadn't thought of. Thanks for bringing it
up.

Yes, indentational parsing may burn more CPU cycles, and so take perhaps
take longer and use up the battery more quickly. I don't have any
figures to see how much of a hit this will be. I would expect it
wouldn't be that bad compared to everything else going on during
parsing.



> - devices withput keyboards typically also have very small
> screens. Using whitespace rather than syntactic markers would spread
> the code out more (geometrically speaking) and that may lose you
> more than gained.

Yes, and no.

When I tried rewriting that LispMe example on the Palm, actually some
lines that had wrapped were no longer wrapped. That is because each line
typically might lose two parentheses, maybe more. Remember that for
readability, the code is probably already indented. So there is usually
just a net loss of parentheses at the edges.

Since handheld screens are typically narrow, it is easier to have code
that is taller and less wide -- because it is easier to just scroll up
and down, rather than scroll left to right or look at confusingly
wrapped lines.

This indentational syntax makes it easy to write code that is not very
wide, because you can always convert something like:

+ long-name another-long-name -another-very-long-name

to:

+
long-name
another-long-name
another-very-long-name

> - why would you want to *program* on such a device?

Well, really mainly for fun. I imagine it might also be useful in some
mobile situations.

As a practical reason (reaching here), maybe instead of natural language
one would want to write Lisp expressions to control your VCR or
Thermostat from your Palm on the run... Realistically though, it might
just be an interesting amusement to code Lisp expressions in unusual
situations. :-)

The only really plausible and useful scenario I can think of is that
you're a system administrator or network troubleshooter or repair
person, walking around a facility with a lot of equipment, and you need
to do come configuration or write a quick test script standing in front
of a network type device without a visual interface (but with a network
interface). Perhaps your simple on-the-fly test script really just calls
other more complex test scripts written on a desktop.

> I can see the need
> to write applications in lisp to be used on a small device, but I do
> not think I would ever like to do any substantial programming on
> it. If you only need to do small fixes or edit some conffile,
> dealing with the parentheses wouldn't be so bad.

In general, you are right. It is much easier to do programming on a big
screen. But even on the big screen, I think indentational syntax for
Lisp and Scheme may have some value.

I had thought of the indentational idea before using LispMe, but it was
motivational to see some additional value in indentation, prompting me
to post (although I was planning to eventually). My main interest in
indentational use right now is actually for programming using a desktop.

> Any particular application that would need user interaction could of
> course do things to cut down the necessary typing, but then it would
> be something decided on an aplication-by-application basis.

In general I agree. However, rather than have Lisp/Scheme using
applications decide on their own how to cut down on typing, it might be
nice to have a standard.

This assumes this indentational one makes technical sense - i.e. it is
complete enough to actually define and regenerate all Lisp/Scheme
expressions. I haven't yet seen any comments that the five rules are not
complete.

> And one
> thing that could help there is that most interactive applications are
> somewhat line oriented in nature and this is a strong help when
> designing the interface.

In Python, the command line knows about indentation, so it helps with
indenting, and it also knows not to evaluate your expression which uses
indenting until you have finished it (which in practice means you may
need to enter a blank line at the end).

That extra blank line at the end of entering an interactive expression
is more work, but I think it is worth it given that there is less typing
of parentheses and less chance of related nesting mistakes.

Since some interactive environments let you enter code and then select
and evaluate it by highlighting it and pressing some command key
sequence, in that case no extra blank line needs to be typed, because
the end of the highlighted section indicates the end of the snippet.



>
> One such example is the Scheme Shell, which tries to go some way in
> order to remove some of the parentheses. An URL is:
>
> http://www.swiss.ai.mit.edu/ftpdir/scsh/

I'll need to look at this more. The first examples I see are fully
parenthesized.

You've given me an idea though. Perhaps if SCSH supported this
indentational style, and used the extra blank line idea above, it might
be easier to code Scheme on the interactive command line by using this
indentational syntax, requiring a blank line or other do-it marker
(perhaps "!") at the end.
Does SCSH already support this then?

For example (taken from the web page):
http://www.swiss.ai.mit.edu/ftpdir/scsh/html/description.html

gunzip < paper.tex.gz | detex | spell | lpr -Ppulp &

would be written in scsh as

(& (| (gunzip) (detex) (spell) (lpr -Ppulp))
(< paper.tex.gz))

And in indentational syntax as:

&
| (gunzip) (detex) (spell) (lpr -Ppulp)
< paper.tex.gz

The indentational approach has six less non-space characters (all were
edge parentheses). It does have two more spaces.

Which do you think you would be more likely to type in correctly the
first time?

Which is easier to visually inspect and confirm correct before
committing to doing it (given that indentation can lie in the
parenthesized case)?

Realistically, which would you rather type on the fly?

Parentheses are fine in an editor with lots of support, but they
can be an extra distraction IMHO at the command line because they
require a higher degree of precision and thought than indentation in a
less forgiving environment (not to invite too many flames, please!)

---------------------------+--------------------------------------------------
> Christian Lynbech | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J
> Fax: +45 8675 6881 | email: c...@ericssontelebit.com
> Phone: +45 8675 6828 | web: www.ericssontelebit.com
---------------------------+--------------------------------------------------

Thanks again for the comments and pointer to SCSH in this context!

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

David Bakhash

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Michael Hudson <mw...@cam.ac.uk> writes:

> David Bakhash <ca...@alum.mit.edu> writes:
>
> > Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
> >

> > > I'm interested in using significant indentation (like in Python)
> > > http://www.python.org
> > > to replace many parentheses in Lisp or Scheme programs.
> > >
> > > Has this been tried before? If so, what was the outcome?
> >

> > I don't know how to respond to this post, and please, don't take
> > offense at anything I say.
> >

> > The idea of using whitespace to alter the meaning of code is absurd.

> > I don't know how python continues to exist in its current state.
>

> From an experienced Pythoneer: don't knock what you don't know.
> Please. Have actually programmed in Python? Have you actually found
> it's dependence on whitespace a problem (other than the "ooh this is
> different therefore it's bad" response)? With a half-decent editor
> you really shouldn't have any difficulties (hmm, now where have I
> heard that defense before...?).

First off, I only gave my opinion that I didn't like that idea, across
the board. I never said it didn't work for Python, and of course,
I've seen lots of very neat python programs, such as the one which
makes Dragon Naturally Speaking Preferred (which is usually not good
enough for coding in) good enough for coding in.

It is still not true that I have no experience with whitespace
dependence. I do; just not with python. I'm one of those unfortunate
people that spent half a day trying to debug a perfect csh script
because it didn't end in a newline. It was weird: 15 minutes to
write, ~3 hours to debug. Granted, I just didn't have a clue about
what the problem was, and so I wasn't looking for it.

After a good nite's rest, a useful conversation with someone else
about this proposal, and some more thought, I can finally state why
this is wrong for Common Lisp, hopefully more coherently than my last
post.

Common Lisp is to Python what free verse is to structured, metered
poetry. The two are really at different ends of the spectrum, though
maybe not at the very ends, and surely not at their theoretical ends.
It's not that one can't do what was proposed, but that it defeats the
purpose of Lisp in the first place. But then you ask yourself, what
if you want to write _mostly_ free-verse poetry that has some rhythm
and meter. Surely, you can. In Lisp, you do this by _providing_ the
proper indentation. A lot is left to the programmer. But if you
restrict the programmer from writing certain forms the way they want,
e.g. by forcing a newline when an expression is so short that (s)he may
not _want_ a newline, for the purposes of readability (and supposedly
writability, as the original poster indicated), then you're holding
the programmer's hand to the point of crushing it.

From what you've said, and some guessing on my part, it's probably the
case that if you're programming Python is say GNU Emacs, then the
indentation is as simple as knowing when to press the <ENTER> key and
then indenting, which can be done in a single keystroke if you bind
'newline-and-indent to the <ENTER> key. Of course, you have to space
tokens and stuff, and put the proper delimiters between certain
fields, but this is always the case.

What I think would be neat is a pretty-printer that would produce more
"readable" lisp code, where readability is inversely related to the
number of perens, as the original poster suggested. So basically,
spit back some non-lisp-reader-readable lisp code that's more human
readable, but without the parens. I guess that with user-defined
macros being used, this would be hard to do, but it might address this
readability issue without affecting (infecting) writability.

I think that in most of the free CL implementations out there, the
pretty-printer is written in CL as well, and so it might not be too
hard to incorporate the aforementioned rules for eliminating parens
and adding certain required indentation. I'd be interested to see
it. There's also the Emacs 'cl-prettyprint function which is written
in elisp that can be altered to produce this effect.

dave

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
David-

Thanks for the reply.

In general, what you propose (doing indentational support for Lisp /
Scheme in emacs instead of DrScheme) makes a lot of sense in terms of
making this feature generally available to the Lisp community for user
testing.

Your outline sounds great -- of how to do indentational support so it is
useful and available in emacs while not getting in the way.

However, for various reasons I am working in DrScheme right now, so it
is of more practical value for me personally to do it in that
environment. I'm also not really current with emacs (last having
significantly used it a very long time ago.)

Hopefully, whatever parsing code I might develop would be readily
portable...

However, it may be less work to do try it in emacs, so I'll think about
what you suggest some more. How hard would it be to do this in emacs?

By the way, if anyone implements this themselves in emacs, please let me
know.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com


"David J. Cooper" wrote:


>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>
> > I'm interested in using significant indentation (like in Python)
> > http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
> >
>
> > ======= Small example =======
> >
>

> ...


>
> >
> > Lisp uses structure to replace much of what other languages do with
> > syntax.
> > Understanding the physical tree structure of a Lisp program is paramount
> > to determining what it does. Why not let that structure be defined
> > syntactically by indentation as an option?
> >
> > Any comments? Have I missed something technical that makes indentation
> > unworkable? Obvious it faces an uphill battle for social acceptance and
> > implementation into specific Lisp and Scheme systems.
> >
> > If people think this idea is interesting and has no obvious technical
> > flaws, I may proceed to try and see if I can get this to work in
> > DrScheme.
> > http://www.cs.rice.edu/CS/PLT/packages/drscheme/index.html
> >
>

Rainer Joswig

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
In article <399156EB...@kurtz-fernhout.com>, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> But I might add, the two I know of (Symbolics infix and Dylan) are
> attempts to put C/Pascal like syntax on Lisp. And poking around on the
> web, it looks like Lisp2 does the same.

Don't forget Haskell. ;-)

> For example, Python's "IDLE" development editor
> http://www.python.org/idle/
> supports this sort of block indent and dedent. Just select the code and
> line it up as needed with a few keyboard commands.

What I usually do is the following:

I have a bunch windows with code I'm currently working on.
The code is my working context. This includes browsers
and inspectors full of symbols.

So I start maybe a function:

(defun send-a-mail (from to subject)
(let ((body (get-body 'introduction)))

Then I just type "(s-m" and press complete: meta-i).
A completion window let's me find smtp:send-mail
and inserts it into the window. Pressing space
inserts a space and shows the arguments in the
window's lower part. Now I just do command-click
on the symbols "from", "to", "subject", "body"
and the editor inserts them after the function
and inserts spaces between them.
the editor has the following other features:

- double-click on a symbol selects the symbol
- double-click on one parentheses selects the
whole expression
- command-click on a symbol inserts the symbol
at the current insertion point or replaces
the current selection (see above)
- command-click on a parentheses inserts the
whole expression at the the current insertion
point or replaces the current selection (see above)

This makes writing and changing code a sequence of
clicks. Now add symbol completion, indentation, source
coloring, transposing of expressions, moving the cursor
across expressions, expression highlighting, who calls
listings, automatic arglist displays, apropos dialogs, list definitions
dialogs, inspecting, in-place evaluation, parentheses blinking,
warnings for missing parentheses, macro expansion, keyboard
macros, voice control, ...

Well, and this is still far from what the Lisp machine's
Zmacs does, where the editor for example parses the buffers into
definition chunks. So you edit a while in your various
Lisp buffers and after a while you say "Compile Changed
Definitions" and the Lisp system knows what definitions
you have changed and compiles them. And much more other
advanced stuff like source locators, patching, presentation
parsing from buffers, mouse macros, unlimited undo, ...

Personally I'd guess, an advanced Lisp development environment
is really *hard* to beat in editing speed.

--

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
David-

Thanks for the reply. No offense taken.

And thanks also to Michael Hudson and Paul Foley for their additional
comments replying to your post, which mostly support your main argument.

I think you have many valid points, especially about learning curves and
people's preferences. And the whole approach might cause
interoperability problems if not handled well. Obviously we disagree
somewhat on the value of indentation, but that's OK. Frankly, I might
not even like the approach I outlined myself (removing edge parentheses)
after I try to use it for a while in a Lisp or Scheme environment. After
all, I'm not speaking from experience using such an indentational
approach to do Lisp or Scheme. You, on the other hand, are speaking from
experience -- obviously the Lisp syntax as it is written now works well
for you (and others in this newsgroup).

I'm only very recently getting back into Lisp/Scheme (using DrScheme).
The last time I used Lisp significantly was many, many years ago
(ZetaLisp + Flavors on a Symbolics around 1987). So I admit my mind
hasn't had time to re-adapt yet to making the parentheses seem like
water to fish. It's quite possible that with a little more time spent
writing and reading Lisp/Scheme code again, I may not consider this
issue as important. However I haven't quite reached that stage yet.

Right now I'm more trying to get feedback on whether it could
theoretically work and maybe then be potentially useful to some people
(for example, people who know Python and want to try Lisp or Scheme).

So, getting beyond the practicalities and all the valid objections you
and others raise, is there any technical reasons why the specification
and rules I propose are incomplete (i.e. are there any valid Lisp or
Scheme programs or related list data structures the rules can't encode
using indentation)?

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

David Bakhash wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>

> > I'm interested in using significant indentation (like in Python)
> > http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
>

> I don't know how to respond to this post, and please, don't take
> offense at anything I say.
>
> The idea of using whitespace to alter the meaning of code is absurd.
> I don't know how python continues to exist in its current state.

> > This proposal is an effort to find a middle ground between fully
> > parenthesized Lisp and a language with a more explicit syntax. I
> > think making indentation syntactically significant (like in Python)
> > might help produce something living in that middle ground.
>

David Bakhash

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Philip Lijnzaad <lijn...@ebi.ac.uk> writes:

> Paul> On 08 Aug 2000 21:34:52 -0400, David Bakhash wrote:

> >> I don't know how python continues to exist in its current state.
>

> Paul> This is rather unfair. The use of indentation as the block structure
> Paul> delimiter in Python is very nice, and works well *for Python*,
>
> I concur.

yeah. I was off the handle. I havn't used Python, so it's probably
not fair to say such a thing, even though I've read a bunch of Python
code since and understand the concept of indentation-dependence, and
understand why it exists, and even to some extent why it caught on.

As an aside, I recently talked to a guy that's been programming CL for
about 20 years, and also C, Java, and Perl and is a professional
developer for a nearby company, and told me that he gave Python his
best effort and had to abandon it, mostly because of indentation
frustration. It's not unheard of for programmers to lose interest in
Python based on its indentation practice.

> Paul> It's absurd *for Lisp*; I couldn't agree more.
>
> Well, there is clearly a connection here: most Lispers are very uncomfortable
> reading Lisp code that is not indented properly. And proper Lisp indentation
> ends up being not entirely dissimilar to what Python uses. So calling it
> 'absurd' is too strong as far as I'm concerned. But I also concur that using
> whitespace-structuring inappropriate for Lisp; it doesn't by you anything.

agreed. but consider that the original poster was not just talking
about indentation for the sake of block readability, but stressed the
removal of parens as noise characters, and that is what I was more
concerned with. So, I have to disagree: the elimination of parens
*is* something, and that was the main purpose of the original post: to
use indentation rules to supplant paren usage.

dave

Paolo Amoroso

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
On Wed, 09 Aug 2000 00:37:23 -0400, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> I'm interested in using significant indentation (like in Python)
> http://www.python.org
> to replace many parentheses in Lisp or Scheme programs.
>
> Has this been tried before? If so, what was the outcome?

I don't know about significant indentation, but an Algol-like syntax has
been tried as a way of replacing parentheses. Check section 3.5.1
"Algol-Style Syntax" of the paper "The Evolution of Lisp" by Richard
Gabriel and Guy Steele:

ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/Evolution-of-Lisp.ps.gz

What was the outcome? Well, note that section 3.5.1 is a subsection of 3.5,
which is titled "Some Notable Failures".


> This example was taken from the LispMe (Lisp for the Palm) sample
> code. http://www.lispme.de/lispme/

[...]


> One advantage to such an approach it that it might make it easier to
> compose Lisp on devices without keyboards. An indent-line button and an
> unindent-line button would be useful in that case.

If you are a LispMe user, I suggest that you check the pedit family of
shareware text editors:

http://www.math.ohio-state.edu/~nevai/palm/

pedit already has both of the features you mention. It provides a form of
automatic indentation that, while it doesn't offer the full power of
Lisp-aware editors such as Emacs, it works well most of the time.
Concerning the unindent line feature, pedit provides commands "Edit+/Shift
Left" and "Edit+/Shift Right" for moving blocks of text.

LispMe and pedit provide a comfortable Lisp editing environment,
considering the hardware and software constraints of the device they run
on.


> Significant indentation might make it easier for developers who don't
> know Lisp well to understand a Lisp program's structure.

Lisp developers already rely on indentation to understand a Lisp program's
structure. Although indentation is not enforced by Lisp systems, it is
sufficiently well standardized.


> It might also allow experiences Lisp developers to read programs faster
> because there is less high frequency "noise" in the text. Every

As someone else pointed out in this thread, parentheses "disappear".
Parentheses are simply not an issue for experienced programmers, and at
times even for novices.


> Such code will be faster to create. There is less typing, and no worry
> about unbalanced parentheses. Indentation might be incorrect, but then

LispMe provides some support for saving typing. If you type a form in the
input field (more or less the equivalent of a listener's prompt), you can
omit all the final parentheses.


> ======= Some disadvantages =======
>
> I'm sure people will point out lots. Send 'em on!

* It's simply not worth the effort.

* In the case of small devices such as the Palm, a more complex parser with
significant indentation may unnecessarily increase the memory footprint of
a Lisp system. Since entry level Palm devices have 2M of RAM, this may be
an issue.


> Another issue is that even though "LISP" stands for List Processing, in

After over 40 years of evolution, "Lisp" stands for list, array, hash
table, rational, bignum, character, pathname, structure, class, etc.
processing.


> Yes, people put down Lisp saying it stands for "Lots of Infernal Stupid
> Parentheses". Rather than be defensive, here is an approach that might
> do something about what much of the world perceives as a difficulty in
> reading and writing Lisp code.

It doesn't work. See the above mentioned paper.


> Making indentation significant works for Python.
> Why not make it work for Lisp too?

Hint: parentheses-based syntax works for Lisp; why not make it work for
Python too?


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Rainer -

Thansk for the reply, and the great example of Lisp editor capabilities.

What you outline for the coding support in Lisp you currently get is
indeed impressive. It reminds me of what a joy it was to work on a
Symbolics 3600. For years I still hoped for command completion in
development various systems (mostly C editors), alas, always to be
disappointed.

I guess I wonder which of the features you mention would be more
difficult (or even impossible) to impliment in an indentational syntax
mode for Lisp.

As a counter example, some Smalltalk systems provide many of the
features you describe (and perhaps some other ones) without directly
relying on list structure for code. I think the same holds for some
other languages as well.
Naturally, Lisp may have had many of these advanced features first, and
one might argue they are the most well developed, consistent, and
complete in Lisp development environments. Still, that does not mean
they might not work alongside indentational syntax. To an extent, it may
depend on whether those facilities rely on textual analysis of a program
(and how the code is externally stored) as well as whether they operate
on an internal parse tree of the code.

If I may add something, when you wrote:

(defun send-a-mail (from to subject)
(let ((body (get-body 'introduction)))

I had to actually count the parentheses to see if this was a complete
statement, to see if you were referring to inserting something within
the current structure or at the end of it. It wasn't immediately obvious
to me whether this fragment was a valid Lisp program or not. It is not.

If you had written (in indentational syntax, removing edge parentheses):

defun send-a-mail (from to subject)
let
...
body (get-body 'introduction)

there would not be any question about validity. This has to be a valid
expression. At almost every point, an indentational syntax specification
is valid. The only exception is unclosed parentheses started within a
line, although typically they would end on the same line too. This makes
me realize I may have the beginnings of a selling point here. On the
other hand, others might argue this is a weakness -- the code can be
evaluated before it is finished, perhaps to detrimental or unexpected
results.

With indentational syntax, one could easily see what you are saying you
do is:

defun send-a-mail (from to subject)
let
...
body (get-body 'introduction)
<YOU ADD NEW CODE HERE WITH COMMAND COMPLETION>

In the case you describe, the editor is smart enough to look up the tree
of the partial definition and grab the relevant variables for choices in
helping you complete the expresion. I don't see any reason an
indentational syntax would prevent a smart editor from doing that. It
might even be easier to code this lookup in some ways, since it might be
easier to map a specific line of code into a leaf in a tree branch of
nested scopes, with less code for dealing with incomplete or unclosed
expressions.

Obviously if one has to choose between all those editor features you
list and indentational syntax, one would choose to have all the other
features. But the technical question then is, could one have those
features and indentational syntax too?

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

thi

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> For example (taken from the web page): [snip]


>
> Which do you think you would be more likely to type in correctly the
> first time?
>
> Which is easier to visually inspect and confirm correct before
> committing to doing it (given that indentation can lie in the
> parenthesized case)?
>
> Realistically, which would you rather type on the fly?
>
> Parentheses are fine in an editor with lots of support, but they
> can be an extra distraction IMHO at the command line because they
> require a higher degree of precision and thought than indentation in a
> less forgiving environment (not to invite too many flames, please!)

in all cases i would prefer the parens, since i run shells from within emacs
(even python). for command sequences, the value metric is encapsulatability,
ie, easy cut and paste. internal whitespace requirements such as newline and
multiple spaces severely hampers the quick movement of text to different
contexts. many times, a complex command is composed by testing out simpler
commands; composition of sexps is trivial and not a spaces-counting chore.

thi

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Paolo-

Thanks for the reply and the pointer to the paper.
Some comments below.

Paolo Amoroso wrote:
>
> On Wed, 09 Aug 2000 00:37:23 -0400, Paul Fernhout
> <pdfer...@kurtz-fernhout.com> wrote:
>

> > I'm interested in using significant indentation (like in Python)
> > http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
>

> I don't know about significant indentation, but an Algol-like syntax has
> been tried as a way of replacing parentheses. Check section 3.5.1
> "Algol-Style Syntax" of the paper "The Evolution of Lisp" by Richard
> Gabriel and Guy Steele:
>
> ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/Evolution-of-Lisp.ps.gz

Thanks for the online pointer. I had read a version of that before in
the book "History of Programming Languages" edited by Bergin and Gibson.

> What was the outcome? Well, note that section 3.5.1 is a subsection of 3.5,
> which is titled "Some Notable Failures".

OK. I reread that. It pertains specifically to Algol-like syntax. In
fact, one proposal suggests using "begin" and "end" instead of
parentheses, which is completely the opposite of my intent of reducing
visual clutter.

As I pointed out in another reply, this proposal does not in any way
relate to changing the order of operators to infix, or doing any other
sort of structural change beyond removing edge parentheses using
syntactically significant indentation. (All right, well I do introduce
"..." to start a list of lists.)

There is very little in that section about indentation, other than to
say that indentation has become more or less standardized. I don't think
any of these points in the section apply directly to an indentational
syntax that removes edge parentheses. They apply perhaps indirectly to
the issue of whether a program looks like a data structure, as well as
whether my proposal is a "rite of passage". :-)

> > This example was taken from the LispMe (Lisp for the Palm) sample
> > code. http://www.lispme.de/lispme/

> [...]


> > One advantage to such an approach it that it might make it easier to
> > compose Lisp on devices without keyboards. An indent-line button and an
> > unindent-line button would be useful in that case.
>

> If you are a LispMe user, I suggest that you check the pedit family of
> shareware text editors:
>
> http://www.math.ohio-state.edu/~nevai/palm/
>
> pedit already has both of the features you mention. It provides a form of
> automatic indentation that, while it doesn't offer the full power of
> Lisp-aware editors such as Emacs, it works well most of the time.
> Concerning the unindent line feature, pedit provides commands "Edit+/Shift
> Left" and "Edit+/Shift Right" for moving blocks of text.
>
> LispMe and pedit provide a comfortable Lisp editing environment,
> considering the hardware and software constraints of the device they run
> on.

Thanks for the pointer.

> > Significant indentation might make it easier for developers who don't
> > know Lisp well to understand a Lisp program's structure.
>

> Lisp developers already rely on indentation to understand a Lisp program's
> structure. Although indentation is not enforced by Lisp systems, it is
> sufficiently well standardized.

My point is, if standardized indentation is already the case with Lisp,
then in actuality the "edge" parentheses are superfluous
(syntactically), and perhaps some benefits in some cases could be
obtained by not displaying them or requiring them to be typed in. Of
course, there may be some costs as well.

> > It might also allow experiences Lisp developers to read programs faster
> > because there is less high frequency "noise" in the text. Every
>

> As someone else pointed out in this thread, parentheses "disappear".
> Parentheses are simply not an issue for experienced programmers, and at
> times even for novices.

Well, obviously what you say is true for Lisp developers, and so
probably almost anyone reading this newsgroup. While I've learned a lot
form people's comments, not one person yet has really written, "Yes, I'd
like my Lisp code with less parentheses, please." Or, "One Scheme
define, hold the extra parentheses, please." :-)

But how many people are there out there who might develop in Lisp and
Scheme who never can get past the parentheses? Obviously, Lisp has not
caught on yet in commercial usage to the degree it deserves compared to
say C, considering the elegance and power of the system (notable
exceptions like http://www.franz.com/success/ excepted). Instead, more
people are doing C, Visual Basic, and Python etc. I understand there are
many, many reasons for a language's fate that have little to do with the
language itself, for example Java hype or even "Worse is Better".
http://www.jwz.org/doc/worse-is-better.html
Still, maybe this indentational technique could help bring more people
into doing Lisp or Scheme?

Just because parentheses have vanished for the people who stick with
Lisp does not mean one can conclude this would be the case for everyone
no matter how long they code in Lisp. Different people have different
abilities and strengths and weaknesses. Dealing with lots of high
frequency noise on a page (side by side parentheses) and spotting the
relevant code may itself be a specific visual ability (I remember being
tested for something like this on the ASVAB -- picking out "c"'s from a
list of "o"'s). Not everyone may be good at that. Neither can one
conclude that that existing Lisp developers might not benefit from an
alternative in the long term, even if the current one works well.

Let me give an example.

Psychological studies have show that mixed case is easier to read than
all upper case or all lower case. They have also shown that all lower
case is easier to read than all upper case. This is because all upper
case provides the least information to the eye about each letter,
because they are all the same height. The eye can use height information
to more quickly recognize a letter. Thus, all upper case is the most
difficult and slowest to read, and most likely to be read incorrectly.
That is why it is more rarely used, and one reason it thus stands out.

For a very long time (and even today in many COBOL shops) people wrote
programs in all upper case, and textbooks had programs in all upper
case. This has become an accepted cultural way of presenting computer
programs. Yet, with one XEDIT editor command a COBOL programmer could
be looking at a COBOL program that is much easier to read. But often for
example a COBOL developer won't make that change (I asked one once)
because it is not the convention. Even worse, companies then create
coding standards that the code will be in all upper case. And they can
point to the books and say that is the standard defined in the books.
And so, no progress is made. So too for most computer manuals, which can
show programs in different fonts, or styles, or sizes, but even now some
probably still resort to all upper case (and maybe make it bold too).
This is even though relevant psychological research on upper and lower
case perception would suggest these programmers are all being less
efficient because these programs are all harder to read.

I'm not necessarily claiming this approach to removing edge parentheses
would definitely have the same magnitude of benefits gained say when
Lisp moved from being written in all upper case to being written usually
in all lower case. I also don't know yet if this approach would have
benefits outweighing the costs. But I do wonder what the resistance was
like back then when Lisp moved from upper case to lower case. Any long
time Lisp users care to comment on that transition?

> > Such code will be faster to create. There is less typing, and no worry
> > about unbalanced parentheses. Indentation might be incorrect, but then
>

> LispMe provides some support for saving typing. If you type a form in the
> input field (more or less the equivalent of a listener's prompt), you can
> omit all the final parentheses.

Thanks for pointing this out.

> > ======= Some disadvantages =======
> >
> > I'm sure people will point out lots. Send 'em on!
>

> * It's simply not worth the effort.

OK. I don't think it would take much effort to test it though.



> * In the case of small devices such as the Palm, a more complex parser with
> significant indentation may unnecessarily increase the memory footprint of
> a Lisp system. Since entry level Palm devices have 2M of RAM, this may be
> an issue.

Good point, and one Christian Lynbech else made as well. I don't know
for sure how big a hit this would be, but I doubt it would be very
large.



> > Another issue is that even though "LISP" stands for List Processing, in
>

> After over 40 years of evolution, "Lisp" stands for list, array, hash
> table, rational, bignum, character, pathname, structure, class, etc.
> processing.

OK. Excellent point.

> > Yes, people put down Lisp saying it stands for "Lots of Infernal Stupid
> > Parentheses". Rather than be defensive, here is an approach that might
> > do something about what much of the world perceives as a difficulty in
> > reading and writing Lisp code.
>

> It doesn't work. See the above mentioned paper.

I don't think the paper supports as broad a conclusion as all that.
Frankly, I agree with the thrust of that section of the paper.
Algol-like syntaxes (infix operators, etc.) are against the elegance of
Lisp -- specifically seeing code and data in the same format.

However, I don't see that this proposal of removing "edge" parentheses
with an indentational notation would necessarily fail for the same
reasons. Fundamentally, very little about the syntactical structure of
Lisp is changed. It is just some redundancy that is removed (given that
you need consistent indentation anyway for readability).

> > Making indentation significant works for Python.
> > Why not make it work for Lisp too?
>

> Hint: parentheses-based syntax works for Lisp; why not make it work for
> Python too?

Python succeeds in part because of indentation. It also succeeds in part
because it looks a lot like C. Take both of those away, and one almost
might as well be using Lisp, Smalltalk, Perl, or Visual Basic. All one
would have left is a lot of nice libraries, a pure OO feel, portability,
and a permissive license.

> Paolo
> --
> EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
> http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Thanks again for the pointer and comments.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Peter Norvig

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
I have no objection to the less-parentheses style. I'd say I wouldn't
use it when editing in emacs, unless s-expression commands support
indentation as thoroughly as they do parens. But when I write code on
paper, I often use a style like this to save time. I think using this
is like using an infix-syntax parser for mathematical expressions: if
used in moderation it can be helpful, especially in communicating with a
community that aren't used to the parens.

Actually, there are other aspects of Lisp syntax that I find more
annoying than the parens. Compare

s.X[i] = val
to
(setf (aref (csp-state-x s) i) val)

The later is what I ended up coding in a constraint satisfaction solver
I was recently working on. The annoyance is that the former (legal
Python, Java or C++) is close enough to what is used in the theoretical
literature that I can understand it in one glance, while the Lisp code
takes two glances to understand. Why does Python/Java/C++ have an
advantage? Because they typographically distinguish useful operations:
assignment in Python/Java (and confusingly, copying in C++); indexing;
and class slots. And also because classes are namespaces in Python/C++,
but not in Lisp (so I can use X instead of csp-state-x). Lisp
multimethods are the preferred solution for complex applications, but
Python/Java/C++ classes do make the easy cases easier.


-Peter Norvig

Rainer Joswig

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
In article <3991881D...@kurtz-fernhout.com>, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> If I may add something, when you wrote:
>
> (defun send-a-mail (from to subject)
> (let ((body (get-body 'introduction)))
>
> I had to actually count the parentheses to see if this was a complete
> statement, to see if you were referring to inserting something within
> the current structure or at the end of it. It wasn't immediately obvious
> to me whether this fragment was a valid Lisp program or not. It is not.

I'm moving around in a Lisp buffer by Lisp expressions.
I can easily "feel" whether this is valid or not, because
I'm not only looking on the code, but I **feel** the code under
the cursor. The belonging parentheses blinks if I place my cursor
in front of the defun. If there is nothing blinking at the end
I have a problem. If I move the cursor over the expression
(c-m-forward or c-m-f) I see where it ends. Another keypress
and the whole thing reindents. Another keypress: undo.
I don't think about that - it's just learned and works
intuitively.

> If you had written (in indentational syntax, removing edge parentheses):
>
> defun send-a-mail (from to subject)
> let
> ...
> body (get-body 'introduction)
>
> there would not be any question about validity. This has to be a valid
> expression. At almost every point, an indentational syntax specification
> is valid.

Not really. In Lisp you can write multiple level macros and
Lisp expressions that have complex indentation descriptions.

How do I now that

foo bar
baz

is valid? How do I know that baz needs another item behind it?
How do I now that it needs another line to be complete?
How do you see it when you have an indentation depths
of 120 characters? How do add additional ways of code formatting?
On a Symbolics I often try different ways of code formatting
(just press c-Tab multiple times to experiment with
different indentations on the current line).

> In the case you describe, the editor is smart enough to look up the tree
> of the partial definition and grab the relevant variables for choices in
> helping you complete the expresion. I don't see any reason an
> indentational syntax would prevent a smart editor from doing that. It
> might even be easier to code this lookup in some ways, since it might be
> easier to map a specific line of code into a leaf in a tree branch of
> nested scopes, with less code for dealing with incomplete or unclosed
> expressions.

Actually I don't like the system telling me whether I have to write:

(+ a b)
(+ a
b)

(+
a
b)

(+
a b)

Then Common Lisp has keyword args, optional args , ...

> features. But the technical question then is, could one have those
> features and indentational syntax too?

You could have a lot of these. Hey, there was once a Haskell
implementation written in Common Lisp. Haskell has also
an indentation based syntax. AXIOM (a computer algebra system
written in Common Lisp) also has an indentation based
syntax (IIRC). So there might be some reason to experiment
with it.


But then why not go further? For MCL there are quite a few
graphical programming systems. In "Open Music" you draw
CL programs in a 2d plane. In "Boxer" code is a bunch
of nested 2d boxes.

Johan Kullstam

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> I'm interested in using significant indentation (like in Python)
> http://www.python.org
> to replace many parentheses in Lisp or Scheme programs.
>
> Has this been tried before? If so, what was the outcome?

dylan tried to make lisp conform to a different syntax. i am not sure
it was completely successful.

what is your aim? do you
1) want to make a new language with new syntax
or
2) find parentheses annoying?

if the latter, maybe you can keep lisp with parentheses but reduce the
annoyance. some suggestions off the top of my head

1) use a good text editor with indendation support, e.g., emacs
2) us querty keyboards have parens in an awkward place and require
pressing the shift key. remap your keyboard (say, just in emacs
for lisp modes) and swap [] for ()
3) you find parens to be visually distracting
- hack the font to make parens smaller
- get emacs font-lock highlighting to display them in a less
prominent color

--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
sysengr

Rainer Joswig

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
In article <39919CF0...@kurtz-fernhout.com>, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> But how many people are there out there who might develop in Lisp and
> Scheme who never can get past the parentheses? Obviously, Lisp has not
> caught on yet in commercial usage to the degree it deserves compared to
> say C, considering the elegance and power of the system (notable
> exceptions like http://www.franz.com/success/ excepted). Instead, more
> people are doing C, Visual Basic, and Python etc. I understand there are
> many, many reasons for a language's fate that have little to do with the
> language itself, for example Java hype or even "Worse is Better".
> http://www.jwz.org/doc/worse-is-better.html
> Still, maybe this indentational technique could help bring more people
> into doing Lisp or Scheme?

Actually Lisp was very big at Apple years ago. Still Apple
thought that Lisp syntax was not for the end user.
So we got AppleScript, NewtonScript, Sk8Script, HyperTalk, Dylan, ...
These languages were all more or less based on Lisp's
technology (objects, symbols, message passing, GC, ...).
Still I think a multitude of syntaxes in a non-integrated
way is not of benefit to the user. The development environments
were always rewritten from scratch - often with poor editor
support. But Apple always thought that the ordinary programmer
was not ready for the complexity and the paradigm shift of
Common lisp.

> Python succeeds in part because of indentation. It also succeeds in part
> because it looks a lot like C. Take both of those away, and one almost
> might as well be using Lisp, Smalltalk, Perl, or Visual Basic. All one
> would have left is a lot of nice libraries, a pure OO feel, portability,
> and a permissive license.

Personally I'm interest in large complex Lisp systems (hey, some people
call these applications) and it seems to me that Lisp *and*
the syntax scales well. I'm not willing to give this up.
Still I think there is good reason to experiment with a different
I/O system: surface syntax, reader, printer, editor support, ...
If it is good, people might use it.

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Thanks for the comments. Some elaborations below.

thi wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>

> > For example (taken from the web page): [snip]


> >
> > Which do you think you would be more likely to type in correctly the
> > first time?
> >
> > Which is easier to visually inspect and confirm correct before
> > committing to doing it (given that indentation can lie in the
> > parenthesized case)?
> >
> > Realistically, which would you rather type on the fly?
> >
> > Parentheses are fine in an editor with lots of support, but they
> > can be an extra distraction IMHO at the command line because they
> > require a higher degree of precision and thought than indentation in a
> > less forgiving environment (not to invite too many flames, please!)
>

> in all cases i would prefer the parens, since i run shells from within emacs
> (even python).

Good point about running scripts from within emacs. I hadn't though of
that.
In that case, you get all the power of emacs for composing these
expressions
and my comments on extra difficulties of interactive composition at the
command line do not apply.

> for command sequences, the value metric is encapsulatability,
> ie, easy cut and paste.

Good point.

I would think this of course assumes that one is doing lots of
interactive things where the next command to enter depends on inspecting
the result of the last thing you did.

This is opposed to say maintaining a complex piece of software, where
cut and paste is discouraged and functional reuse is encouraged
(including trying to get to the point where typical changes are made at
a single point in the code).

On a tangent, could it be that the reason for a lot of cut and paste in
Lisp is precisely because it is so hard to get all those parentheses
consistent or configured correctly for a specific operation (when typing
them in by hand)? Thus could it be a Lisp developer finds it easiest to
copy a correctly structured piece of code (containing say a defun with a
"let" definition including all the nested parentheses) whereas with
syntactically significant indentation a Lisp developer might be doing
more command completion sorts of approaches, and type the rest in by
hand? It would be ironic if this indentational approach wasn't
considered useful because it conflicted with a code creation methodology
for which it might in some cases help eliminate the need. :-)

> internal whitespace requirements such as newline and

> multiple spaces severely hampers the quick movement of text to different
> contexts.

I'd like to come to a full understanding of what exactly it is about
indentation that makes cut and paste in Lisp so awkward.

I think this would benefit from a good example.
What would a typical composition task be?
Maybe we could compare "indented" vs. "edge parentheses" versions.

Is part of the problem perhaps a historical use of tabs in Lisp coding
-- which might be expanded inconsistently in different contexts?

Or is the issue more the precise cutting to include all the leading
spaces on a line?

Could this perhaps be helped by some sort of drag and drop assist in an
editor, so it automatically makes dropped items indented properly
relative to the item they are dropped under?

> many times, a complex command is composed by testing out simpler
> commands; composition of sexps is trivial and not a spaces-counting chore.

Again, I think that indent/dedent support in the editor can help with
this.
I don't think one really ever has to count spaces. It either lines up or
it does not. You can see what is below what (and thus a sublist) just by
inspecting.

For example, in:

+
* 3 4
/ 4 5


the last expression doesn't line up.

Or, alternatively, in this bit of improperly indented indentational
Scheme:

define (foo x)
print x

it is obvious (to me) that the "print x" is not part of the define
because it is not nested.

Is this really any less obvious than the sort of converse with
parentheses:

(define (foo x))
(print x)

Actually, I'd think in this case the indentational style would be more
obvious, because without a careful reading of parentheses, one might see
these two line as a group and assume the parentheses are set up in a way
they are not (i.e. these are two independent s-expressions, despite the
indentation).

Of course, maybe because I have been using this two space indentation
convention in C and then Python for so long, it's as obvious to me as
parentheses to a seasoned Lisp developer.

Actually, I think I picked up using two spaces consistently from using
Occam (a parallel language first for Transputers) where two space
indentation is enforced.
http://www.rdg.ac.uk/~ssswills/occam.html
As I think on it, Occam is probably the first language I used which had
enforced indentational syntax (around 1986). This was long before
Python.
Any Occam users out there who also have Lisp experience care to comment
on the pros and cons of this aspect of Occam, and how they would apply
to Lisp?

I would think that rapidly seeing strucutre implied by spacing uses
visual perceptive abilities to see symmetry and consistency and grouping
most people have. I assume this, but I may be wrong. Perhaps some people
don't easily see the structure specified by the white space. Counting
parentheses may use different abilities -- perhaps ones I personally am
weaker in.

I guess I still don't see how the s-expressions are getting you any
advantage in cut&paste, since realistically you still have to indent the
whole thing consistently to make it readable and maintainable. Again, a
specific example here would help me out.

I'll concede that if you're just cutting and pasting sections of code
which have been auto-highlighted by clicking inside a parenthese and
inserting them into a stream of s-expressions with no concern for
indentation, and then pretty printing the result, this might be somewhat
faster than thinking about the indentation. But I don't normally do
something like this when I program, as I like to see the structure of
what I am working on emerge and then stay consistent as I work on it.
And I might add, with indentation you wouldn't be as likely to get a
surprise when pretty-printing or executing.

> thi

Thanks for the comments.

Tom Breton

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

>
> ======= Some advantages =======
>
> One advantage to such an approach it that it might make it easier to
> compose Lisp on devices without keyboards. An indent-line button and an
> unindent-line button would be useful in that case.

It isn't clear how that would make it easier; I suspect it would be
harder. It's also not clear why those two buttons would be better
than "(" ")" keys. In any case, how many people write code that way?

> Significant indentation might make it easier for developers who don't
> know Lisp well to understand a Lisp program's structure.

Again, that's kind of a lost cause. If they don't know Lisp, they
won't make sense of it regardless. If they know Lisp even a little
bit, they should already be past parentheses problems.

> It might also allow experiences Lisp developers to read programs faster
> because there is less high frequency "noise" in the text. Every
> additional character on the screen takes more time for the eye and mind
> to process. In practice, experienced Lisp developers will rely on the
> indentation anyway -- as editors are used to count parentheses.

I doubt it would let me or any other experienced Lisp programmer read
programs faster.

> Such code will be faster to create. There is less typing, and no worry
> about unbalanced parentheses. Indentation might be incorrect, but then
> the mistake in the structure would usually be obvious on inspection.

I doubt it. I suspect you need a different editor, since all these
things are non-issues when using emacs.

> Also, with significant indentation, indentation can not as often be
> misleading as it can be with parentheses.

Indentation in Lisp can be trivially made to match the parentheses in
a good editor.

> ======= Some disadvantages =======
>
> I'm sure people will point out lots. Send 'em on!

> The major one is that this is non-standard and not available.

> Also, it may confuse some people (novices?) as much as it clarifies
> things to others.

If it does clarify structure.

Other problems:

It would not survive accidental reformatting. (A problem Lisp only
has with strings' newlines)

It needs additional rules when a line is too long (can't all fit) or
too short (ie, you want to fit multiple sexps on one line).

It requires more smarts from editors and other tools. And it's not a
one-time thing. I've seen plenty of Elisp packages that each
independently tried to parse some piece of some Lisp. They'd all need
to be smarter. Some wouldn't exist or would be buggy.

Printing data readably would be tricky. For embedded expressions, you
must figure out the proper level of indentation to start at. And it
would be disastrous when you missed, because there'd be no parentheses
to indicate how the expression is really scoped.

More nebulously, but very important, it "tempts" the language to not
represent code as data. That's almost the core of Lisp.

So all in all, I don't think it would be an improvement. But it's
good that you're thinking about it.

--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.

Tom Breton

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

>
> Many people say of Python, "well if indentation is significant, how do I
> copy and paste code?"
>
> I think the answer is that when you copy and paste and code -- be it
> Lisp or C or whatever, you still need to make the indentation work out
> to make the code readable.

That wasn't really the issue. In indentation code, selecting the
proper sexp is ambiguous when nested sexps begin in the same place.

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Johan -

Thanks for the excellent suggestions. Some comments below.

Johan Kullstam wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>

> > I'm interested in using significant indentation (like in Python)
> > http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
>

> dylan tried to make lisp conform to a different syntax. i am not sure
> it was completely successful.

Again, I have no interest in changing the syntax to be more Pascal or
Algol like (such as Dylan attempts). I'm just addressing "edge"
parentheses here.



> what is your aim? do you
> 1) want to make a new language with new syntax
> or
> 2) find parentheses annoying?

Definitely not 1. I want everything in Lisp and Scheme to work exactly
the way it is, only with somewhat less effort.

So, sort of, 2. The exception is that I don't find parentheses in the
middle of an expression annoying. I use them all the time in other
languages (Smalltalk, C, Python). It is only the parentheses at the
"edges" that I find distracting.

For example, in the Scheme function below:

[defun (foo x)
[print x]]

it is the parentheses marked as brackets I find distracting and
redundant.
I call these "edge" parentheses because they are on the "edges" of
indented lines. They are syntactically redundant if indentation is
syntactically significant.

Thus, I would prefer:

defun (foo x)
print x

It seems following the five rules for eliminating edge parentheses I
outlined, this expression and others like it could be consistently
converted to a legal Scheme expression.

> if the latter, maybe you can keep lisp with parentheses but reduce the
> annoyance. some suggestions off the top of my head
>
> 1) use a good text editor with indendation support, e.g., emacs

Good point. I currently use DrScheme, which has quite good support for
parentheses. I have no complaints as far as what it does.

> 2) us querty keyboards have parens in an awkward place and require
> pressing the shift key. remap your keyboard (say, just in emacs
> for lisp modes) and swap [] for ()

Very good point. My parentheses are over the "9" and "0" keys, and so
require a shift key.

Ah yes, now I'm remembering the silky feel of the Symbolics 3600
keyboard with its well places parentheses... And the glorious command
completion key... And the purr of the fan... And the 4MB of memory (1MB
cells)... and the calls to technical support for trying to get free
hardware fixes for a bad memory board... (oops, some things maybe we
don't want to remember) :-)

> 3) you find parens to be visually distracting
> - hack the font to make parens smaller
> - get emacs font-lock highlighting to display them in a less
> prominent color

Good suggestion. However, what I want is the "edge" parentheses to
disappear, not the core parentheses. Thus I can't just change the font.
I need something smart enough to know what are edge parentheses (when
the structure is properly indented), and which are not. Maybe emacs can
hide edge parentheses?

> J o h a n K u l l s t a m
> [kull...@ne.mediaone.net]
> sysengr

Thanks for the great suggestions!

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

David Bakhash

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Peter Norvig <pe...@norvig.com> writes:

> Why does Python/Java/C++ have an
> advantage? Because they typographically distinguish useful operations:
> assignment in Python/Java (and confusingly, copying in C++); indexing;
> and class slots. And also because classes are namespaces in Python/C++,
> but not in Lisp (so I can use X instead of csp-state-x). Lisp
> multimethods are the preferred solution for complex applications, but
> Python/Java/C++ classes do make the easy cases easier.

This is really interesting. Back in '96 is when I first started using
Windows (it was Windows 95, of course). I was coming from a Unix
background, and really despised MS Windows, but really couldn't
elaborate on why. It was something much deeper than anything overtly
apparent to me. Then I heard the guy in the cubicle next to mine
bitching about his windows box. He was also a non-hacker EE type, and
what he said was:

"I hate this goddamn OS. They try to make everything so &%*#ing
easy, but as soon as I try to do something that they didn't
anticipate, it's a nightmare. I want my Unix box back."

His point was exactly that the simple things in Unix seem hard, but
once you've got them down, the hard things are very similar and follow
logically from the simple things. There's no dichotomy there, whereas
for windows he felt that there was, and I finally realized that that's
what was plaguing me too.

It's the same deal here. You have a universal method for mutation
which follows logically from accessing. You claim that the simple
things in Java and C++ are simpler? Do you find writing dozens of
set_* and get_* methods to be simpler than the :accessor slot option
of defclass? I surely don't. Throw in that lots of [Java] code out
there doesn't conform to the set/get naming conventions and I'd argue
that it's anything but simple and straightforward.

dave


Marie-Noëlle Baechler

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to

> - one of the points of the syntax of lisp is that it makes it very
> easy to parse; since devices without keyboards probably also are
> short on other ressources, increasing the complexity in central
> components may be the wrong way to go.

In addition, there has been myriads of Algol-like syntax implemented
over a Lisp System. But none of these extensions did ever become
popular. Even John MacCarthy mentions that S-Expressions were
originally only intended for data and that program had to be written
in a more algol-like syntax called M-expressions(*). But S-expressions
were used from the beginning and they are still there.

Lips syntax has other advantages beyond easy of parsing. It makes
programs similar to data and reciprocally. With good macros, this
gives a tremendous expressive power and I am not sure that it can
be achieved with a more conventional system. Finally, Lisp makes
it extremely easy to develop interpreters over an existing
implementations. Even in the seventies, when he was testing the
Actor model, Harold Abelson was developping and testing up to 10
interpreters a week! (**) Once again, I doubt that such an expressive
power can be achieved with a more conventional language.

(*) John McCarthy
History of Lisp
Stanford university, 12 February 1979

(**) Guy Steel Jr. & Richard P. Gabriel
The Evolution of lisp
ACM Sigplan Notices 28 3. (231-270), April 1993

Both are available on-line

Regards

Marie-Noëlle Baechler

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Peter -

Thanks for the reply.

I hadn't thought of the issue of writing on paper. Thanks for bringing
that up. Also, good point on communicating with the non lisp community.
Perhaps these guidelines might help in publishing Lisp code in non-Lisp
situations?

I think what I am hearing again though is that if this indentational
syntax concept were to have any hope of taking off in the Lisp community
in general, it really needs good emacs support. And it needs to be
transparent support, so people aren't committed to this approach. This
is all along the lines David J. Cooper suggested. However, I'm not
currently using emacs.

You raise an interesting point about which elements of syntax are most
useful.
However, I don't want to spawn another thread on that. I'm content to
live within the Lisp/Scheme syntax. I'm just trying to cut back on some
perceived redundancy. However I am interested in numerical simulation,
so I'd certainly like something more elegant for simple array indexing.
But, it's a tradeoff.

By the way, does:

setf
aref (csp-state-x s) i
val

seem any clearer?

It's certainly still not as simple as the C one liner for the simple
case.

I guess one other solution if this is common is defining a function,
called as:

set-object-array-field! s i val

or more conventionally:

(set-object-array-field! s i val)

Thanks again for the comments.

-Paul Fernhout


Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Peter Norvig wrote:
>
> I have no objection to the less-parentheses style. I'd say I wouldn't
> use it when editing in emacs, unless s-expression commands support
> indentation as thoroughly as they do parens. But when I write code on
> paper, I often use a style like this to save time. I think using this
> is like using an infix-syntax parser for mathematical expressions: if
> used in moderation it can be helpful, especially in communicating with a
> community that aren't used to the parens.
>
> Actually, there are other aspects of Lisp syntax that I find more
> annoying than the parens. Compare
>
> s.X[i] = val
> to
> (setf (aref (csp-state-x s) i) val)
>
> The later is what I ended up coding in a constraint satisfaction solver
> I was recently working on. The annoyance is that the former (legal
> Python, Java or C++) is close enough to what is used in the theoretical
> literature that I can understand it in one glance, while the Lisp code

> takes two glances to understand. Why does Python/Java/C++ have an


> advantage? Because they typographically distinguish useful operations:
> assignment in Python/Java (and confusingly, copying in C++); indexing;
> and class slots. And also because classes are namespaces in Python/C++,
> but not in Lisp (so I can use X instead of csp-state-x). Lisp
> multimethods are the preferred solution for complex applications, but
> Python/Java/C++ classes do make the easy cases easier.
>

> -Peter Norvig
>
> Paul Fernhout wrote:
> >

> > I'm interested in using significant indentation (like in Python)
> > http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
> >

Erik Naggum

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
* Paul Fernhout <pdfer...@kurtz-fernhout.com>

| Has this been tried before? If so, what was the outcome?

You have broken the property of Lisp that code can be read as data,
and code printed as text to be read back in. You don't seem to be
aware of the fact that Lisp code is readable by the Lisp system, but
instead treat it as if Lisp were a language with a syntax it could
not itself simply "read", like Python. And like Scheme. This is
where Scheme departed most clearly from the Lisp camp, years ago.
Scheme code is made up of characters and tokens. Lisp code is made
up of lists and elements. The difference is _monumental_ in scope.

| One advantage to such an approach it that it might make it easier to
| compose Lisp on devices without keyboards. An indent-line button and an
| unindent-line button would be useful in that case.

I think "down" and "up" are equally useful/likely "buttons". I use
Emacs with these operations all the time, in fact. Very seldom do I
type invididual parentheses.

| Significant indentation might make it easier for developers who don't
| know Lisp well to understand a Lisp program's structure.

Nonsense.

| Every additional character on the screen takes more time for the eye
| and mind to process.

This silly metric runs counter to much cognitive science.

forinstanceithaslongbeenknownthataddingsuperfluouscharacterslike
whitespaceandpunctuationmarksimprovereadabilitysignificantly

| In practice, experienced Lisp developers will rely on the
| indentation anyway -- as editors are used to count parentheses.

If you rely on something, would you be happy if someone removed that
which what you rely on rests? I would be unhappy, as that which I
rely on is now in danger of collapsing, as surely your syntax would
as soon as the next clever idea comes along.

| Such code will be faster to create.

Drop the marketing and your credibility will improve.

| There is less typing, and no worry about unbalanced parentheses.

Again, drop the marketing. How do you determine the indentation?
That alone looks like _more_ typing to me.

| Also, with significant indentation, indentation can not as often be
| misleading as it can be with parentheses.

Your credibility is suffering with this line, too.

| ======= Some disadvantages =======
|
| I'm sure people will point out lots. Send 'em on!

This idiocy hints that you're ill-prepared for your own proposal.

| The major one is that this is non-standard and not available.

The major one is that you're breaking a very significant property of
the language, and you're not even aware of it.

Oh, right, you're thinking in Scheme, which _is_ a language that
breaks this important property of Lisp, and has a character-level
syntax, like Algol.

| ======= More issues to consider =======
|
| One issue is that parenthesization is redundant when you use
| indentation.

Predictable redundancy is what keeps people sane.

| Another way to look at it is, in practice, a Lisp coder is already
| doing these rules implicitly as part of the conventional indentation
| process.

You seem to think that Lisp "coders" indent their code by hand.
They don't.

| So this approach just loses some of the extra burden of worrying
| about quite a few of the parentheses, which are syntactically
| redundant if proper indentation is in place.

Lisp programmers (I take exception to "coders") don't count parens,
but use automatic re-indentation to check that they got it right.
When you remove one of these "redundant" parts, you remove the tool
that makes indentation sufficient _after_the_fact_.

| Yes, people put down Lisp saying it stands for "Lots of Infernal Stupid
| Parentheses". Rather than be defensive, here is an approach that might
| do something about what much of the world perceives as a difficulty in
| reading and writing Lisp code.

Rather than be defensive, be smart and ignore the infernal idiots.

| Making indentation significant works for Python.
| Why not make it work for Lisp too?

Because Lisp doesn't have _syntax_ the way Python has.

You have redesign the Lisp reader and printer to be able to perform
this incredibly silly stunt, and you aren't even _aware_ of that,
either. Go do your homework, and be creative when you know what
your "good ideas" are affecting.

| Learning from Python's mistakes (tabs are allowed and they are
| expanded inconsistently on various systems) I would suggest always
| requiring two spaces per level of indentation.

But you don't even understand how the current indentation is used!

| I'm not going to say this wouldn't take some getting used to for
| experienced Lisp hackers.

Hey, not to worry, most of the experienced Lisp hackers around have
been to one more universities, and anyone who has been to any
university has seen the freshman who knows how to run the whole
place better than everybody who has ever actually run a university.
"Clever" novices is old hat to us old farts.

| ======= Psychobabble justification =======
|
| Some level of complexity in any task exists. It can often be pushed
| around however, or refactored into different chunks. Sometimes, a
| refactoring of compelxity will fit more naturally onto what most
| human minds do well.

Pardon me, but most human minds don't to programming well at all.
The few that do, tend to be very diverse. Much more so than those
that do, e.g., plumbing or carpentry well. Programming is like an
art in many ways because of this diversity of its performers. Some
like Lisp because Lisp is Lisp. You don't. That may mean your mind
doesn't work the way that other Lisp programmers' minds work. I
know my mind doesn't work the way Perl programmers' minds work, and
while I think Perl is the suckiest language ever, I don't handle the
way purely functional languages work very well, either, and while I
could be "proud" of being "above" Perl, I can't be proud of being
"below" functional languages, as those are somehow "better". I have
come to recognize that I understood SGML very well because my mind
works very well with hierarchical, nested structures and languages
that describe them. If your mind doesn't work that way, come to
peace with yourself and do something else: I have "decided" not to
work with Perl and C++ and such things, in the sense that I know
that I couldn't be so good at it that it would be rewarding in
itself to work with these languages. It _is_ rewarding in itself to
work with Lisp. For me.

| This is because the human mind is quirky that way.

Some day, I hope you will recognize that "the human mind" is one of
the stupidest things you can say. We're not 6 billion people who
differ only in fingerprints, you know. We're surprisingly different
mentally, too. _Diversity_ is the name of the game. Accepting it
is not very different from getting used to people having different
color skins. After you accept it, you automatically accept that
people who are like-minded in any of whole range of different ways
will congregate. Lisp programmers congregate for such reasons, and
they don't _need_ your misplaced, misunderstood syntax.

| For example, it is easier to remember a seven digit phone number
| than a fifteen digit number.

But it's easier to remember an eight-digit phone number with a large
degree of systematic relation to something you know well, such as
geography, than to remember a six-digit phone number that appears to
be randomly allocated. (Empirical results from the expansion of the
Norwegian phone number system, which went from 5- and 6-digit local
numbers with 1- or 2-digit area codes to a uniform 8-digit system.)
It's also easier to remember a ten-digit phone number than to take
short-cuts and remember only the seven last digits and _hope_ you're
in the right area. (Empirical evidence from area code splits in the
U.S., repeated many times, and well documented in telephone circles.)

| Together these let you run about seven digits (each digit itself a
| chunk) through your mind while you dial a seven digit telephone
| number.

Remembering phone numbers are similar to musical memory. We don't
remember individual digits, but somehow find an internal "rhythm" to
them. Much recent research into memory has concentrated on the
"rhythm" theories, both in spelling and remembering numbers, music,
exact quotes, poems, stories, names, etc. People who are unable,
for a variety of reasons, to map events to rhythms, lose out. This
has absolutely nothing to do with the theory you ascribe to numbers.

| ======= Conclusion =======


|
| Lisp uses structure to replace much of what other languages do with
| syntax.

This is simply WRONG. Do your homework, and come back later.

| Have I missed something technical that makes indentation unworkable?
| Obvious it faces an uphill battle for social acceptance and
| implementation into specific Lisp and Scheme systems.

You will meet much less resistance in the Scheme camps, as they have
already dispensed with the notion that code should be readable as
data. Hell, they don't even believe in compile-time manipulation of
the code, so there's no _need_ to be able to read it as data.

| If people think this idea is interesting and has no obvious technical
| flaws, I may proceed to try and see if I can get this to work in
| DrScheme.

That sounds like a good idea. However, I suggest you keep Common
Lisp out of your experiment.

#:Erik
--
If this is not what you expected, please alter your expectations.

Erik Naggum

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
* Michael Hudson <mw...@cam.ac.uk>

| From an experienced Pythoneer: don't knock what you don't know.

Let's keep this sage advice in mind for just a few seconds.

| Have you actually found it's dependence on whitespace a problem
| (other than the "ooh this is different therefore it's bad" response)?

Why are you so unfathomably stupid as to think it's OK for _you_ to
knock what you don't know right after you've told others not to?
How the hell did you come up with the _chutzpah_ required to write
such an obvious attack based on your own ignorance of how others
reacted to Python's significant whitespace?

Some people just prove that human procreation is too cheap.

The reason _I_ don't like Python's significant whitespace is that I
don't want to keep doing indentation by hand. I'm sure it looks
good after the fact, but before the fact, which I automatically
think about as I keep writing stuff and make my living writing, it
involves a lot of _unnecessary_ work. But hey, if you're used to
C++ and you think Perl's way too ugly, but still has merits, Python
probably wins. If you're used to Common Lisp, I fail to see how
Python could win, except over C++ and Perl and possibly Java.

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Rainer-

Thanks for the comments. Some more below.

Rainer Joswig wrote:
>
> In article <39919CF0...@kurtz-fernhout.com>, Paul Fernhout
> <pdfer...@kurtz-fernhout.com> wrote:
>

> > But how many people are there out there who might develop in Lisp and
> > Scheme who never can get past the parentheses? Obviously, Lisp has not
> > caught on yet in commercial usage to the degree it deserves compared to
> > say C, considering the elegance and power of the system (notable
> > exceptions like http://www.franz.com/success/ excepted). Instead, more
> > people are doing C, Visual Basic, and Python etc. I understand there are
> > many, many reasons for a language's fate that have little to do with the
> > language itself, for example Java hype or even "Worse is Better".
> > http://www.jwz.org/doc/worse-is-better.html
> > Still, maybe this indentational technique could help bring more people
> > into doing Lisp or Scheme?
>

> Actually Lisp was very big at Apple years ago. Still Apple
> thought that Lisp syntax was not for the end user.
> So we got AppleScript, NewtonScript, Sk8Script, HyperTalk, Dylan, ...
> These languages were all more or less based on Lisp's
> technology (objects, symbols, message passing, GC, ...).
> Still I think a multitude of syntaxes in a non-integrated
> way is not of benefit to the user. The development environments
> were always rewritten from scratch - often with poor editor
> support. But Apple always thought that the ordinary programmer
> was not ready for the complexity and the paradigm shift of
> Common lisp.

Very interesting comment. I have used NewtonScript and HyperTalk and
looked at those others. Maybe in part Apple was just hung up on Pascal
syntax (the original Mac system programming language)?

I agree that the proliferation of (abandoned) syntaxes is not good.

Actually, I said something very similar about development environments
to someone in research at Apple several years ago. That is, novice
developers are often the ones most in need of things like version
control or advanced editing or debugging features (or even just well
tested stability!), and yet these are usually the last things to be
added (if ever) to new experimental languages for novices. Experienced
developers can more easily deal with quirks. The environment and its
stability and comprehensiveness is often just as if not more important
than the language to a developer. It's too bad, because when you think
of what all those resources could do if just applied to making a
cross-platform Lisp or Scheme with great libraries.

DrScheme (for example) is a very pleasant exception to that trend.

Hopefully, this indentational approach is a minor enough change (since
it can be handled by a smart editor) that it would not follow that road
that Dylan etc. went down. It's really mostly just the same old Lisp and
Scheme with the removal of some redundant parentheses (redundant
syntactically, when given syntactically significant indentation).

> > Python succeeds in part because of indentation. It also succeeds in part
> > because it looks a lot like C. Take both of those away, and one almost
> > might as well be using Lisp, Smalltalk, Perl, or Visual Basic. All one
> > would have left is a lot of nice libraries, a pure OO feel, portability,
> > and a permissive license.
>

> Personally I'm interest in large complex Lisp systems (hey, some people
> call these applications) and it seems to me that Lisp *and*
> the syntax scales well. I'm not willing to give this up.

OK. Hopefully one could use indentational syntax and it would still
scale.

There must be some better way I can explain this approach without it
coming across that I am proposing a major syntactical change. I thought
this approach had merit precisely because it was such a slight change.

> Still I think there is good reason to experiment with a different
> I/O system: surface syntax, reader, printer, editor support, ...
> If it is good, people might use it.

Build it and they will come! :-)

I woudn't think it would be that hard.

Mostly I started this thread (rather than actually write the thing)
because I expected someone would just point out that precidsely what I
suggested had been tried before, and maybe given me a URL of the code.
I'm actually surprised no one has said this.

I had tried to look at the archives of newsgroups and web sites myself,
but I couldn't figure out a precise enough way to search for a
discussion of exactly this topic, so I thought I'd see what people had
to say.

> Rainer Joswig, Hamburg, Germany
> Email: mailto:jos...@corporate-world.lisp.de

Thanks again for your comments.

Craig Brozefsky

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> Good suggestion. However, what I want is the "edge" parentheses to
> disappear, not the core parentheses. Thus I can't just change the font.
> I need something smart enough to know what are edge parentheses (when
> the structure is properly indented), and which are not. Maybe emacs can
> hide edge parentheses?

I suggest you put this in your interface, not in the code you intend
to share with the rest of the lisp community.

An extension to emacs lisp mode with identified those "edge"
parentheses and used them to enforce a significant indentation
convention would allow you to read the existing lisp code as you like
to see it, but without requiring the rest of the community to convert
their code to the new syntax. If emacs would then produce normal lisp
code from your "indentation significant lisp buffer" you could run it
in any lisp system, and share it with other lispers, without them
having to learn the rules for your new indentation system.

--
Craig Brozefsky <cr...@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---

Espen Vestre

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Peter Norvig <pe...@norvig.com> writes:

> and class slots. And also because classes are namespaces in Python/C++,
> but not in Lisp (so I can use X instead of csp-state-x).

...but quite often the defstruct-like idea of using the class name in
the accessor function is not a very good one, since it may just be
disturbing when used with subclasses with quite different names. In
most cases, I rather tend to use x-of for the name of the accessor of
x, which, if you tend to use the slotname x for things that are
related, gives you the additional benefit of the accessor function
having methods for several classes that aren't necessarily sharing the
slot name through a common superclass.

(I'm sure someone will object to this naming convention, but I've only
experienced positive effects so far)

--
(espen)

Craig Brozefsky

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Erik Naggum <er...@naggum.net> writes:

> I think "down" and "up" are equally useful/likely "buttons". I use
> Emacs with these operations all the time, in fact. Very seldom do I
> type invididual parentheses.

How do you avoid that? I am using ILISP and I find that I often type
individual parenthesis. I can understand how one an avoid closing
parens, but not opening parens.

Since I use the []s for an embedded SQL syntax in the code I'm working
on now, I can't use ILISP's super-paren feature to automatically close
expressions. Instead I ue the emacs paren-matching feature. I type
parens, while watching the mini-buffer at the edge of my vision, and
when it I see it match the top-level of my expression I stop. One
nice feature of this tactic is that I can see my expressions closing
over one another.

> Oh, right, you're thinking in Scheme, which _is_ a language that
> breaks this important property of Lisp, and has a character-level
> syntax, like Algol.

I understand this difference, but I'm unable to see the repurcussions
it has.

In R5RS any Expression will also parse as Datum (what read
understands). So (if 1 2 3) would be returned from read as a list
whose first element is a symbol "if" and then the numbers 1 2 and 3.
The syntax is defined at the character level. Scheme does not have a
way of extending the reader, but I don't see how the language
precludes that.

It's very possible that I'm just not seeing something that I should
be.

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Rainer-

Thanks for the further comments.

You raise some excellent point. Comments below.

Rainer Joswig wrote:
>
> In article <3991881D...@kurtz-fernhout.com>, Paul Fernhout


> <pdfer...@kurtz-fernhout.com> wrote:
>
> > If I may add something, when you wrote:
> >
> > (defun send-a-mail (from to subject)
> > (let ((body (get-body 'introduction)))
> >
> > I had to actually count the parentheses to see if this was a complete
> > statement, to see if you were referring to inserting something within
> > the current structure or at the end of it. It wasn't immediately obvious
> > to me whether this fragment was a valid Lisp program or not. It is not.
>

> I'm moving around in a Lisp buffer by Lisp expressions.
> I can easily "feel" whether this is valid or not, because
> I'm not only looking on the code, but I **feel** the code under
> the cursor. The belonging parentheses blinks if I place my cursor
> in front of the defun. If there is nothing blinking at the end
> I have a problem. If I move the cursor over the expression
> (c-m-forward or c-m-f) I see where it ends. Another keypress
> and the whole thing reindents. Another keypress: undo.
> I don't think about that - it's just learned and works
> intuitively.

OK. I can see the Lisp editing system works well for you as is. I lost
such a fluid feeling of working with any specific system as I bounced
around through so many different development environments and languages.
It would be nice to have that feeling back again. I can see the value to
the current Lisp approach you outline.

But, in the context of this thread, the relevant question is then,
technically speaking, can similar functionality (when meaningful) be
provided when editing an indentational syntax? I would think so, because
basically you are moving around a tree structure, which the
indentational syntax still preserves.

Another question is, is such functionality still important given
syntactically significant indentational syntax? That is, maybe with
significant indentation, moving around smoothly across expressions would
not be so important as expression boundaries might be more apparent.

> > If you had written (in indentational syntax, removing edge parentheses):
> >
> > defun send-a-mail (from to subject)
> > let
> > ...
> > body (get-body 'introduction)
> >
> > there would not be any question about validity. This has to be a valid
> > expression. At almost every point, an indentational syntax specification
> > is valid.
>

> Not really. In Lisp you can write multiple level macros and
> Lisp expressions that have complex indentation descriptions.

OK. You may have a strong technical point against the approach here if
this holds. I'm relearning Lisp (actually Scheme) and there may be
something I am missing here with macros.

But ultimately, unless you are messing with the parser, you are still
parsing lists, correct, even if you apply macros to the result? And the
indentational syntax should still (if the five rules are correct and
complete) produce the same lists as the fully parenthesized notation. So
given that, are macros really a problem? Can you give me an example of
one that would not work with the indentational syntax?

Is this something that would only apply to Common Lisp, or would Scheme
be affected by it as well?

> How do I now that
>
> foo bar
> baz
>
> is valid?

It is valid. The equivalent Lisp is:

(foo bar baz)

The first line starts a list. The second line just makes "baz" a sublist
of the first list. But by Rule 3, the item by itself is just taken as
itself (rather than as a list).

> How do I know that baz needs another item behind it?

That really depends on the meaning of baz. Is it a function call? Is it
a variable? Is it a symbol? As far as I can see right now, there is
nothing about indentational syntax that makes this problem any different
then if you were coding in fully parenthesized Lisp.

> How do I now that it needs another line to be complete?

It doesn't, unless you want to extend the structure. Again, this is the
same problem with any Lisp coding -- the indentational syntax doesn't
change the problem of Lisp program or structure composition.

Or perhaps you are referring to my comment in another post about
interactive command lines requiring a final blank line or other command
start indicator? In the interactive case, you would need a blank line
or command indicator to start evaluation.

If you are talking about the parser parsing a file, then when the file
containing this expression is parsed, the end of this list structure is
signaled by either the fact that either EOF is encountered, or another
expression is encountered with less indentation.

> How do you see it when you have an indentation depths
> of 120 characters?

Well, this is a good point. You would have to scroll.

But really, in the Smalltalk world which I am more familiar with, people
would say an expression with 60 levels of indentation (/ 120 2) should
probably be refactored into subexpressions. I would think this is true
in the Lisp world as well.

What do you propose as the alternative? Again, even with parentheses,
people rely on Lisp being consistently indented for readability.

If you collapse the indentation for convenience, even with parentheses,
you are practically begging some maintenance programmer to misunderstand
your code.

I might argue it is actually an advantage of the indentational approach
to encourage people to factor their functions if they get too complex.

I guess if it is some sort of database strucutre you are defining, you
might make a stronger arguement for having the whole thing in one place.
But I still think the difficulty reading and understanding such a
complex tree of nested lists 60+ deep (especially if it was not properly
indented) would be asking for trouble.

Can you point me to a good example of such a function or data structure
that has to be all in one expression?

> How do add additional ways of code formatting?

There is some variation allowed in the choice of which elements of a
list to make into sublists, or whether to keep a short list in line or
make it a sublist on a new line, or (discouraged) whether to split a
fully parenthesized list across multiple lines.

Would the need for alternative formatting really be a big issue under an
indentational syntax?

What specific code formatting are you concerned about?
Can you given an example?

> On a Symbolics I often try different ways of code formatting
> (just press c-Tab multiple times to experiment with
> different indentations on the current line).

OK. But is this really essential? What situations make this important?

And if it is important, is it still important in an unambiguously
indented system, and if so, is the benefit for it greater than possible
benefits from not having to type or view "edge" parentheses?

> > In the case you describe, the editor is smart enough to look up the tree
> > of the partial definition and grab the relevant variables for choices in
> > helping you complete the expresion. I don't see any reason an
> > indentational syntax would prevent a smart editor from doing that. It
> > might even be easier to code this lookup in some ways, since it might be
> > easier to map a specific line of code into a leaf in a tree branch of
> > nested scopes, with less code for dealing with incomplete or unclosed
> > expressions.
>

> Actually I don't like the system telling me whether I have to write:
>
> (+ a b)
> (+ a
> b)
>
> (+
> a
> b)
>
> (+
> a b)

Actually, in Lisp, the system may not tell you how to indent, but
ultimately your own need for maintainability (or that of your
colleagues) does exert pressure towards standard indenting. So I would
argue, in practice, almost all of any Lisp developers code probably is
consistently indented anyway.

> Then Common Lisp has keyword args, optional args , ...

Well, these may pose more of a problem. However, aren't they too just
list elements? And so they would fit into this system. The only major
difference I can see is that you can no longer write the keyword and
value on a line by itself, because the indentational approach would take
this as a list of two elements. So you would need to write things more
like:

myfunction keyword1 value1
keyword2
value2
keyword3
value3

instead of having say "keyword2 value2" on one line.

Since I am more interested in working in Scheme at this point, the
keyword issue is not as important to me (since I don't think Scheme
supports keywords).

Still, I think they are doable, but admittedly there is an awkwardness
perhaps.

As for optional args, again, they are just list elements. So you can
either put them in or not.

Maybe it would be clearest if I had proposed a "indentational
preprocessor" for Lisp and Scheme. That is, it lets you write properly
indented code without the edge parentheses and then it puts them in.
Then it might be clearer that I am not in any way messing with the
notion of defining nested lists (hopefully, if the rules are correct).
I'm hopefully just changing something minor about the syntax involving
indentation and displaying edge parentheses, in the interest of what I
as an unseasoned Lisp user consider clarity.



> > features. But the technical question then is, could one have those
> > features and indentational syntax too?
>

> You could have a lot of these. Hey, there was once a Haskell
> implementation written in Common Lisp. Haskell has also
> an indentation based syntax. AXIOM (a computer algebra system
> written in Common Lisp) also has an indentation based
> syntax (IIRC). So there might be some reason to experiment
> with it.

Thanks for the pointers. I'll need to look at them.

> But then why not go further? For MCL there are quite a few
> graphical programming systems. In "Open Music" you draw
> CL programs in a 2d plane. In "Boxer" code is a bunch
> of nested 2d boxes.

If I am changing the syntax, why stop there?

Actually, I was hoping this change was so minor that it could be readily
implemented and adopted. All the other systems you mention are much more
radical departures from Lisp syntax.

I propose just changing part of the surface structure of the language,
and in a way that even a smart editor could hide from the internals of
the system.
Still, I probably won't know for sure how valuable it is until I try it
-- and of course I am probably biased, or surely will be by the time I
have put a lot of work into implementing something.

> Rainer Joswig, Hamburg, Germany
> Email: mailto:jos...@corporate-world.lisp.de

Thanks again. I've enjoyed all your comments.

Fernando D. Mato Mira

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
David Bakhash wrote:

> As an aside, I recently talked to a guy that's been programming CL for
> about 20 years, and also C, Java, and Perl and is a professional
> developer for a nearby company, and told me that he gave Python his
> best effort and had to abandon it, mostly because of indentation
> frustration. It's not unheard of for programmers to lose interest in
> Python based on its indentation practice.

Never used Python. What's the problem with indentation? With Occam
it was just cool, compared to using BEGIN..ENDs

But this is a FBI (Frequent Bad Idea) for Lisp
[except for a mode for interactive shells where the outermost level can
be dropped, trading off the ability to just type a symbol to get its
value
(top-level commands work the same, provided an appropriate function
definition)]

--
Fernando D. Mato Mira Phone : +41 (78) 778 FDMM
E-mail : matomira AT acm DOT org

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Tom-

Thanks for the comment. More comments below.

Tom Breton wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>
> >

> > Many people say of Python, "well if indentation is significant, how do I
> > copy and paste code?"
> >
> > I think the answer is that when you copy and paste and code -- be it
> > Lisp or C or whatever, you still need to make the indentation work out
> > to make the code readable.
>
> That wasn't really the issue. In indentation code, selecting the
> proper sexp is ambiguous when nested sexps begin in the same place.

I can see how this might be an issue in theory. I'm having trouble with
seeing a specific example of this as a problem in practice. Maybe I
don't understand the situation you refer to. If you can supply an
example, I'd be happy to think about it.

A simple example I can see that works might be:

define (foo bar)
let ((x 10) (y 20))
bar * x * y

If I want to make a similar function called "poo", but taking x and y as
parameters, I just type:

define (poo bar x y)

And then I cut and paste the entire line " bar * x * y" to get:

define (poo bar x y)
bar * x * y

and then I dedent the last line to produce the correct:

define (poo bar x y)
bar * x * y

I guess I don't see what is so complicated.

Using indentational syntax ensures all valid S-expressions will simply
be a line and all indented lines below it (up to the first line with
equal or lesser indentation). As long as you select them all (perhaps
with editor support by double clicking at the beginning of a line?)
everything should be fine and the expression should be complete.

For example, in the following:

A
B
C
D

equivalent to:

(A B (C D))

the four obvious valid S-expressions are:

1:
A
B
C
D

2:
B

3:
C
D

4:
D

I find all easily identifiable based on indentation.

[I guess the two non-obvious empty lists in there are valid
S-expressions too.]

It is true one can mess up indentation if one is not careful. But I
think the same is true (in a different way) for messing up parentheses.
It is true that it may be harder to mess up the parentheses given the
typical types of editing mistakes people might make (especially if they
are used to languages without syntactically significant indentation),
and that the resulting errors of messing up parentheses might typically
be more obvious. This is probably a tradeoff of this approach.

> Tom Breton, http://world.std.com/~tob

Thanks again for the comments.

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Craig -

Thanks for the reply. Good suggestion. What you outline does sound like
the sensible approach if this technique is to be used at all.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Craig Brozefsky wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>

> > Good suggestion. However, what I want is the "edge" parentheses to
> > disappear, not the core parentheses. Thus I can't just change the font.
> > I need something smart enough to know what are edge parentheses (when
> > the structure is properly indented), and which are not. Maybe emacs can
> > hide edge parentheses?
>
> I suggest you put this in your interface, not in the code you intend
> to share with the rest of the lisp community.
>
> An extension to emacs lisp mode with identified those "edge"
> parentheses and used them to enforce a significant indentation
> convention would allow you to read the existing lisp code as you like
> to see it, but without requiring the rest of the community to convert
> their code to the new syntax. If emacs would then produce normal lisp
> code from your "indentation significant lisp buffer" you could run it
> in any lisp system, and share it with other lispers, without them
> having to learn the rules for your new indentation system.
>

Hartmann Schaffer

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
In article <31748430...@naggum.net>,
Erik Naggum <er...@naggum.net> writes:
> ...

> The reason _I_ don't like Python's significant whitespace is that I
> don't want to keep doing indentation by hand. I'm sure it looks

maybe we have different ideas what indentation by hand means, but imo
with emac's python mode you don't have to

> ...

--

Hartmann Schaffer


Hartmann Schaffer

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
In article <m3wvhqq...@atrus.jesus.cam.ac.uk>,
Michael Hudson <mw...@cam.ac.uk> writes:
> David Bakhash <ca...@alum.mit.edu> writes:

>
>> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>>
>> > I'm interested in using significant indentation (like in Python)
>> > http://www.python.org
>> > to replace many parentheses in Lisp or Scheme programs.
>> >
>> > Has this been tried before? If so, what was the outcome?
>>
>> I don't know how to respond to this post, and please, don't take
>> offense at anything I say.
>>
>> The idea of using whitespace to alter the meaning of code is absurd.
>> I don't know how python continues to exist in its current state.

>
> From an experienced Pythoneer: don't knock what you don't know.
> Please. Have actually programmed in Python? Have you actually found

> it's dependence on whitespace a problem (other than the "ooh this is
> different therefore it's bad" response)? With a half-decent editor
> you really shouldn't have any difficulties (hmm, now where have I
> heard that defense before...?).

i have no problem with the puthon syntax, provided you use the right
[x]editor. emac's is great, so is the python ide (if you have to use
windows). i ran into one problem, though: at one point i was working
together with somebody who was too stupid to use either of them, and
he did the indenting manually. incorporating his code was a pain in
the neck.

> It has to be said, I agree with you in that I don't think this idea
> would work for Common Lisp.
>
> Just your daily dose from the anti-bigotry squad,
> M.
>

--

Hartmann Schaffer


Hartmann Schaffer

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
In article <399156EB...@kurtz-fernhout.com>,
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
> ...

> I think the answer is that when you copy and paste and code -- be it
> Lisp or C or whatever, you still need to make the indentation work out

you should eventualy, but with a delimiter based syntax you can feed
it into the compiler o interpreter immediately (can help to determine
whether what you want to do really works. with an ndentation based
syntax you must massage the code before you can try. with some
constructs it can also get considerably trickier (try inserting a
block of code that ends with ifs nested several levels somewhere into
i several level deep if structure and keep track which branch belongs
to which level; you'll love parentheses after that)

> ...

this is independent of the widespread (imo correct) opinion the too
deep nesting should be avoided)

--

Hartmann Schaffer


Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Tom-

Thanks for the comments. A few elaborations below.

Tom Breton wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>
> >

> > ======= Some advantages =======


> >
> > One advantage to such an approach it that it might make it easier to
> > compose Lisp on devices without keyboards. An indent-line button and an
> > unindent-line button would be useful in that case.
>

> It isn't clear how that would make it easier; I suspect it would be
> harder. It's also not clear why those two buttons would be better
> than "(" ")" keys. In any case, how many people write code that way?

The reason I thought it easier is that one only needs to press one of
the indent or dedent buttons once per line -- as opposed to having to
press the a button once for each of two parentheses. But this is a
minor issue.

> > Significant indentation might make it easier for developers who don't
> > know Lisp well to understand a Lisp program's structure.
>

> Again, that's kind of a lost cause. If they don't know Lisp, they
> won't make sense of it regardless. If they know Lisp even a little
> bit, they should already be past parentheses problems.

Well, maybe the issue is more "intimidation" than "understanding".

I think, for example, this:

define (foo x)
* x x

is less intimidating than this:

(define (foo x)
(* x x))

for someone not used to dealing with lots of parentheses. And I think it
just gets worse from there in terms of intimidation as the functions get
more complex.

Meaningful hierarchical indentation is often encountered outside of
programming. People use it all the time to make outlines. People write
pseudo-code using meaningful indentation.

> > It might also allow experiences Lisp developers to read programs faster

> > because there is less high frequency "noise" in the text. Every


> > additional character on the screen takes more time for the eye and mind

> > to process. In practice, experienced Lisp developers will rely on the


> > indentation anyway -- as editors are used to count parentheses.
>

> I doubt it would let me or any other experienced Lisp programmer read
> programs faster.

OK. I have no empirical evidence to back up this specific point.

> > Such code will be faster to create. There is less typing, and no worry
> > about unbalanced parentheses. Indentation might be incorrect, but then
> > the mistake in the structure would usually be obvious on inspection.
>
> I doubt it. I suspect you need a different editor, since all these
> things are non-issues when using emacs.

Well, it does seem emacs solves a lot of these issues.

But I think at a cost -- both in the complexity of learning emacs and in
the complexity of having to think about some of these functions. For
example, with indentational syntax, worrying about indentation is
paradoxically a non-issue, because you would rarely or never want to
reindent code.

But it probably true that the cost of learning emacs is relatively low
given the evident benefits it supplies someone developing in Lisp.

> > Also, with significant indentation, indentation can not as often be
> > misleading as it can be with parentheses.
>

> Indentation in Lisp can be trivially made to match the parentheses in
> a good editor.

True. But it is still one more thing to worry about -- one more function
to have to learn. One more thing to have to do periodically.



> > ======= Some disadvantages =======
> >
> > I'm sure people will point out lots. Send 'em on!
>

> > The major one is that this is non-standard and not available.
>

> > Also, it may confuse some people (novices?) as much as it clarifies
> > things to others.
>
> If it does clarify structure.

Well, I think it does. Obviously several people on this newsgroup
disagree.



> Other problems:
>
> It would not survive accidental reformatting. (A problem Lisp only
> has with strings' newlines)

True. But "accidental reformatting" is something one takes care not to
do in a language with indentation that is significant. Also, once one
starts talking about accidents, any thing can happen to a bunch of code
-- including a cat walking on the keyboard.

> It needs additional rules when a line is too long (can't all fit) or
> too short (ie, you want to fit multiple sexps on one line).

Good point. This is a good technical objection. I think one can work
around it, but it is a weakness of the system compared to fully
parenthesized code/data.

> It requires more smarts from editors and other tools. And it's not a
> one-time thing. I've seen plenty of Elisp packages that each
> independently tried to parse some piece of some Lisp. They'd all need
> to be smarter. Some wouldn't exist or would be buggy.

True. Obviously, the current standard has much additional support as
several other people on this newsgroup have also pointed out.

Hopefully though, in the case of emacs, using the strategy a couple of
people have suggested in other posts, this "edge parentheses removal
process" could be made transparent to the rest of the system.



> Printing data readably would be tricky. For embedded expressions, you
> must figure out the proper level of indentation to start at. And it
> would be disastrous when you missed, because there'd be no parentheses
> to indicate how the expression is really scoped.

I'm not sure how it is any trickier in the system I propose than in the
current system. For example, when Lisp pretty prints an expression, it
needs to know the indentation level of embedded expressions. So I don't
see how what I propose is significantly harder than what Lisp does now
(unless you are referring to non-pretty-printed output).

It is true if you printed just part of an expression, the indentation
would typically start at the top level, and so would not be the same as
the expression printed as part of something else. I don't yet see how
that would cause a big problem in practice though. I could believe it
might.

While it is true a mistake in printing would be disastrous, this
printing code would in theory only have to be debugged once, and then
could be used multiple times. But I can see how it might be harder to
debug such code, and related bugs might remain hidden, and this is a
tradeoff in the approach.

> More nebulously, but very important, it "tempts" the language to not
> represent code as data. That's almost the core of Lisp.

Most certainly, separating code and data is not at all an intent of the
approach. I love the concept of mixing code and data -- one reason I
like Lisp.

For an example of defining data using an indentational syntax, if you
are making a zoo inventory, you can input data like so:

'(zoo-inventory
polar-bears 2
igunas 3
ocelots 7
birds
penguins 3
nut-hatches 4
finches 7
elephants 6)

So, I don't see the temptation. This is equivalent to:

'(zoo-inventory
(polar-bears 2)
(igunas 3)
(ocelots 7)
(birds
(penguins 3)
(nut-hatches 4)
(finches 7))
(elephants 6))

I do admit that it would be easier parsing-wise to have quoted lists
entirely done as conventional list syntax, but I think this quote
approach used above could be made to work.

> So all in all, I don't think it would be an improvement.

OK. It might not be.

> But it's good that you're thinking about it.

Well, thanks!

> Tom Breton, http://world.std.com/~tob

I enjoyed your comments.

Paul Fernhout

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Erik-

Ouch!

I do think you have several valid points, and I enjoyed your comments on
later thinking in perceptual human architecures and related issues.

Your point on metrics is well put -- but more likely to hold for a
routinized well learned task. For a less experienced user, more data
often means a longer processing time, because the data is processed by a
primarily serial consciousness. For an experienced user, it may also
mean additional mental resources in use that can't be freed for other
tasks, although it is likely true the processing time may not be
noticeably different in many cases. I wonder if anyone has reaction time
data on this for experienced Lisp developers?

Your point about the potential value of redundancy is quite good, and a
valid cognitive science type objection to the approach as a high cost.

You have an interesting point about the Common Lisp vs. Scheme
distinction.

I am not really at this point marketing much to the Lisp community,
beyond mostly trying to see if this idea has value. However, I think I
have pointed out in several other posts how indentation can in theory be
used without an overly large amount of work, and Python and Occam both
show that it is workable in theory (admittedly, only for those languages
in practice). And Python for example never suffers from problems when a
poorly indented piece of code (typically involving if statements)
convinces the reader it does something other than the code really does.

Obviously however, as you point out, many good editors exist
(specifically emacs) which make Lisp programing much more pleasant than
writing everything by hand (like I did when I first tried Lisp on a
PDP-10 back around 1979).
Unfortunately, that system didn't support "'" and so I couldn't get the
examples to work from Winston's AI book -- not knowing to use "quote"
instead which I later learned worked the same. Maybe if I had known that
then, I would have been doing nothing but Lisp for the last twenty+
years. :-)

As I said in reply to Tom Breton, it is not my intent to separate code
and data. I don't see where in my specification one would get the idea I
wanted to separate them. Obviously though I have somehow given that
impression. If you can show me where I said that or what wording caused
you to believe that, I will take a look at it and try to come up with an
alternative wording that does not seem to imply that.

I understand one would need to make various modifications to the parsing
and printing system to accommodate this approach -- unless one does the
changes transparently in the editor (which must then do its own parsing
and printing).

One more or less factual issue you raised does leave me puzzled.

You wrote in response to my comment:


>> Lisp uses structure to replace much of what other languages do with
>> syntax.
>
> This is simply WRONG.

Perhaps this shows some deep misunderstanding on my part. What I
intended by this was to say, for example that a procedure like "let"
requires its arguments to be in a certain structure for it to operate
correctly (a list of lists for assignments, and then lists of things to
do). In most other languages, there is specific syntax to denote
variable definitions and their assignments and so forth. In that sense,
I see Lisp as relying on "structure" where other languages use "syntax".
Perhaps I am misusing these terms? Also, perhaps you are referring to my
not mentioning keyword syntax here or something like that?

I appreciate your taking the time to respond to the proposal.

Anyway, hoping to keep things cordial.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

David Bakhash

unread,
Aug 9, 2000, 3:00:00 AM8/9/00
to
Bruce Hoult <br...@hoult.org> writes:

> In article <m3punil...@cadet.dsl.speakeasy.net>, David Bakhash

> <ca...@alum.mit.edu> wrote:
>
> > It's the same deal here. You have a universal method for mutation
> > which follows logically from accessing. You claim that the simple
> > things in Java and C++ are simpler? Do you find writing dozens of
> > set_* and get_* methods to be simpler than the :accessor slot option
> > of defclass? I surely don't. Throw in that lots of [Java] code out
> > there doesn't conform to the set/get naming conventions and I'd argue
> > that it's anything but simple and straightforward.
>

> You're right again. Writing hundreds of trivial getters and setters in
> Java and C++ sucks. But you've got no choice if you want to maintain
> the possibility that sometime in the future they might not be trivial
> any more.
>
> But that doesn't mean that it's the syntax of being able to put a
> slot/field/data member reference on the left hand side of "obj.foo =
> bar" that is at fault. The fault is in not making this a function call,
> under the hood. In Dylan, declaring a slot "X.foo" automatically
> creates a trivial getter function "foo(X)" and a trivial setter function
> "foo-setter(newVal, X)" so that writing...
>
> X.foo := X.foo + 1;
>
> ... actually means ...
>
> foo-setter(X, foo(X) + 1)
>
> Of course, 99% of the time this will just turn into a simple inlined
> load and store, just as in C, but it means that you can later change the
> getter and/or setter to do something less trivial with no impact on the
> client code (except recompiling it).

yes. in this case, Dylan made a smart move, and (not surprisingly)
C++ and Java did it wrong, in my opinion. I can't stand trivial
get/set function writing. that's exaclty the kind of stuff macros
were designed for. Still, I think what Dylan does is a bit awkward
too, and syntactically, it's just not my speed. I admit that norvig's
(setf (aref ...) ...) example is probably more easily read by most
people (even lisp people) more easily (because it more closely
resembles a mathematical notation, except for the fact that the `='
operator should be a `<-' operator), but again, this does not buy you
very much, even as far as readability goes. So I'd just leave it by
the wayside and stick to setf.

dave


Bruce Hoult

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
In article <399156EB...@kurtz-fernhout.com>, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> Many people say of Python, "well if indentation is significant, how do I
> copy and paste code?"
>

> I think the answer is that when you copy and paste and code -- be it
> Lisp or C or whatever, you still need to make the indentation work out

> to make the code readable. Often as not this is done by hand. Yes, some
> editors could pretty print the code after cut and paste, but for short
> things typically one may fix it up by hand, especially if you don't
> always agree with the pretty-printer.
>
> Editors designed to support indentation usually have block indent and
> block dedent commands. This makes the procedure of copying code more
> like: "cut", "paste" and then "block indent/dedent to desired nesting".

"Block indent/dedent" is a standard feature on all Mac programmer's
editors, starting from MPW. They even all agree to use cmd-[ and cmd-]
to do it.

It works pretty well, but I think it's *still* better to have the editor
understand the structure of the code and (at least be able to) indent
the moved code automatically. Then if the editor's idea of the correct
indentation differs from yours then you can take a closer look and see
if you really put the pasted code in the right place.


> Yes, some
> editors could pretty print the code after cut and paste, but for short
> things typically one may fix it up by hand, especially if you don't
> always agree with the pretty-printer.

If you don't agree with the pretty-printer then you should fix it :-)

-- Bruce

Bruce Hoult

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to

> Actually, there are other aspects of Lisp syntax that I find more
> annoying than the parens. Compare
>
> s.X[i] = val
> to
> (setf (aref (csp-state-x s) i) val)
>
> The later is what I ended up coding in a constraint satisfaction solver
> I was recently working on. The annoyance is that the former (legal
> Python, Java or C++)

That's also legal (and normal) in Dylan.


> Why does Python/Java/C++ have an
> advantage? Because they typographically distinguish useful operations:
> assignment in Python/Java (and confusingly, copying in C++); indexing;

> and class slots. And also because classes are namespaces in Python/C++,

> but not in Lisp (so I can use X instead of csp-state-x). Lisp
> multimethods are the preferred solution for complex applications, but
> Python/Java/C++ classes do make the easy cases easier.

In Dylan, the statement "s.X[i] := val" will result in calls to the
multimethods/Generic Functions "X" and "element-setter" and means the
same thing as...

element-setter(val, X(s), i)

...so you get the best of both worlds, at the cost of having two
possible ways to write it.

-- Bruce

Bruce Hoult

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
In article <m3punil...@cadet.dsl.speakeasy.net>, David Bakhash
<ca...@alum.mit.edu> wrote:

> Peter Norvig <pe...@norvig.com> writes:
>
> > Why does Python/Java/C++ have an
> > advantage? Because they typographically distinguish useful operations:
> > assignment in Python/Java (and confusingly, copying in C++); indexing;
> > and class slots. And also because classes are namespaces in Python/C++,
> > but not in Lisp (so I can use X instead of csp-state-x). Lisp
> > multimethods are the preferred solution for complex applications, but
> > Python/Java/C++ classes do make the easy cases easier.
>

> This is really interesting. Back in '96 is when I first started using
> Windows (it was Windows 95, of course). I was coming from a Unix
> background, and really despised MS Windows, but really couldn't
> elaborate on why. It was something much deeper than anything overtly
> apparent to me. Then I heard the guy in the cubicle next to mine
> bitching about his windows box. He was also a non-hacker EE type, and
> what he said was:
>
> "I hate this goddamn OS. They try to make everything so &%*#ing
> easy, but as soon as I try to do something that they didn't
> anticipate, it's a nightmare. I want my Unix box back."
>
> His point was exactly that the simple things in Unix seem hard, but
> once you've got them down, the hard things are very similar and follow
> logically from the simple things. There's no dichotomy there, whereas
> for windows he felt that there was, and I finally realized that that's
> what was plaguing me too.

You're absolutely correct, and I agree with you completely.

The problem is that I think you're failing to distinguish between a bad
idea and a bad implementation of a good idea. I program on Unix,
Windows and the Mac, and I share your frustrations with Windows. As
soon as you try to step outside the box it becomes virtually impossible.
But this doesn't seem to apply to the Mac anywhere near as much -- the
MacOS provides quite literally a "toolbox" that you can use to put
together a GUI application, but Windows provides a straitjacket.


> It's the same deal here. You have a universal method for mutation
> which follows logically from accessing. You claim that the simple
> things in Java and C++ are simpler? Do you find writing dozens of
> set_* and get_* methods to be simpler than the :accessor slot option
> of defclass? I surely don't. Throw in that lots of [Java] code out
> there doesn't conform to the set/get naming conventions and I'd argue
> that it's anything but simple and straightforward.

You're right again. Writing hundreds of trivial getters and setters in
Java and C++ sucks. But you've got no choice if you want to maintain
the possibility that sometime in the future they might not be trivial
any more.

But that doesn't mean that it's the syntax of being able to put a
slot/field/data member reference on the left hand side of "obj.foo =
bar" that is at fault. The fault is in not making this a function call,
under the hood. In Dylan, declaring a slot "X.foo" automatically
creates a trivial getter function "foo(X)" and a trivial setter function
"foo-setter(newVal, X)" so that writing...

X.foo := X.foo + 1;

... actually means ...

foo-setter(X, foo(X) + 1)

Of course, 99% of the time this will just turn into a simple inlined
load and store, just as in C, but it means that you can later change the
getter and/or setter to do something less trivial with no impact on the
client code (except recompiling it).

-- Bruce

Robert Monfera

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Espen Vestre wrote:
>
> Peter Norvig <pe...@norvig.com> writes:
>
> > and class slots. And also because classes are namespaces in Python/C++,
> > but not in Lisp (so I can use X instead of csp-state-x).
>
> ...but quite often the defstruct-like idea of using the class name in
> the accessor function is not a very good one

Agreed. It may distract us from recognizing commonalities and
exploiting them via common superclassing. It can even limit your
freedom if these functions are exported - you can't support a new class
without exporting a whole bunch of new functions.

There has to be one single concept under which the various methods
gather, and it should be documented in the GF. X can be a poor function
name (whether or not classes are namespaces) if there are multiple
meanings behind it. Le's have as few GFs as possible, but not fewer!

Robert

Robert Monfera

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Craig Brozefsky wrote:

>
> Erik Naggum <er...@naggum.net> writes:
>
> > I think "down" and "up" are equally useful/likely "buttons". I use
> > Emacs with these operations all the time, in fact. Very seldom do I
> > type invididual parentheses.
>
> How do you avoid that?

I am interested in Erik's answer myself, but there are ways to do it.
Sometimes I would enter parentheses in pairs, guaranteeing balance and
reducing the paren-closing overhead.

Is anyone using an editor such a way that hitting the left paren inserts
a matching right paren? (| -> (|)

Robert

Michael Hudson

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Erik Naggum <er...@naggum.net> writes:

> * Michael Hudson <mw...@cam.ac.uk>


> | From an experienced Pythoneer: don't knock what you don't know.
>

> Let's keep this sage advice in mind for just a few seconds.
>

> | Have you actually found it's dependence on whitespace a problem
> | (other than the "ooh this is different therefore it's bad" response)?
>

> Why are you so unfathomably stupid as to think it's OK for _you_ to
> knock what you don't know right after you've told others not to?
> How the hell did you come up with the _chutzpah_ required to write
> such an obvious attack based on your own ignorance of how others
> reacted to Python's significant whitespace?

While I personally have not had much problem with Python's whitespace,
I have seen many many people post on comp.lang.python saying "I like
Python apart from the whitespace problem" and then just turn into your
regular members of the Python community and get used to it. So I'm
not entirely ignorant of "how others reacted to Python's significant
whitespace".

> Some people just prove that human procreation is too cheap.
>

> The reason _I_ don't like Python's significant whitespace is that I
> don't want to keep doing indentation by hand.

Hey, I don't do indentation by hand... but this is the wrong place for
Python evangelisation. I'll stop now.

> I'm sure it looks good after the fact, but before the fact, which


> I automatically think about as I keep writing stuff and make my
> living writing, it involves a lot of _unnecessary_ work. But hey,
> if you're used to C++ and you think Perl's way too ugly, but still
> has merits, Python probably wins. If you're used to Common Lisp,
> I fail to see how Python could win, except over C++ and Perl and
> possibly Java.

It remains a mystery to me why I still program in Python. Lisp *is*
obviously superior in many ways, but maybe I'm just wierd.

Cheers,
M.

--
I'm not particularly fond of singing GSTQ because she stands for
some things I don't, but it's not really worth letting politics
getting in the way of a good bawling.
-- Dan Sheppard, ucam.chat

Paolo Amoroso

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
On Wed, 09 Aug 2000 18:22:36 +0200, Paolo Amoroso <amo...@mclink.it>
wrote:

> LispMe and pedit provide a comfortable Lisp editing environment,
> considering the hardware and software constraints of the device they run
> on.

This sentence was probably poorly worded. I meant that, given the hardware
and software constraints of Palm devices, pedit and LispMe provide a
reasonably comfortable Lisp editing environment. For more information you
may have a look at a message I posted to the peditors forum, a pedit
mailing list:

http://www.egroups.com/message/peditors/3


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

David Bakhash

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Erik Naggum <er...@naggum.net> writes:

> * Paul Fernhout <pdfer...@kurtz-fernhout.com>


> | Also, with significant indentation, indentation can not as often be
> | misleading as it can be with parentheses.
>
> Your credibility is suffering with this line, too.

In a case like this:

(if (zerop flag)
(progn
(do-this)
(then-that)
(now-this))
(otherwise-this))

it's certainly true that you would think that the last line of code
was part of the progn body. No doubt, if the 2nd to last line had
a more complex form, with more parens, this would be a terrible
indentation.

But this is not an argument in your favor of the indentation-dependent
meaning of code. Just think, if programmers can't figure out how to
indent, which is orders of magnitude easier to do than to write good
code, then they shouldn't be programming. In a good lisp-mode, 98% is
simply a matter of knowing when to press the <ENTER> key. I'd rather
re-indent a whole file (C-x h M-x indent-code-rigidly) or something
than incur such a cost to programming as was suggested in this post.

What the bottom line is that while the points you raise are good, they
don't support your conclusion, though they may appear to. I liked the
point made that redundancy keeps people sane:

> | One issue is that parenthesization is redundant when you use
> | indentation.
>
> Predictable redundancy is what keeps people sane.

Most people would not have answered this way, including me initially
(it was an issue you raised that I was struggling with). But the
reply here is right on. When you consider that the redundancy (in
this case, indentation) comes at almost no additional cost
(i.e. pressing the <ENTER> key and letting the editor do its work),
you realize that it's not a double effort.

When I program, the indentation often hints to me that I've done
something wrong somewhere. What you're proposing would turn a tool
into a chore.

dave

David Bakhash

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> By the way, does:
>
> setf
> aref (csp-state-x s) i
> val
>
> seem any clearer?

clearer than

(setf
(aref (csp-state-x s) i)
val)

???

no. not particularly. My brain knows that right after I typed "val",
that the "val" was the new value in a setf, and that I should close
it. So I press that closing paren, then press enter, with almost no
concern about indentation, unless the cursor ends up somewhere that
looks funny. In addition to just knowing how many parens to press,
paren-matching/highlighting helps too.

dave

Chris Page

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
To a great extent, it is. Most programming languages have a lot in common.

In any case, it is my primary belief that the whole issue of syntax is a red
herring. Programming should be a high-level, automated process in which the
syntax of the language is largely of no concern to the programmer.

Programmers should edit "programs" not "text files". How programs are
displayed to programmers should be a flexible and dynamic affair. There are
already a lot of editors with auto-formatting, and dedicated
"pretty-printers" for static code presentation -- and the kinds of things
they do should certainly be a part of what I'm suggesting. However,
programming tools should move beyond mere indentation, bracket matching,
coloring and highlighting.

A great book on the topic of improved code presentation is:

Human Factors and Typography for More Readable Programs
Ronald M. Baecker & Aaron Marcus
ACM Press
ISBN 0-201-10745-7

One simple idea from that book is that C braces are almost completely
unnecessary if the indentation is correct. Eliminating them improves the
readability of C, at least. And thus dies the age-old question: Where do you
put the opening brace?

These ideas for presentation should then be integrated into the editing
process. Using the above example, not only are braces unnecessary in the
presentation, they do not need to be typed by programmers. Instead, a
programmer could place the insertion point somewhere in the code, and create
a "for" statement. They would not type all the other text or punctuation;
the parenthesis, the semicolons, the braces, the white space. The insertion
point would be placed at the first appropriate spot for adding more code,
and moving the insertion point would skip across the punctuation to the
empty statements where code may be entered. Syntax-related coding errors no
longer exist.

Of course there are editors that do some of these kinds of things, but they
are still manipulators of raw, plain text. They usually aren't capable of
automating editing tasks that require deeper knowledge about the language or
the particular program being edited (e.g. they don't know about definitions
or macros).

I think the future holds a programming experience where syntax is fluid --
perhaps even changing moment by moment to present programs in a way best
suited for what the programmer is doing at that time -- and programs are
manipulated in terms of their semantic objects at a far quicker pace and
with less errors than at present.

Think I'm blue-skying? Just wait. Or better yet, start working on making it
a reality.

P.S. When you have an editor that manipulates code rather than text, then it
also becomes possible to instantly recompile code as it is changed, because
the compiler's workload is dramatically reduced. There are a number of
wonderful implications, including some that have nothing to do with the
compiler (e.g. revision control can operate at a higher level of
abstraction).

P.P.S. Languages like Dylan, Lisp, and Smalltalk can be edited and compiled
one definition at a time, so they're ahead of the game. The semantics of
C/C++ compilation units make it more difficult (and occasionally impossible)
to minimize the amount of code that must be recompiled when something as
trivial as a comment is changed.

--
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", "@", "best.com>");

Chris Page

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
in article m3ya25v...@cadet.dsl.speakeasy.net, David Bakhash at

ca...@alum.mit.edu wrote on 2000.08.09 23:51:

> clearer than
>
> (setf
> (aref (csp-state-x s) i)
> val)
>
> ???
>
> no. not particularly. My brain knows that right after I typed "val",
> that the "val" was the new value in a setf, and that I should close
> it. So I press that closing paren, then press enter, with almost no
> concern about indentation, unless the cursor ends up somewhere that
> looks funny. In addition to just knowing how many parens to press,
> paren-matching/highlighting helps too.

Imagine, instead, you type "setf aref csp-state-x s i val" and it appears
however you want it formatted. Or however someone else wants it formatted,
depending on who's looking at the code.

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Hartmann -

Thanks for the comments.

Your point about the difficulties of cutting and pasting nested if
structures is well made. It is quite true that if you insert such code
you could easily loose track of where it belongs.

This is definitely a time when one needs to leave the code highlighted
after a paste and immediately move it into position using indent/dedent.
But, I think in practice, when indentation is significant, people tend
to always do formatting right away when cutting and pasting anything --
so as to always maintain the logical structure of the program. So, I
don't see this being a big problem in practice, and in the Python or
Occam case I don't remember ever experiencing such a problem (at least
not down the road -- it may have been more of an issue at the start).

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Hartmann Schaffer wrote:
>
> In article <399156EB...@kurtz-fernhout.com>,

> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
> > ...


> > I think the answer is that when you copy and paste and code -- be it
> > Lisp or C or whatever, you still need to make the indentation work out
>

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Chris-

Wow! What a great post!

This is a much more sophisticated idea than what I propose.
Thanks for sharing it.



-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

The Glauber

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
The use of indentation to convey syntax is interesting and may lead to
more readable code. The reason i don't use Python anymore and i hope
never to have to use this kind of language again is simple: even though
my indentation is always correct and perfect :-), my colleagues are not
as good as i am in choosing a system and sticking to it.

This is complicated by the existence of editors that use tabs for
indenting (like our old friend, vi), and people who will then change
the meaning of the tab to whatever is their favorite prime number that
day (3 spaces, 5 spaces, 7...).

If i have to work with some horribly indented piece of code written in
C or Java, i can usually fix it either by hand or using a tool. It
would be pretty exciting (in the bad way) if, by fixing the
indentation, i would be introducing subtle syntax changes too.

As for Lisp, the joy of Lisp is in the parens!

Anyway, just my .02

g

--
Glauber Ribeiro
thegl...@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"


Sent via Deja.com http://www.deja.com/
Before you buy.

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
David-

Thanks for the comments.

I've realized from this example what it is visually about parentheses
that can be confusing, especially to one less experienced with Lisp
syntax.

Naively, to an eye used to looking for objects in space, where
physically proximity in three dimensions helps denote an "object", the
following:

(setf
(aref (csp-state-x s) i)
val)

could be broken down by the eye/mind into rounded graphical objects as
follows:

1:

(setf
(csp-state-x s) i)

2:

(aref
val)

if one proceeds on the principle that parentheses which are "spatially"
closest (in 2D) match first. Just imagine these as free floating
molecules of S-expressions that get docked somehow to see the
possibility.

While the beginning Lisp user may have been told it doesn't work that
way, the eye (perhaps only at first) may be still trying to make sense
of what is on the page using conventional rules of spatial association.

When everything is written on one line like so:

(setf (aref (csp-state-x s) i) val)

this is not an issue. But as soon as things are indented, this becomes a
potential problem.

Granted, an experienced Lisp developer may see past this issue, and
learn to enforce a strict left-to-right and wrapping interpretation of
conceptual units. Their eye may get trained to see that in a Lisp
context. At that point, what I point out may never occur to them as a
possible reading. If it did despite training, one might think of it as
"Lisp Dyslexia" since it would certainly make it harder to work with
Lisp code.

However, to someone without that Lisp developing experience, the
expectation of the eye for spatial closeness in 2D or 3D can be violated
in many, many Lisp expressions using parentheses as they are presented
on the 2D page.
The approach outlined using significant indentation has less of this
perceptual problem (although granted it may bring up others).

To be fair, by this logic, the indentationally significant example:

setf
aref (csp-state-x s) i
val

could be read as:

1:

setf
aref
val

2:

(csp-state-x s) i

but that feels a less natural reading to me, and there are no
parentheses in this case to reinforce this particular visual parsing.
However, granted I may be biased from being used to a similar convention
in other languages, so others might parse it that way visually.

I would then point out that this specific visual parsing still makes
sense in a way, because in practice (1:) is the structure of the "high
level" view of the code, and (2:) is a detail to one line of (1:). This
will almost always be the case, because the indentation rules I outline
would most usually result in a "backbone" of code running down the left
edge of the expression. Thus, even this unexpected parsing aids in
understanding the code, whereas in the parenthesized case the unexpected
parsing is at odds with the true structure of the code.

I must say, I'm enjoying all these comments because they are making me
think much more deeply about this issue.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

David Bakhash wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>
> > By the way, does:
> >
> > setf
> > aref (csp-state-x s) i
> > val
> >
> > seem any clearer?
>

> clearer than
>
> (setf
> (aref (csp-state-x s) i)
> val)
>
> ???
>
> no. not particularly. My brain knows that right after I typed "val",
> that the "val" was the new value in a setf, and that I should close
> it. So I press that closing paren, then press enter, with almost no
> concern about indentation, unless the cursor ends up somewhere that
> looks funny. In addition to just knowing how many parens to press,
> paren-matching/highlighting helps too.
>

> dave

Erik Naggum

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
* Erik Naggum

| I think "down" and "up" are equally useful/likely "buttons". I use
| Emacs with these operations all the time, in fact. Very seldom do I
| type invididual parentheses.

* Craig Brozefsky


| How do you avoid that?

M-( inserts () and leaves point between them. M-) leaves point
after the closing paren. (A numeric argument, n, to M-( wraps the
next n s-exprs in parens.) I have written similar functions for []
and {}, as well as "" and **. This means I don't generally have
unmatched paired delimiters in my code. (This is a simplification
of the SGML code I wrote years ago to start with <></> and let each
character (up to the first whitespace) in the start-tag also insert
in the end-tag.)

* Erik Naggum


| Oh, right, you're thinking in Scheme, which _is_ a language that
| breaks this important property of Lisp, and has a character-level
| syntax, like Algol.

* Craig Brozefsky
| I understand this difference, but I'm unable to see the
| repurcussions it has.

Look at Dylan. It had a Lisp-like syntax at first, then lost it
because of the syntactic changes in the "other" syntax. If you
don't constantly think in terms of LL(1) grammars and readers that
return objects, someone will begin to think in other terms and win
popularity because people generally just accept visible concepts,
but don't think about them if they aren't immediately visible.

So even if the significant-whitespace proposal is OK now, _because_
of the explicit list structure, some next step will lose the list
structure because someone will make another "innovation" that leaves
that heritage behind.

| In R5RS any Expression will also parse as Datum (what read
| understands).

In scheme, (if 1 2 3) and (if 1 2 . (3)) are identical as data, but
as code, they are different. [I think this is completely idiotic.]

Eugene Zaikonnikov

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
>>>>> "Rainer" == Rainer Joswig <jos...@corporate-world.lisp.de> writes:

[...]

Rainer> Well, and this is still far from what the Lisp machine's
Rainer> Zmacs does, where the editor for example parses the
Rainer> buffers into definition chunks. So you edit a while in
Rainer> your various Lisp buffers and after a while you say
Rainer> "Compile Changed Definitions" and the Lisp system knows
Rainer> what definitions you have changed and compiles them. And

IIRC, LispWorks IDE also has a feature like you described.

--
Eugene.

Erik Naggum

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
* Peter Norvig <pe...@norvig.com>
| But when I write code on paper, I often use a style like this to
| save time.

Interesting (implicit) question. When I worked with Ada some 15
years ago, it was the first and so far the last language where my
notes on paper were practically syntactically valid -- they had to
be to be meaningful. Some of the redundancy you find in most other
languages can be ignored when writing on paper, in some almost all.
(C has a _lot_ of redundancy, for instance, mostly because of its
sorry excuse for an explicit static typing system.)

| Actually, there are other aspects of Lisp syntax that I find more
| annoying than the parens. Compare
|
| s.X[i] = val
| to

| (setf (aref (csp-state-x s) i) val)

Some of this may be handled by a specialized infix reader. I prefer
to bind "mathematical" syntax to $, so $ ... $ is a "mathematical"
form. (The choice of delimiter should be obvious, and if anything
is obvious when it comes to special mathematical syntax, it's $.)

| And also because classes are namespaces in Python/C++, but not in
| Lisp (so I can use X instead of csp-state-x).

Huh? Of course you can use X. Accessors are generic functions.

I don't like the dot notation, as I already pronounce (x s) as "x of
s", and that's as fitting for slot accessors as for function calls,
which means that "s.x" gets the order wrong. (I could pronounce it
"s's x", mirroring the Norwegian pronounciation "s sin x", but that
has always rubbed me the wrong way.)

$ (x s)[i] <- val $

If the dot notation is important, it shouldn't be hard to add.

Russell Wallace

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Paul Fernhout wrote:
> I'm interested in using significant indentation (like in Python)
> http://www.python.org
> to replace many parentheses in Lisp or Scheme programs.

Interesting idea! I'm afraid my response is going to be negative, but
thanks for posting the idea anyway, it's certainly sparked some
discussion and helped me clarify some thoughts.

I don't see any big practical problems with the proposal, but I must
admit I'm still not fond of it.

> While some people can't get past significant indentation in Python
> (citing for example occasional difficulty cutting and pasting code from
> newsgroup posting or mail sent with old mail clients) and stick with
> Perl, etc., the ones who do get past the unfamiliarity with
> indentational syntax almost uniformly like it and say it is a feature
> that aids program readability.

Maybe. If that's a rule, then I'm an exception to it.

I've found no practical problems whatsoever with Python's
indentation-based syntax. (I indent C the same way, after all, even
though the language doesn't require it.) Nonetheless, it still makes me
feel a bit queasy. The best analogy I can think of is drinking milk
that hasn't _quite_ gone off yet. You have to admit there isn't any
practical problem with drinking the stuff, but nothing will ever
convince you it wouldn't be better if it was perfectly fresh.

For me, the issue isn't one of practice, but of aesthetics, and no
practical argument will ever convince me to like indentation-based
syntax. (If typing brackets was a lot of work it might be different,
but it's not.) Now I use Python happily enough anyway (it helps that I
use it for scripting/prototyping stuff where the emphasis is more on
"get the job done quickly" than on "build to last"), but I'd be even
happier if that aspect of it were different.

And I suspect that for most people who dislike indentation-based syntax,
their real reason is aesthetic also.

> Yes, people put down Lisp saying it stands for "Lots of Infernal Stupid
> Parentheses". Rather than be defensive, here is an approach that might
> do something about what much of the world perceives as a difficulty in
> reading and writing Lisp code.

People do say that, and they talk about prefix versus infix. But I
don't think those are the real issues. I've switched from Scheme to
Python for AI/prototyping work for reasons of syntax, but it's not a
question of the number of brackets required, or of putting the + sign
before the operands rather than between them, and I think that's true
for most Lisp-avoiders. So I don't think your proposal would actually
help.

--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwal...@esatclear.ie
http://www.esatclear.ie/~rwallace

Paolo Amoroso

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
On Wed, 09 Aug 2000 14:03:28 -0400, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> caught on yet in commercial usage to the degree it deserves compared to
> say C, considering the elegance and power of the system (notable
> exceptions like http://www.franz.com/success/ excepted). Instead, more

It should be noted that the availability of information on Lisp success
stories on Web sites or elsewhere is mainly related to the time people are
willing to spend to tell about them, not much with Lisp's actual
popularity. Take for example the commercial applications page at the ALU
site:

http://www.alu.org/table/commercial-use.htm

It is out of date and the maintainer recently asked for help in order to
make it more current. I am not an industry insider, yet I was able to
contribute a few tens new entries, and I will submit some more.

So you are probably not going to find Lisp product ads in major newspapers
or glossy computer magazines. And you may not hear about hot quote-com
IPOs. But Lisp might be more widespread than many suspect.

Paolo Amoroso

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
On Wed, 09 Aug 2000 16:02:44 -0400, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> On a tangent, could it be that the reason for a lot of cut and paste in
> Lisp is precisely because it is so hard to get all those parentheses

Could you elaborate on this? From which sources did you get the impression
that cut and paste is common in Lisp (no pun intended), or possibly more
common than in other languages?

Rainer Joswig

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
In article <3991CA48...@kurtz-fernhout.com>, Paul Fernhout
<pdfer...@kurtz-fernhout.com> wrote:

> Very interesting comment. I have used NewtonScript and HyperTalk and
> looked at those others. Maybe in part Apple was just hung up on Pascal
> syntax (the original Mac system programming language)?

Well, you can read about it in Dylan discussion archives
about switching the Dylan syntax.

> developers are often the ones most in need of things like version
> control or advanced editing or debugging features (or even just well
> tested stability!), and yet these are usually the last things to be
> added (if ever) to new experimental languages for novices.

The experimental multimedia development environment SK8 from
Apple had all this. It was written in Macintosh Common Lisp.
The source is still available.

> > Still I think there is good reason to experiment with a different
> > I/O system: surface syntax, reader, printer, editor support, ...
> > If it is good, people might use it.
>
> Build it and they will come! :-)

"Demo or die".

--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de

Craig Brozefsky

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Erik Naggum <er...@naggum.net> writes:

> M-( inserts () and leaves point between them. M-) leaves point
> after the closing paren. (A numeric argument, n, to M-( wraps the

Schweet. Makes LET expressions trivial to type and really cuts down
cursor moving when doing things like wrapping sexps in a conditional.
This is a very useful time saver.

> | In R5RS any Expression will also parse as Datum (what read
> | understands).
>
> In scheme, (if 1 2 3) and (if 1 2 . (3)) are identical as data, but
> as code, they are different. [I think this is completely idiotic.]

Ahh, the price of having all Expressions be Datum, but not all Datum
are Expressions. Not until I thought of the programmatic
construction, spurred by this example, did I realize how big of an
issue it could be.


--
Craig Brozefsky <cr...@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---

Daniel Barlow

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
> But I think at a cost -- both in the complexity of learning emacs and in
> the complexity of having to think about some of these functions. For
> example, with indentational syntax, worrying about indentation is
> paradoxically a non-issue, because you would rarely or never want to
> reindent code.

I don't buy that. Supposing you have a chunk of code

(let ((b (cdr x)))
(doo b)
(and (worth-it-p b)
(pay b))
(bar b)
(sting-like-a b))

then later realise that x can be an atom. So you surround the whole
thing with "(if (listp x)".

To do this using CL, you just type that on the line above the original
code, close the paren at the end of the conditional and run M-x
indent-sexp. Because there are parens denoting the structure, it's
simple for the editor to reindent using the information that they
contain. I'm not sure whether you could do this reliably if the _only_
indication of structure were the indentation.


-dan

--
http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm

David Bakhash

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Erik Naggum <er...@naggum.net> writes:

> $ (x s)[i] <- val $

Do you have code that parses this (minus any dot notation, which I
also don't care too much for)? infix.lisp has some of the stuff I
think one would need to implement this, but I don't think it's
complete, and (sin x) is, as far as I know, expected to be sin(x) with
infix.lisp. What you seem to have above is a bit hybrid. But
infix.lisp also had a way to escape to pure lisp syntax inside the
$'s.

dave

David Bakhash

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Russell Wallace <rwal...@esatclear.ie> writes:

> I've switched from Scheme to Python for AI/prototyping work for
> reasons of syntax, but it's not a question of the number of brackets
> required, or of putting the + sign before the operands rather than
> between them, and I think that's true for most Lisp-avoiders. So I
> don't think your proposal would actually help.

You are not the first AI person I've heard of moving from some Lisp to
Python. I'd be first inclined to wonder why you didn't convert to CL
instead. But, guessing that you considered, and probably tried CL,
can you elaborate on why Python over Scheme, or (better) of CL? It's
about time I asked. I looked over Python, though didn't dive into
it. I hated it right away, at least for AI-related applications.

thanks,
dave

Craig Brozefsky

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Russell McManus <russell...@msdw.com> writes:

> Just keep programming in Lisp, and the paren issue will cease to
> become a problem.

On that note, I can say that during my earlier days of learning Lisp
and scheme both, the parenthesis were never any problem at all,
neither confusing nor intimidating. When I was trying to wrap my head
around the distinction between compile, eval, and load time or any of
the other concepts Lisp introduces that are MUCH more alienating and
tremendously more important than its syntax, the simplicity of lists
was a boon, not a burden.

I think the "common sense" understanding that parens are confusing and
intimidating to new users is utterly bogus. It's like television
news, commenting on the most obvious, yet utterly unimportant details
of an event, meanwhile the more pressing implications of the event go
unaddressed.

Python was/is a pedagogical tool, and it's decision to make syntax
significant was based on that context. It was designed to teach new
CS students better habits for the formatting of code, by making a
standard formatting schema mandatory. Lisp already has
pretty-printers and editor support for encourgaing good formatting
habits.

Kent M Pitman

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Chris Page <pa...@best.NOSPAM.com> writes:

> Programmers should edit "programs" not "text files". How programs are
> displayed to programmers should be a flexible and dynamic affair.

I don't buy this. If you'd just said

Programmers should have the option to edit "programs" instead of "text files"
if they so choose. How programs are displayed to them should be possible to
make flexible and dynamic if they find that useful.

I would not have any problem.

Writing programs is a form of expression, and I think it's fair to leave
the programmer whatever control he/she wants.

When I play Scrabble(R), I observe that some people have to always face the
board to play. So they spin the board toward them to make this easy. This
drives me nuts. I don't care if I face the board--I only care that the view
does not change during the game. If possible, I try to negotiate a fixed
position of the board, even if it's always upside down for me, so that I can
not have the board view shift during play. That's what suits me. Others
deal differently. The world needs to be about choices. Strangely, "flexible
and dynamic" does not sound like choices to me. "optionally flexible and
dynamic" sounds fine to me.

> There are
> already a lot of editors with auto-formatting, and dedicated
> "pretty-printers" for static code presentation -- and the kinds of things
> they do should certainly be a part of what I'm suggesting.

Emacs has this but you have to call on it when you want it. I sometimes
use these facilities but never like the "electric" mode where it does them
without asking.

> However,
> programming tools should move beyond

"the option of"

> mere indentation, bracket matching,
> coloring and highlighting.
>
> A great book on the topic of

"one person's view of"

> improved code presentation is:
>
> Human Factors and Typography for More Readable Programs
> Ronald M. Baecker & Aaron Marcus
> ACM Press
> ISBN 0-201-10745-7
>
> One simple idea from that book is that C braces are almost completely
> unnecessary if the indentation is correct. Eliminating them improves the
> readability of C, at least. And thus dies the age-old question: Where do you
> put the opening brace?

The answer to these questions is always statistically related to what's
"common" and what's "uncommon". This whole business of indentation as a
substitute for bracketing, etc. is all a statistical argument. I don't
doubt that there are cases where this is useful. But I get irritated when
people say unconditional things likes "improves" rather than adding an extra
conditional notating the test conditions under which this is an improvement.

The age-old question never dies because the problem can't be gotten rid of.
These things run in cycles. People get rid of braces because they tire of
them, and then they invent braces because they tire of not having them. Each
time, they are sure they have solved the world's problems. The fact is that
there's virtue in both, and the best thing is to acknowledge that no single
syntax suffices for all, and to work on ways to make syntax more of a personal
choice and less of something that is offered as dogma.

There are no more superior ways to arrange code than there are superior ways
to arrange your living room furniture. Certainly there are "common issues
to consider" and there are "internally clashing styles" but even so there are
lots of variations that are ok, any one of which satisfies only some.

> These ideas for presentation should then be integrated into the editing
> process.

For people that want them. Text is fine for me, for example. The OPTION
to integrate them into editing is fine. Personally, I prefer Emacs exactly
because it gives me 100% control when I want it and allows me to elect to
relax my control on my own choice.

> Using the above example, not only are braces unnecessary in the
> presentation, they do not need to be typed by programmers. Instead, a
> programmer could place the insertion point somewhere in the code, and create
> a "for" statement. They would not type all the other text or punctuation;
> the parenthesis, the semicolons, the braces, the white space. The insertion
> point would be placed at the first appropriate spot for adding more code,
> and moving the insertion point would skip across the punctuation to the
> empty statements where code may be entered. Syntax-related coding errors no
> longer exist.

There still has to be an unambiguous way to present and store the
code, and that will involve syntax. It's a myth to say there is no
syntax-related coding. You may succeed in making this opaque to users,
and that may please some, but it will frustrate others.

It's fine to say some people want to autogenerate code or not deal at
the presentation level, but not everyone does.

> Of course there are editors that do some of these kinds of things, but they
> are still manipulators of raw, plain text.

And sometimes intentionally so.

> They usually aren't capable of
> automating editing tasks that require deeper knowledge about the language or
> the particular program being edited (e.g. they don't know about definitions
> or macros).

They happen not to, but they can be taught. Symbolics used to have a lot of
tools that did stuff taking into account of such stuff. People can manipulate
definitions in the face of macros, and I'm confident that programs can be made
to deal like people.



> I think the future holds a programming experience where syntax is fluid --

I'm happy for you. I hope I'm done programming by the time the invasive
world you describe comes to pass, unless it leaves me the option to control
presentation in my own way.

> perhaps even changing moment by moment to present programs in a way best
> suited for what the programmer is doing at that time -- and programs are
> manipulated in terms of their semantic objects at a far quicker pace and
> with less errors than at present.

You still have to have a way to look at them, unless you're basically going
to say that the visual system offers no leg up in understanding. As a
regular reader of audiobooks, I find it hard to believe that the visual system
doesn't contribute a lot of useful stuff that is sadly lost if a system doesn't
use them. If the system does use visual presentation and doesn't let the
user fix a preferred presentation, it increases the amount of time it will
take to look at the program each time it is presented because it won't be the
form in which the person last saw it and it will take a while to verify that
it hasn't been screwed over by whatever reformatting is done, plus time to
link back up whatever mental pointers you had recorded in spatial form to
the new locations offered by the "helpful" system.

> Think I'm blue-skying? Just wait. Or better yet, start working on making it
> a reality.

Not me.

I'm happy to work on systems that understand and manipulate presentation,
but I'm not happy to work on systems that purport to "take over" presentation
and leave the user out of it.

> P.S. When you have an editor that manipulates code rather than text, then it
> also becomes possible to instantly recompile code as it is changed,

And hopefully to know whether compilation contains anything like a
load-time-value of a call to delete-file on something I care about. Or
perhaps something more subtle than that. "Synchronization" happens
implicitly in editing systems I use by virtue of my need to issue commands.
Your aggressive world better introduce a protoocl for synchronizing the
difference between "edited code" and "ready to be deployed code".

> because
> the compiler's workload is dramatically reduced.

This isn't the only reason that code isn't instantly compiled now.

> There are a number of
> wonderful implications, including some that have nothing to do with the
> compiler (e.g. revision control can operate at a higher level of
> abstraction).

Insert discussion of the complexities of "version synchronization" here.

> P.P.S. Languages like Dylan, Lisp, and Smalltalk can be edited and compiled
> one definition at a time, so they're ahead of the game. The semantics of
> C/C++ compilation units make it more difficult (and occasionally impossible)
> to minimize the amount of code that must be recompiled when something as
> trivial as a comment is changed.

Certainly determining which modules need recompilation is easier, and the
work is less. It's only the "happening automatically" that is bugging me
throughout here. A lot more goes through my mind before recompiling than
the mere words "why doesn't this happen automatically when I type close paren?"


Lieven Marchand

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Chris Page <pa...@best.NOSPAM.com> writes:

> Think I'm blue-skying? Just wait. Or better yet, start working on making it
> a reality.

You might look at the past and the present. There has been a project
to make an environment like that for C++ at AT&T. Stan Lippman worked
on it before he went to Pixar and has written a few articles on
it. The project got axed before completion, but I don't know
why. Also, IBM's VisualAge X tools (for X in Java, PL/1, Smalltalk)
work that way. They seem to get mixed reviews with some people
absolutely loving them and some hating them.

--
Lieven Marchand <m...@bewoner.dma.be>
Lambda calculus - Call us a mad club

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Paolo-

Mostly that impression is from comments on this newsgroup to this
posting. The possibility that an indentational syntax might make cut and
paste more difficult seems to be a source of strong objections to an
indentationally significant syntax (not that there aren't others).

I have no other evidence that Lisp developers cut and paste any more
than other language developers. If anything, I would expect Lisp
developers to cut and paste much less than usual. This is because of the
Lisp tradition of abstraction -- which Lisp lends itself to so easily.
Since it is so easy to write a function in Lisp (no prototyping is
needed for example unlike C), Lisp makes it easy for the developer to
build software from lots of little functions. (Whether these functions
are reusable easily in other applications is another story...)

It was only when I thought about the reason why cut and paste seemed so
important to some posters that I realized that some Lisp developers may
be cutting and pasting generic structures in Lisp (by copying from an
example with the same structure), and then by hand changing the symbols
to suit the current situation.

If this were true (and I don't know that it is, I'm just guessing) it
might prove a useful observation leading to creating a new Lisp tool,
perhaps combining a library of typical structures and a
fill-in-the-blanks sort of instantiation process, along with some easy
way to search for the right sort of structure to start with.

Thanks for the interesting question.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Tom Breton

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Chris Page <pa...@best.NOSPAM.com> writes:

>
> I think the future holds a programming experience where syntax is fluid --

> perhaps even changing moment by moment to present programs in a way best
> suited for what the programmer is doing at that time -- and programs are
> manipulated in terms of their semantic objects at a far quicker pace and
> with less errors than at present.
>

> Think I'm blue-skying? Just wait. Or better yet, start working on making it
> a reality.

People have been saying that for decades, and programmers still
relentlessly keep dealing with text source. Of course, they also
still use C and its children too...


--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.

Tom Breton

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to

> Robert Monfera <mon...@fisec.com> writes:
>
> > Is anyone using an editor such a way that hitting the left paren inserts
> > a matching right paren? (| -> (|)

I am all the time. I use (and wrote) sm-insert.el for emacs which
does the same for braces, brackets, anything the syntax table defines
as matching delimiters.

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Russell-

Thanks for the encouragement!

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com


Russell McManus wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
>

> > I would think that rapidly seeing strucutre implied by spacing uses
> > visual perceptive abilities to see symmetry and consistency and grouping
> > most people have. I assume this, but I may be wrong. Perhaps some people
> > don't easily see the structure specified by the white space. Counting
> > parentheses may use different abilities -- perhaps ones I personally am
> > weaker in.
>
> Lisp programmers use the indentation to see the structure of the code.
> The editor can reindent whole expressions with a keystroke. The
> parens make it easy to implement the advanced editor features that
> have been discussed, without building a complete parser for the
> language you are editing into the editor.


>
> Just keep programming in Lisp, and the paren issue will cease to
> become a problem.
>

> -russ
>
> --
> They don't make nostalgia like they used to.

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Paul-

This comment you made greatly interests me, regarding the proposal I
outlined:

You wrote:
> But Lisp's parentheses are not at all the same thing as C's braces.
> You could certainly replace parentheses with more syntax (at some
> cost)...as has been done in the past, with Dylan for instance...but
> not just indentation.

The whole point of my proposal was that indentation (plue "..." to
indicate the start of a list of lists) was adequate to represent any
S-expression when one is just interested in removing redundant "edge"
parentheses.

I understand people have many reasons why they may not want to use
indentation in Lisp, but I still haven't heard of any technical
objections to why it could not work which have included a specific
example.

There has been some misunderstanding by people thinking that I wanted to
introduce an algol-like syntax or such (not the case!) or that I wanted
to seperate code and data representations (also not the case!). Really,
I'm just trying to define an alternate way of displaying and creating
S-expressions without changing any fundamental properties of the
underlying Lisp language (and thus, to an extent somewhat along the
lines of Chris's post).

If you could point out an example where indentation (and the occaional
"..." and a few parentheses) would not work to represent a Lisp
S-expression (thus showing the rules I outlined to be technically
incomplete or flawed) I would greatly appreciate it.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Paul Foley wrote:


>
> On Thu, 10 Aug 2000 04:19:38 -0700, Chris Page wrote:
>
> > It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
> > To a great extent, it is. Most programming languages have a lot in common.
>

> For most languages syntax isn't very important; it's just a "surface
> feature" that you learn to live with. But for Lisp, what syntax it
> has is _vitally_ important. Lisp _is_ essentially the "semantic
> objects" representation you mention later.


>
> > One simple idea from that book is that C braces are almost completely
> > unnecessary if the indentation is correct. Eliminating them improves the
>

> Which is why Python doesn't have braces.
>
> But Lisp's parentheses are not at all the same thing as C's braces.
> You could certainly replace parentheses with more syntax (at some
> cost)...as has been done in the past, with Dylan for instance...but
> not just indentation.


>
> > presentation, they do not need to be typed by programmers. Instead, a
> > programmer could place the insertion point somewhere in the code, and create
> > a "for" statement. They would not type all the other text or punctuation;
>

> Structure editors have been done to death. Besides which, the "other
> text or punctuation" usually consists of single characters, which take
> no more (and often rather less) time to type than it takes to move the
> cursor around.


>
> > P.S. When you have an editor that manipulates code rather than text, then it
>

> What is Lisp if not "code rather than text"?
>
> --
> When C++ is your hammer, everything looks like a thumb.
> -- Steven M. Haflich
> (setq reply-to
> (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Daniel-

Thanks for the interesting comment. Let's work through that example,
using syntactically significant indentation and no edge parentheses.

Say you have an indented equivalent to the expression you defined:

let
...
b (cdr x)
doo b
and
worth-it-p b
pay b
bar b
sting-like-a b

then you later realise that x can be an atom.

So you now want to make this S-expression part of another S-expression.

First you select the expression. You know where the expression ends by
finding by eye the first line that is indented equal to or less than the
"let" starting the S-expression. (To make this easier, an
indentational-aware editor could select to that line when you press a
"select expression" meta-key combination when on the line with "let".)

Having selected the expression you wish to embed, you do now indent the
entire expression using an "indent-block" editor command key
combination.

Then you type in the statement "if (listp x)" above it, at the previous
indentation. This produces:

if (listp x)
let
...
b (cdr x)
doo b
and
worth-it-p b
pay b
bar b
sting-like-a b

You do not need to add a paren, and you do not need to reindent (beyond
the initial indent-block command). Note also that in a complex
expression, using conventional parenthetical S-expression syntax, it
might have been easy to have inserted that extra paren at the wrong
place. With an indentational system, that particular mistake could not
be made (although I'm sure other mistakes could).

Note that this process could be made even easier by assuming a very
smart indentionally aware Lisp editor. In that case you would just put
the cursor on "let", press a key combination to make a new line indented
to the same level above the expression, type "if (listp x)" on that line
above the expression, and then hit a key combination that says "make the
next S-expression be indented under this one".

Or, this might even be all set up on one key combination -- "insert line
and nest this one" activated with the cursor on the "let". Then you just
type in "if (listp x)" and you're done.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the GPL'd Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Daniel Barlow wrote:
>
> Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Craig-

A very interesting post. Some comments below.

Craig Brozefsky wrote:


>
> Russell McManus <russell...@msdw.com> writes:
>
> > Just keep programming in Lisp, and the paren issue will cease to
> > become a problem.
>

> On that note, I can say that during my earlier days of learning Lisp
> and scheme both, the parenthesis were never any problem at all,
> neither confusing nor intimidating.

Just to be clear, I don't find the notion of parenthetical expressions
itself confusing. I agree it is elegant and consistent. It is just the
redundancy and visual clutter I find unappealing at the moment. But,
that is an opinion obviously not shared by many if not all experienced
Lisp developers on this newsgroup. I also see unnecessary work involved
in manipulating some parentheses at the edges of lines in addition to
managin indentation, but I am not a current emacs user like many of the
people on this newsgroup, and I can see how emacs or alternatives
environments like DrScheme can make many of these issues easy to manage.

> When I was trying to wrap my head
> around the distinction between compile, eval, and load time or any of
> the other concepts Lisp introduces that are MUCH more alienating and
> tremendously more important than its syntax, the simplicity of lists
> was a boon, not a burden.

Excellent point. In general, you are right on the mark. The really
complicated and difficult problems in computing have to do more with
understanding concepts and creating specific complex implementations
than with mastering any specific syntax. However, that is not to say an
inelegant syntax can't slow one down.



> I think the "common sense" understanding that parens are confusing and
> intimidating to new users is utterly bogus. It's like television
> news, commenting on the most obvious, yet utterly unimportant details
> of an event, meanwhile the more pressing implications of the event go
> unaddressed.

Good point. Actually, looking at something like the TeachScheme!
project,
http://www.cs.rice.edu/CS/PLT/Teaching/
if anything it looks like a consistent use of parentheses with little
other arbitrary syntax makes it much easier for people to learn to
program in Scheme or Lisp than say in Pascal or C++. So this all
supports your point.

However, I should point out that I've programmed for 20+ years, and
tried Lisp a few times, even doing some small projects in it. Coming
back to it yet again from Python, Smalltalk, Delphi, and C++, I still
think that there might be some way the process of coding and reading
Lisp can be improved. But, of course, a lot of this is tradeoffs.

The fact that this is a perennial "newbie" lament does, in my opinion,
point to an inelegance of some aspect of the Lisp family of languages.
However, that is not to say this price is not worth paying for the other
advantages that Lisp family languages provide. People on this newsgroup
seem sure it is, and further add that the problem appears to go away in
time as one becomes more experienced with the system. I am just trying
to seek a solution that keeps the Lisp elegance and minimizes this very
real "newbie" issue.

Perhaps that is impossible, but people also said that of proving the
Fermat Conjecture ("Fermat's Last Theorem"). Of course, that work had to
be done in secret, less the mathematician involved risk his career. But
I was hoping to harness all the brainpower of this newsgroup to perhaps
improve the solution I proposed, or point out obvious technical flaws in
the concept.

> Python was/is a pedagogical tool, and it's decision to make syntax
> significant was based on that context. It was designed to teach new
> CS students better habits for the formatting of code, by making a
> standard formatting schema mandatory. Lisp already has
> pretty-printers and editor support for encourgaing good formatting
> habits.

I don't remember reading about the code formatting habit emphasis, but I
could believe it. Certainly after using Occam I used two spaces for
indentation when possible.



> Craig Brozefsky <cr...@red-bean.com>
> Lisp Web Dev List http://www.red-bean.com/lispweb
> --- The only good lisper is a coding lisper. ---

Thanks for the interesting comments.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations

Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Marie-Noëlle -

Thanks for the interesting comments and references.

Just to be clear though, I do want to keep all the advantages of Lisp.

I am looking for a way to do this while still removing what I as someone
coming back to Lisp from a long hiatus sees as some excess visual
clutter.

If anything, since I want to remove things, I'd certainly be against
personally using an Algol-like syntax if I'm programming in Lisp.

I think the Lisp syntax is elegant and powerful. I just want to see if
it can still work with less parentheses on the edges of lines.

In a way, along the lines of another post by Chris Page, it's really a
typographic convention I am proposing more than something fundamental.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com


Marie-Noëlle Baechler wrote:
>
> > - one of the points of the syntax of lisp is that it makes it very
> > easy to parse; since devices without keyboards probably also are
> > short on other ressources, increasing the complexity in central
> > components may be the wrong way to go.
>
> In addition, there has been myriads of Algol-like syntax implemented
> over a Lisp System. But none of these extensions did ever become
> popular. Even John MacCarthy mentions that S-Expressions were
> originally only intended for data and that program had to be written
> in a more algol-like syntax called M-expressions(*). But S-expressions
> were used from the beginning and they are still there.
>
> Lips syntax has other advantages beyond easy of parsing. It makes
> programs similar to data and reciprocally. With good macros, this
> gives a tremendous expressive power and I am not sure that it can
> be achieved with a more conventional system. Finally, Lisp makes
> it extremely easy to develop interpreters over an existing
> implementations. Even in the seventies, when he was testing the
> Actor model, Harold Abelson was developping and testing up to 10
> interpreters a week! (**) Once again, I doubt that such an expressive
> power can be achieved with a more conventional language.
>
> (*) John McCarthy
> History of Lisp
> Stanford university, 12 February 1979
>
> (**) Guy Steel Jr. & Richard P. Gabriel
> The Evolution of lisp
> ACM Sigplan Notices 28 3. (231-270), April 1993
>
> Both are available on-line
>
> Regards
>
> Marie-Noëlle Baechler

Erik Naggum

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
* David Bakhash <ca...@alum.mit.edu>

| Do you have code that parses this (minus any dot notation, which I
| also don't care too much for)?

The implicit "to share" has been noted. Most of my recent Lisp code
is under "trade secret" wraps as it's work for hire these days, so
I'm not as free to share as I once was.

| infix.lisp has some of the stuff I think one would need to implement
| this, but I don't think it's complete, and (sin x) is, as far as I
| know, expected to be sin(x) with infix.lisp. What you seem to have
| above is a bit hybrid.

Well, fully parenthesized prefix syntax is a lot easier to deal with
than the sort of hybrid prefix notation you find in infix, so
instead of inventing a language to describe hybrid prefix in infix,
I decided to use infix where it clearly worked well, and real prefix
where infix doesn't work at all, such as in function calls. Parens
retain their Lispness, while the mathematical parens are expressed
using brackets.

E.g., (foo (+ a b) (* c d)) becomes $ (foo [a + b] [c * d]) $.

Perhaps needless to say, this stuff has grown without prior design
to guide it and with much backward compatibility to hamper any
design, so given enough time, it would probably grow into C++.

Hartmann Schaffer

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
In article <39929AF6...@kurtz-fernhout.com>,
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
> ...
> But, I think in practice, when indentation is significant, people tend
> to always do formatting right away when cutting and pasting anything --
> so as to always maintain the logical structure of the program. So, I

true, but contrary to the delimited syntax the whitespace syntax does
rely on errorfree editing. in my experience (maybe it's just me, it
is quite easy to put the mark in the wrong place, leading to errors
that can be very hard to track down. with a delimited syntax you the
cutted and pasted code being transferred with its delimiters simply
doesn't raise this problem, and if you made a mistake when cutting
(leaving out or adding a delimiter) you most likely will get a syntax
error.

> don't see this being a big problem in practice, and in the Python or
> Occam case I don't remember ever experiencing such a problem (at least
> not down the road -- it may have been more of an issue at the start).

the problem with the white space syntax as i see it: provided the
delimiters in the delimited syntax aren't too verbous, it buys you
very little in typing effort (in emac's python mode you have to use an
extra keystroke to indicate that you want to revert the indentation to
the previous level (at least most of the time), but it removes
valuable redundancy what you have when you combine a delimited syntax
with a pretty printer, where the programming environment uses what you
typed to put the structure of your code on display. i actually would
argue that the whitespace syntax, rather than being helpful and save
the programmer some work transfers a much harder burden (to keep track
of the structure) to the programmer.

I find typing an extra parenthesis no more burdensome than to hit a
key to tell the editor to reverse the indentation. it might be a
little bit differend with very verbose delimiters (like mandatory 'end
keyword' etc)

--

Hartmann Schaffer


Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Russell-

Thanks for the comments.

I appreciate your opinions as someone who has tried both approaches.

You also raise a very good point about prefix vs. infix notation being
another stumbling block for people coming to Lisp from many Algol-like
languages. I personally feel prefix is OK if it gets you other things
(such as Lisp has). However, I should note that a language like
Smalltalk that merges postfix, infix, and keyword syntax (e.g.
"dictionary at: key put: value + 2 sin") does get by on less
parentheses, at a cost of course of not easily representing code and
data in the same format (plus other costs). And of course, Forth gets by
on no parentheses -- again at other costs.

Yes, I too think aesthetics plays a big role. We may have somewhat
different senses of aesthetics, but the world would be pretty boring if
we didn't.

Thanks for the comment on not seeing any big practical problems to
making it work. Thats a major interest o mine in posting. So far, while
I have a lot of good reasons why current experienced Lisp users wouldn't
want to use an identational syntax, I still haven't seen a concrete
example of where one can't represent a valid S-expresison with the sort
of indentational approach outlined.

Thanks again for the comments. I'll be curious as well to see your reply
if any to the question someone else asked regarding your switch to
Python for AI.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

> don't think those are the real issues. I've switched from Scheme to


> Python for AI/prototyping work for reasons of syntax, but it's not a
> question of the number of brackets required, or of putting the + sign
> before the operands rather than between them, and I think that's true
> for most Lisp-avoiders. So I don't think your proposal would actually
> help.
>

Paul Fernhout

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Thanks for the interesting post. Some comments below.

The Glauber wrote:
>
> The use of indentation to convey syntax is interesting and may lead to
> more readable code.

Hooray! :-)

> The reason i don't use Python anymore and i hope
> never to have to use this kind of language again is simple: even though
> my indentation is always correct and perfect :-), my colleagues are not
> as good as i am in choosing a system and sticking to it.

Interesting point.

Actually, I remember one student in a C programming class I taught who
had a BASIC background. He strongly believed at first he didn't need to
indent anything, and I remember watching him struggle in a lab to get a
couple pages of unindented C to work...

You can lead a horse to water, but you can't make 'em drink.

That's actually one thing I like about a language like Occam that
enforces consistent indentation. It's also a reason many other people
despise a language like Occam -- saying it takes away their freedom,
whereas I think it creates freedom on another level.

> This is complicated by the existence of editors that use tabs for
> indenting (like our old friend, vi), and people who will then change
> the meaning of the tab to whatever is their favorite prime number that
> day (3 spaces, 5 spaces, 7...).

Yes, tabs can really mess up an indentational system.

Python does struggle with this somewhat.

In practice I think this can be worked out, but it is annoying.

> If i have to work with some horribly indented piece of code written in
> C or Java, i can usually fix it either by hand or using a tool. It
> would be pretty exciting (in the bad way) if, by fixing the
> indentation, i would be introducing subtle syntax changes too.

It's been my experience that horribly indented code usually has other
horrible problems associated with it. That's not much comfort when you
have to work with a specific piece of code in a specific setting, but it
can be a rule of thumb for avoiding some problems if you get to choose
the code you work with.

It is true one can introduce bugs by messing up indentation, but I think
they are not likely to be "subtle" because one can see the program
structure by inspection. Obviously if we are talking about changing the
nesting of some delicate "if" statements, then that is a greater point
of failure, and the errors are more likely to be subtle. Still, there
are lots of subtle errors unusual indentation can hide in a language
with block delimiters -- be they parens, begin/end, braces, or whatever
else.
In practice, in a language with syntactically significant indentation,
it might be less likely one would ever need to fix up someone else's
indentation.

Ultimately, in any programming endeavor, there are areas where people
have to exercise caution. Obviously, for most programmers today,
whitespace has rarely been one of them.

> As for Lisp, the joy of Lisp is in the parens!

They certainly are elegant and consistent.

> Anyway, just my .02
>
> g
>
> --
> Glauber Ribeiro
> thegl...@my-deja.com http://www.myvehiclehistoryreport.com
> "Opinions stated are my own and not representative of Experian"
>

Thanks for the comments!

David Bakhash

unread,
Aug 10, 2000, 3:00:00 AM8/10/00
to
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:

> > As for Lisp, the joy of Lisp is in the parens!
>
> They certainly are elegant and consistent.

I think Paul is being too genial here. I think that the Joy of Lisp
comment was kinda silly. Sometimes you have to be cruel to be kind.
For example:

> > The reason i don't use Python anymore and i hope
> > never to have to use this kind of language again is simple: even though
> > my indentation is always correct and perfect :-), my colleagues are not
> > as good as i am in choosing a system and sticking to it.
>
> Interesting point.

C'mon now. This "point" makes no sense at all. So you had to abandon
Python not because it wasn't good enough for the task, or because you
didn't like it, but because your colleagues couldn't keep up with you?
Please don't tell me you switched [back] to Common Lisp. I would
hardly believe it. I also don't see what "this kind of language" is
referring to (i.e. what language feature?). If it is the indentation
thing, then what are you talking about when you say "choosing a
system"? Are you colleagues unable to figure out when to press the
<ENTER> key in Emacs? I'm trying to understand this, being that most
software development problems are so much harder than what your
colleagues were supposedly having difficulty with. Were you guys
writing "hello world" in different tongues?

Paul Foley

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to

Christopher Browne

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Centuries ago, Nostradamus foresaw a time when Paolo Amoroso would say:

>On Wed, 09 Aug 2000 00:37:23 -0400, Paul Fernhout
><pdfer...@kurtz-fernhout.com> wrote:
>
>> I'm interested in using significant indentation (like in Python)
>> http://www.python.org
>> to replace many parentheses in Lisp or Scheme programs.
>>
>> Has this been tried before? If so, what was the outcome?
>
>What was the outcome? Well, note that section 3.5.1 is a subsection of 3.5,
>which is titled "Some Notable Failures".

:-).

>> This example was taken from the LispMe (Lisp for the Palm) sample
>> code. http://www.lispme.de/lispme/
>[...]
>> One advantage to such an approach it that it might make it easier to
>> compose Lisp on devices without keyboards. An indent-line button and an
>> unindent-line button would be useful in that case.
>
>If you are a LispMe user, I suggest that you check the pedit family of
>shareware text editors:
>
> http://www.math.ohio-state.edu/~nevai/palm/

An unexpectedly remarkably useful link; thanks!

>> Significant indentation might make it easier for developers who don't
>> know Lisp well to understand a Lisp program's structure.
>
>Lisp developers already rely on indentation to understand a Lisp program's
>structure. Although indentation is not enforced by Lisp systems, it is
>sufficiently well standardized.

Parentheses _imply_ the appropriate indentation, and while enforcement
is nonexistant particularly when code might be generated by macros,
with the result that there's no text, and thus no notion of
indentation.

>> It might also allow experiences Lisp developers to read programs faster
>> because there is less high frequency "noise" in the text. Every
>
>As someone else pointed out in this thread, parentheses "disappear".
>Parentheses are simply not an issue for experienced programmers, and at
>times even for novices.

A pretty valid parallel is that in Python, the "strangeness" of using
indentation to indicate block structure _also_ disappears with use.

>> Such code will be faster to create. There is less typing, and no worry
>> about unbalanced parentheses. Indentation might be incorrect, but then
>
>LispMe provides some support for saving typing. If you type a form in the
>input field (more or less the equivalent of a listener's prompt), you can
>omit all the final parentheses.

You can? Cool!
>> Making indentation significant works for Python.
>> Why not make it work for Lisp too?
>
>Hint: parentheses-based syntax works for Lisp; why not make it work
>for Python too?

I think this would be a _tremendously_ interesting option.

Norvig <http://www.norvig.com/python-lisp.html> describes Python thus:

``Basically, Python can be seen as a dialect of Lisp with
"traditional" syntax (what Lisp people call "infix" syntax). One
message on comp.lang.python said "I never understood why LISP was
a good idea until I started playing with python." Python supports
all of Lisp's essential features except macros, and you don't miss
macros all that much because it does have eval, and operator
overloading, so you can create custom languages that way.
(Although it wasn't my intent, Python programers have told me this
page has helped them learn Lisp.)''

Sticking Python code into "lists," as an alternative notation, would
introduce the possibility of doing macros _well_, as well as providing
a completely unambiguous way of transferring code betwixt places.
--
(concatenate 'string "cbbrowne" "@" "acm.org")
<http://www.ntlug.org/~cbbrowne/linux.html>
"Cars move huge weights at high speeds by controlling violent
explosions many times a second. ...car analogies are always fatal..."
-- <west...@my-dejanews.com>

Christopher Browne

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Centuries ago, Nostradamus foresaw a time when Paul Fernhout would say:
>Chris-
>
>Wow! What a great post!
>
>This is a much more sophisticated idea than what I propose.
>Thanks for sharing it.

>
>-Paul Fernhout
>Kurtz-Fernhout Software
>=========================================================
>Developers of custom software and educational simulations
>Creators of the Garden with Insight(TM) garden simulator
>http://www.kurtz-fernhout.com
>
>Chris Page wrote:
>>
>> It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
>> To a great extent, it is. Most programming languages have a lot in common.
>>
>> In any case, it is my primary belief that the whole issue of syntax is a red
>> herring. Programming should be a high-level, automated process in which the
>> syntax of the language is largely of no concern to the programmer.

>>
>> Programmers should edit "programs" not "text files". How programs are
>> displayed to programmers should be a flexible and dynamic affair. There are

>> already a lot of editors with auto-formatting, and dedicated
>> "pretty-printers" for static code presentation -- and the kinds of things
>> they do should certainly be a part of what I'm suggesting. However,
>> programming tools should move beyond mere indentation, bracket matching,
>> coloring and highlighting.
>>
>> A great book on the topic of improved code presentation is:

>>
>> Human Factors and Typography for More Readable Programs
>> Ronald M. Baecker & Aaron Marcus
>> ACM Press
>> ISBN 0-201-10745-7
>>
>> One simple idea from that book is that C braces are almost completely
>> unnecessary if the indentation is correct. Eliminating them improves the
>> readability of C, at least. And thus dies the age-old question: Where do you
>> put the opening brace?
>>
>> These ideas for presentation should then be integrated into the editing
>> process. Using the above example, not only are braces unnecessary in the

>> presentation, they do not need to be typed by programmers. Instead, a
>> programmer could place the insertion point somewhere in the code, and create
>> a "for" statement. They would not type all the other text or punctuation;
>> the parenthesis, the semicolons, the braces, the white space. The insertion
>> point would be placed at the first appropriate spot for adding more code,
>> and moving the insertion point would skip across the punctuation to the
>> empty statements where code may be entered. Syntax-related coding errors no
>> longer exist.
>>
>> Of course there are editors that do some of these kinds of things, but they
>> are still manipulators of raw, plain text. They usually aren't capable of

>> automating editing tasks that require deeper knowledge about the language or
>> the particular program being edited (e.g. they don't know about definitions
>> or macros).
>>
>> I think the future holds a programming experience where syntax is fluid --
>> perhaps even changing moment by moment to present programs in a way best
>> suited for what the programmer is doing at that time -- and programs are
>> manipulated in terms of their semantic objects at a far quicker pace and
>> with less errors than at present.
>>
>> Think I'm blue-skying? Just wait. Or better yet, start working on making it
>> a reality.
>>
>> P.S. When you have an editor that manipulates code rather than text, then it
>> also becomes possible to instantly recompile code as it is changed, because
>> the compiler's workload is dramatically reduced. There are a number of

>> wonderful implications, including some that have nothing to do with the
>> compiler (e.g. revision control can operate at a higher level of
>> abstraction).
>>
>> P.P.S. Languages like Dylan, Lisp, and Smalltalk can be edited and compiled
>> one definition at a time, so they're ahead of the game. The semantics of
>> C/C++ compilation units make it more difficult (and occasionally impossible)
>> to minimize the amount of code that must be recompiled when something as
>> trivial as a comment is changed.

The last book I browsed [and quickly discarded as pointless to buy, as
compared to the _very good_ O'Reilly book I just got on OCAML] was the
Addison Wesley book,
_Generative Programming: Methods, Tools, and Applications_
<http://www.awl.com/product/0,2627,0201309777,00.html>

It's an interesting book, at some levels. Frightening at others.
Remarkably _NON_concrete throughout.

Basic idea is that it looks at a number of "somewhat-beyond-OO"
techniques for metaprogramming, notably including:
- Domain Engineering [which seems to be a whole lot of "design
blathering"]
- Feature modeling [also "design blather"]
- Generic programming
- Component-based C++ templates [start saying "ick" now...]
- Aspect Oriented Decomposition
[This is the Xerox thing where they suggest building language
tools to support generating "coupling" code so that, for instance,
synchronization management might be managed by the "coupler"
rather than you having to manage the bird-droppings of synch code
throughout the code base...]
- Code generators
- Microsoft's Intentional Programming
<http://www.research.microsoft.com/ip/>

[Aside: It seems to me that On Lisp addresses all but AOP in a
_CONCRETE_ manner, with clear code samples...]

The last item, Intentional Programming, is the either-very-smart-
or-really-scary bit, which certainly parallels what Chris Page is
talking about.

<http://www.research.microsoft.com/ip/NewsMove.htm>

"IP, one of the first projects started at Microsoft Research, set
out on an ambitious goal to change program representation from the
traditional text stream and syntax to a database (the "IP tree"),
which is not about the program, but which represents the program
itself."

What MSFT seems to be trying to do [making up product names as needed]
is to build a "kinder, gentler" _Visual C++ 2001_. Screen shots of
some sort of "intentional" C++ editor _are_ shown in the book.

There are likely to be patents forthcoming, and it might be wise for
those with existing Lisp-related "IP-like" functionality to watch to
see if there be infringements on this.

Now, with C++, the complexity of the language syntax means that
either:

a) They'll be creating a new language that's not _really_ C++ that the
IP tool works with, or

b) The IP tool will integrate absolutely frightening amounts of
"parser stuff,"

[or both!]

All this stuff considered [to some extent!], I'm skeptical that the
"code as trees" idea will go _terribly_ far towards eliminating "code
as text" any time soon.

Treating code as text allows deploying all sorts of "perhaps
less-intelligent, but easier to write and make generic" text-based
tools to manage code.

And if the code is _only_ available as a tree, then you're left saying
"What will Microsoft's Code Editor Allow Me To Do Today?" [Substitute
other things for "Microsoft" as needed.]

Tree-oriented editors haven't taken off elsewhere; people tend to edit
HTML using text editors rather than using Amaya, which is
tree-oriented.

Text is just plain more flexible.

- Give me tools that make it easy to mess with text.

- Give me "syntax-oriented" tools like Emacs "electric" modes or HTML
manipulators like Dave Raggett's HTML tidy, or sgmlnorm, or C
indent, that can help clean up whatever gets "messed."

That seems to me to be more likely to cope well with code than having
to have a [perhaps rather fragile] "tree-oriented environment."

[Obvious retorts back include "How about Smalltalk, which has no
files? How about Lisp Machines that had no files?" Therein may lie
the interesting answers...]
--
(concatenate 'string "aa454" "@" "freenet.carleton.ca")
<http://www.hex.net/~cbbrowne/lisp.html>
"90% of the ideas people bring to me are no good. So if I reject all
of them I've got a pretty good batting average" -- Sam Goldwyn (MGM)

Christopher Browne

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Centuries ago, Nostradamus foresaw a time when Tom Breton would say:

>Chris Page <pa...@best.NOSPAM.com> writes:
>
>>
>> I think the future holds a programming experience where syntax is fluid --
>> perhaps even changing moment by moment to present programs in a way best
>> suited for what the programmer is doing at that time -- and programs are
>> manipulated in terms of their semantic objects at a far quicker pace and
>> with less errors than at present.
>>
>> Think I'm blue-skying? Just wait. Or better yet, start working on making it
>> a reality.
>
>People have been saying that for decades, and programmers still
>relentlessly keep dealing with text source. Of course, they also
>still use C and its children too...

"Snappy comebacks" would be to look at the programming environment
that commonly don't use files.

Notable examples would be:
a) Smalltalk
b) Some of the Lisp Machines

Vaporware examples people are playing with include:
c) The EROS operating system
d) Some of the attempts at "LispOSes" (see URL below)


--
(concatenate 'string "aa454" "@" "freenet.carleton.ca")

<http://www.hex.net/~cbbrowne/lisposes.html>
"That's convenience, not cracker-proofing. Security is an emergent
property, not a feature." -- void <fl...@interport.net>

felix

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to

Erik Naggum wrote in message <31748950...@naggum.net>...

> In scheme, (if 1 2 3) and (if 1 2 . (3)) are identical as data, but
> as code, they are different. [I think this is completely idiotic.]

Microsoft(R) Windows 98 [<-- any
comments?]
(C)Copyright Microsoft Corp 1981-1998.

C:\work>mzscheme
Welcome to MzScheme version 101, Copyright (c) 1995-99 PLT (Matthew Flatt)


> (if 1 2 . (3))

2
> (if #f 2 . (3))
3

C:\Stuff\scheme48>scheme48vm
Welcome to Scheme 48 0.53 (suspended image).
Copyright (c) 1993-1999 by Richard Kelsey and Jonathan Rees.
Please report bugs to scheme-...@martigny.ai.mit.edu.
Type ,? (comma question-mark) for help.
> (if #f 2 . (3))
3


(Hm, this doesn't look too bad)

In another posting you wrote:

> ... Hell, they [the ones from the Scheme camp] don't even believe in
> compile-time manipulation of the code...

Now, please, how exactly do you come to that conclusion?
(I expect you know about macros in Scheme, but perhaps I
have to alter my expectations)


felix


Aaron Crane

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
In article <3992235B...@kurtz-fernhout.com>,
Paul Fernhout <pdfer...@kurtz-fernhout.com> writes:
> I think, for example, this:
>
> define (foo x)
> * x x
>
> is less intimidating than this:
>
> (define (foo x)
> (* x x))
>
> for someone not used to dealing with lots of parentheses.

I think someone who isn't used to dealing with lots of parentheses has
insufficient experience to be able to pass judgment on whether Lisp is worth
investigating further. And someone who _is_ used to dealing with lots of
parentheses is unlikely to notice that they are there -- as many Lisp
programmers report. It seems misguided at best to optimise for novices,
especially for a programming language: one hopes and expects that people
remain novices for only a vanishingly small fraction of their lives as a
programmer.

> Meaningful hierarchical indentation is often encountered outside of
> programming. People use it all the time to make outlines. People write
> pseudo-code using meaningful indentation.

Precisely. This is one of the complaints I have with the way Python does
things. I've heard Python programmers saying that Python syntax is
`parsable pseudo-code' or some such -- but none seem to realise just how bad
an idea that is. The point about pseudo-code is that it's a helpful,
abstract notation _for_humans_. Pseudo-code isn't given to compilers to
deal with. It isn't read and stored as data. It isn't passed around via
lossy communication channels which have problems with whitespace. Most
importantly, though, it tends to be written once, and deleted once finished
with. This means that certain of its properties (that it can be hard to
parse unambiguously, that its textual representation is far from robust, and
so on) aren't a problem. However, when you use such notations for real
code, these things can make you lose big.

--
Aaron Crane <aaron...@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **

Christopher Browne

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Centuries ago, Nostradamus foresaw a time when felix would say:

>Erik Naggum wrote in message <31748950...@naggum.net>...
>In another posting you wrote:
>
>> ... Hell, they [the ones from the Scheme camp] don't even believe in
>> compile-time manipulation of the code...
>
>Now, please, how exactly do you come to that conclusion?
>(I expect you know about macros in Scheme, but perhaps I
>have to alter my expectations)

A legitimate problem is that there's not a single scheme for
handling macros, but rather two or three, most of which are
somewhat less powerful than CL macros.
--
aa...@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/linux.html>
"If you were plowing a field, which would you rather use? Two strong
oxen or 1024 chickens?" -- Seymour Cray

Robert Monfera

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Chris Page wrote:

> I think the future holds a programming experience where [...] programs are


> manipulated in terms of their semantic objects at a far quicker pace and
> with less errors than at present.
>
> Think I'm blue-skying? Just wait. Or better yet, start working on making it
> a reality.

You are predicting the past :-) I think it used to be a reality for
various programming environments. For example, there was a recent
thread about structure editors and the Interlisp environment. There
were some discussions about the merit of object-based versus text-based
editing.

> P.S. When you have an editor that manipulates code rather than text, then it
> also becomes possible to instantly recompile code as it is changed,

It can be done both ways. The question is: do you _always_ want to have
a function recompiled? Maybe you make a dozen modification steps - do
you want a dozen recompliation? Do you want instant recompilation when
you would rather want to recompile several functions in one
_transaction_ - for example to preserve metastability?

If anything, I'd like an editor that can manipulate definitions beyond
the boundaries of stone-age file concepts (e.g., seeing all methods of a
GF on the screen, or seeing all business logic code, or seeing all code
related to a class). I hear Dylan's editor is like this.

An indicator for each declaration would also not hurt. It could have
one of the following states:
- currently active
- changed, not yet compiled (i.e., obsolete)
- removed from image (undefined)

Another area to improve is macros. Currently the only safe thing to do
after macro redefinition is to recompile all files that possibly use the
macro.

What surprised me is that some popular Lisp environments don't even have
an "undefine" function for methods (something like fmakunbound, with an
extended function name containing argument specializations). A GF
browser would also be helpful.

The bright side is that any of the enhancements above can be implemented
by users with moderate effort in Lisp itself.

Robert

Russell Wallace

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
David Bakhash wrote:

>
> Russell Wallace <rwal...@esatclear.ie> writes:
>
> > I've switched from Scheme to Python for AI/prototyping work for
> > reasons of syntax, but it's not a question of the number of brackets
> > required, or of putting the + sign before the operands rather than
> > between them, and I think that's true for most Lisp-avoiders. So I
> > don't think your proposal would actually help.
>
> You are not the first AI person I've heard of moving from some Lisp to
> Python. I'd be first inclined to wonder why you didn't convert to CL
> instead. But, guessing that you considered, and probably tried CL,
> can you elaborate on why Python over Scheme, or (better) of CL? It's
> about time I asked. I looked over Python, though didn't dive into
> it. I hated it right away, at least for AI-related applications.

For Scheme vs. CL - well, I liked Scheme's simplicity and elegance, for
prototyping work, though if I were writing commercial, production code
in any Lisp family language I'd use CL for its industrial-strength
features.

My reason for switching to Python over either for AI stuff, though, is
pretty much entirely a matter of syntax. Specifically:

1) Algol-phylum languages use different syntactic forms for the various
common operations, whereas Lisp relies almost entirely on parentheses
and indentation. I find the result is I can see the structure of code
written in an Algol language at a glance, whereas with Lisp I have to
nearly read it line by line.

2) Algol languages have concise syntax for common operations, with the
result that I find it much easier to write and (more importantly) read
and modify code. Compare

foo.bar += a[i][j] * abc.xyz;

with the Lisp equivalent.

Lisp's main practical strength as I see it is higher-order programming
(including macros), code that writes code etc (for which of course its
syntax is helpful). Looking back over what I was doing, though, I found
I wasn't really using that stuff except for just passing function
references around, which can be done in any reasonably powerful
language, so I didn't have any reason to switch.

I would conjecture, admittedly without proof, that the above factors are
important for most of those who've seen Lisp but avoid it, even if they
don't articulate them.

Russell Wallace

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Paul Fernhout wrote:
>
> Russell-
>
> Thanks for the comments.
>
> I appreciate your opinions as someone who has tried both approaches.
>
> You also raise a very good point about prefix vs. infix notation being
> another stumbling block for people coming to Lisp from many Algol-like
> languages. I personally feel prefix is OK if it gets you other things
> (such as Lisp has). However, I should note that a language like
> Smalltalk that merges postfix, infix, and keyword syntax (e.g.
> "dictionary at: key put: value + 2 sin") does get by on less
> parentheses, at a cost of course of not easily representing code and
> data in the same format (plus other costs). And of course, Forth gets by
> on no parentheses -- again at other costs.

Yep! I've played around with both of them a little bit - they're each
wonderfully elegant in their own way, though I must admit at the end of
the day I prefer the Algol phylum syntax for actually getting code
written.

> Yes, I too think aesthetics plays a big role. We may have somewhat
> different senses of aesthetics, but the world would be pretty boring if
> we didn't.

This is true :)

> Thanks for the comment on not seeing any big practical problems to
> making it work. Thats a major interest o mine in posting. So far, while
> I have a lot of good reasons why current experienced Lisp users wouldn't
> want to use an identational syntax, I still haven't seen a concrete
> example of where one can't represent a valid S-expresison with the sort
> of indentational approach outlined.

I'm pretty sure it would work. I think it's important to make it easy
to flip back and forth between the two views of a particular source
file, so fans of one don't break out the voodoo dolls when faced with
the other :) Either an add-on for Emacs or a pair of filter programs
I'd say would do the job nicely.

> Thanks again for the comments.

Welcome!

Christopher Browne

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Centuries ago, Nostradamus foresaw a time when Russell Wallace would say:

>2) Algol languages have concise syntax for common operations, with the
>result that I find it much easier to write and (more importantly) read
>and modify code. Compare
>
> foo.bar += a[i][j] * abc.xyz;
>
>with the Lisp equivalent.

Hmm.
(incf foo-bar (* (aref a i j) abc-xyz))
does not look _so_ awful.
--
cbbr...@ntlug.org - <http://www.hex.net/~cbbrowne/linux.html>
Rules of the Evil Overlord #138. "The passageways to and within my
domain will be well-lit with fluorescent lighting. Regrettably, the
spooky atmosphere will be lost, but my security patrols will be more
effective." <http://www.eviloverlord.com/>

Robert Monfera

unread,
Aug 11, 2000, 3:00:00 AM8/11/00
to
Russell Wallace wrote:

> Compare
>
> foo.bar += a[i][j] * abc.xyz;
>
> with the Lisp equivalent.

(incf (foo bar) (* (aref a i j)
(abc xyz)))


Compare

(incf (foo bar baz) (* (aref a i j)
(abc xyz qwe)))

with the Python equivalent .

...oops, no multimethods...

Robert

It is loading more messages.
0 new messages