RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
David Bakhash
> 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
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
> 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
> 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
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
<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
> 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
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
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
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
> 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
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
<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
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
> 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
<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
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
> 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
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
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
<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
> 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
<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
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
>
> ======= 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
>
> 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
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
> 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
> - 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
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
| 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
| 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
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 j