From: Paul Fernhout
Subject: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3990E003.6EE78131@kurtz-fernhout.com>
I'm interested in using significant indentation (like in Python)
  http://www.python.org 
to replace many parentheses in Lisp or Scheme programs.
 
Has this been tried before? If so, what was the outcome?

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

For example, how about:

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

Instead of:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Example:

  (+ 1 2)

becomes:

  + 1 2 

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

Example: 

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

becomes:

  + (* 3 4)
    / 2 3

or:

  + 
    * 3 4
    / 2 3

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

  + (* 3 
  4) (/ 2 3)

This conversion is also legal, but also advised against:

  + (* 3 
  4) 
    / 2 3

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

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

Example:

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

can become:

  + 
    1 
    / 2 3 
    f 
    (my-function)

It can also be represented as the equally valid:

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

Or as one of several hybrids:

  + 1 
    / 2 3 
    f 
    (my-function)

Or:

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

Or:

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

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

Example:

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

could become:

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

Or it could become:

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

Or it could become:

  let 
    ...
      x 10
      y 20 
    * x y

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

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

For example: 
  
  (+ 1 2)

can become:

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

  ... + 1 2


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

Example:

  let 
    ...
      x 10

      y 20
 
    * x y

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

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

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

Example taken from the modified "doodle" example above: 

  (menu) (frm-return 'bye)

could become:

  (menu) 
    frm-return 'bye

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

Or consider another fragment from a modified "doodle":

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

can be thought of as:

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

and then could be fully de-parenthesized as:

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

Note that this re-parenthesizes back to Scheme as:

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

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

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

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

For example:

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

could become:

  cons 
    '(a b) 
    '(c d)

Although of course this could also be:

  cons 
    quote
      a b 
    quote
      c d

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

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

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

  +
     (+ 1 2)
     + 3 4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here are some simple examples:

  (+ 1 2)

becomes:

  + 1 2

or:

  +
    1
    2

A slightly more complex example (in Scheme):

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

can become:

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

Or, alternatively, using more indentation to denote sublists:

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

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

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

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

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

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

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

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the GPL'd Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <m3zomnkyir.fsf@cadet.dsl.speakeasy.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

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

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

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

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

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

Paul Fernhout <··········@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
From: Michael Hudson
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <m3wvhqq55y.fsf@atrus.jesus.cam.ac.uk>
David Bakhash <·····@alum.mit.edu> writes:

> Paul Fernhout <··········@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
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <3174843003803441@naggum.net>
* Michael Hudson <·····@cam.ac.uk>
| From an experienced Pythoneer: don't knock what you don't know.

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

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

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

  Some people just prove that human procreation is too cheap.

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

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Hartmann Schaffer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <39920f27@news.sentex.net>
In article <················@naggum.net>,
	Erik Naggum <····@naggum.net> writes:
> ...
>   The reason _I_ don't like Python's significant whitespace is that I
>   don't want to keep doing indentation by hand.  I'm sure it looks

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

> ...

-- 

Hartmann Schaffer
From: Marco Antoniotti
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <y6csnro6qth.fsf@octagon.mrl.nyu.edu>
··@inferno.nirvananet (Hartmann Schaffer) writes:

> In article <················@naggum.net>,
> 	Erik Naggum <····@naggum.net> writes:
> > ...
> >   The reason _I_ don't like Python's significant whitespace is that I
> >   don't want to keep doing indentation by hand.  I'm sure it looks
> 
> maybe we have different ideas what indentation by hand means, but imo
> with emac's python mode you don't have to

Emacs has indented (Any) Lisp code for a much longer time than
Python.  And it has always doe a pretty good job at it.

Cheers

-- 
Marco Antoniotti =============================================================
NYU Bioinformatics Group			 tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                          fax  +1 - 212 - 995 4122
New York, NY 10003, USA				 http://galt.mrl.nyu.edu/valis
From: Michael Hudson
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <m3lmy5polv.fsf@atrus.jesus.cam.ac.uk>
Erik Naggum <····@naggum.net> writes:

> * Michael Hudson <·····@cam.ac.uk>
> | From an experienced Pythoneer: don't knock what you don't know.
> 
>   Let's keep this sage advice in mind for just a few seconds.
> 
> | Have you actually found it's dependence on whitespace a problem
> | (other than the "ooh this is different therefore it's bad" response)?
> 
>   Why are you so unfathomably stupid as to think it's OK for _you_ to
>   knock what you don't know right after you've told others not to?
>   How the hell did you come up with the _chutzpah_ required to write
>   such an obvious attack based on your own ignorance of how others
>   reacted to Python's significant whitespace?

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

>   Some people just prove that human procreation is too cheap.
> 
>   The reason _I_ don't like Python's significant whitespace is that I
>   don't want to keep doing indentation by hand.  

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

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

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

Cheers,
M.

-- 
  I'm not particularly fond of singing GSTQ because she stands for
  some things I don't, but it's not really worth letting politics
  getting in the way of a good bawling.
                                            -- Dan Sheppard, ucam.chat
From: Hartmann Schaffer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <39920e2a@news.sentex.net>
In article <··············@atrus.jesus.cam.ac.uk>,
	Michael Hudson <·····@cam.ac.uk> writes:
> David Bakhash <·····@alum.mit.edu> writes:
> 
>> Paul Fernhout <··········@kurtz-fernhout.com> writes:
>> 
>> > I'm interested in using significant indentation (like in Python)
>> >   http://www.python.org 
>> > to replace many parentheses in Lisp or Scheme programs.
>> >  
>> > Has this been tried before? If so, what was the outcome?
>> 
>> I don't know how to respond to this post, and please, don't take
>> offense at anything I say.
>> 
>> The idea of using whitespace to alter the meaning of code is absurd.
>> I don't know how python continues to exist in its current state.
> 
> From an experienced Pythoneer: don't knock what you don't know.
> Please.  Have actually programmed in Python?  Have you actually found
> it's dependence on whitespace a problem (other than the "ooh this is
> different therefore it's bad" response)?  With a half-decent editor
> you really shouldn't have any difficulties (hmm, now where have I
> heard that defense before...?).

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

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

-- 

Hartmann Schaffer
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <m3wvhqlpng.fsf@cadet.dsl.speakeasy.net>
Michael Hudson <·····@cam.ac.uk> writes:

> David Bakhash <·····@alum.mit.edu> writes:
> 
> > Paul Fernhout <··········@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
From: Christian Lynbech
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <ofhf8u50vh.fsf@chl.tbit.dk>
I haven't read through all of your proposal, but a few things spring to
mind.

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

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

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

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

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

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


---------------------------+--------------------------------------------------
Christian Lynbech          | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J  
Fax:   +45 8675 6881       | email: ···@ericssontelebit.com
Phone: +45 8675 6828       | web:   www.ericssontelebit.com
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - ·······@hal.com (Michael A. Petonic)
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant   indentation?
Date: 
Message-ID: <399162BC.83ABDE69@kurtz-fernhout.com>
Christian-

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

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

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

Yes, indentational parsing may burn more CPU cycles, and so take perhaps
take longer and use up the battery more quickly. I don't have any
figures to see how much of a hit this will be. I would expect it
wouldn't be that bad compared to everything else going on during
parsing.
 
> - devices withput keyboards typically also have very small
>   screens. Using whitespace rather than syntactic markers would spread
>   the code out more (geometrically speaking) and that may lose you
>   more than gained.

Yes, and no. 

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

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

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

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

to:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Since some interactive environments let you enter code and then select
and evaluate it by highlighting it and pressing some command key
sequence, in that case no extra blank line needs to be typed, because
the end of the highlighted section indicates the end of the snippet.
 
> 
> One such example is the Scheme Shell, which tries to go some way in
> order to remove some of the parentheses. An URL is:
> 
>         http://www.swiss.ai.mit.edu/ftpdir/scsh/

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

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

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

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

would be written in scsh as 

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

And in indentational syntax as:

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

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

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

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

Realistically, which would you rather type on the fly?

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

---------------------------+--------------------------------------------------
> Christian Lynbech          | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J  
> Fax:   +45 8675 6881       | email: ···@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
From: thi
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant   indentation?
Date: 
Message-ID: <y16snsenyc5.fsf@glug.org>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

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

thi
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <3991B8E4.B8CE44A2@kurtz-fernhout.com>
Thanks for the comments. Some elaborations below.

thi wrote:
> 
> Paul Fernhout <··········@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.

-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
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <8qmSOenQcmmI9HeP2wzlM4L1FFn+@4ax.com>
On Wed, 09 Aug 2000 16:02:44 -0400, Paul Fernhout
<··········@kurtz-fernhout.com> wrote:

> On a tangent, could it be that the reason for a lot of cut and paste in
> Lisp is precisely because it is so hard to get all those parentheses

Could you elaborate on this? From which sources did you get the impression
that cut and paste is common in Lisp (no pun intended), or possibly more
common than in other languages?


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant   indentation?
Date: 
Message-ID: <399327F7.D0F9865E@kurtz-fernhout.com>
Paolo-

Mostly that impression is from comments on this newsgroup to this
posting. The possibility that an indentational syntax might make cut and
paste more difficult seems to be a source of strong objections to an
indentationally significant syntax (not that there aren't others).

I have no other evidence that Lisp developers cut and paste any more
than other language developers. If anything, I would expect Lisp
developers to cut and paste much less than usual. This is because of the
Lisp tradition of abstraction -- which Lisp lends itself to so easily.
Since it is so easy to write a function in Lisp (no prototyping is
needed for example unlike C), Lisp makes it easy for the developer to
build software from lots of little functions. (Whether these functions
are reusable easily in other applications is another story...)

It was only when I thought about the reason why cut and paste seemed so
important to some posters that I realized that some Lisp developers may
be cutting and pasting generic structures in Lisp (by copying from an
example with the same structure), and then by hand changing the symbols
to suit the current situation. 

If this were true (and I don't know that it is, I'm just guessing) it
might prove a useful observation leading to creating a new Lisp tool,
perhaps combining a library of typical structures and a
fill-in-the-blanks sort of instantiation process, along with some easy
way to search for the right sort of structure to start with.

Thanks for the interesting question.

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

Paolo Amoroso wrote:
> 
> On Wed, 09 Aug 2000 16:02:44 -0400, Paul Fernhout
> <··········@kurtz-fernhout.com> wrote:
> 
> > On a tangent, could it be that the reason for a lot of cut and paste in
> > Lisp is precisely because it is so hard to get all those parentheses
> 
> Could you elaborate on this? From which sources did you get the impression
> that cut and paste is common in Lisp (no pun intended), or possibly more
> common than in other languages?
> 
> Paolo
> --
> EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
> http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like      significant   indentation?
Date: 
Message-ID: <sfwg0obr9di.fsf@world.std.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Mostly that impression is from comments on this newsgroup to this
> posting. The possibility that an indentational syntax might make cut and
> paste more difficult seems to be a source of strong objections to an
> indentationally significant syntax (not that there aren't others).

I use "cut and paste" (per se) very little in Lisp code.  That is, I rarely
specify a region by start and end and then use Emacs control-w (kill region).
Instead, I tend to use Emacs control-meta-k (kill-sexp) which knows how to
pick up a Lisp expression to be moved elsewhere.  The advantage here is being
able to point at a single end of an expression and have the other end of the
expression unambiguously known.

Consider, by contrast, infix languages where you have a situation like:

  a*b+c
  ^

with the cursor at the indicated point and you want to grab the expression
after the cursor.  You can't.  You don't know if "the expression" is a,
a*b, or a*b+c because the situation is ambiguous.  In Lisp, the presence of
parens means that
  (+ (* a b) c)
  ^
is distinguished from
  (+ (* a b) c)
     ^
is distinguished from
  (+ (* a b) c)
        ^

In each case, the cursor position unambiguously identifies a "next expression"
so there is always a place to point to for each expression which designates
both ends of an expression to be grabbed.

I suspect when Lispers get all excited about cut-and-paste being destroyed,
they are specifically talking about the loss of understanding of balanced
components... certainly that's my immediate concern.

My concern would also be about subtleties like:
 (setq x f)
vs
 (setq x (f))
Were I to replace parens with indentation, it's not obvious to me how to 
easily distinguish these two items.  Do I add "a little extra" identation
for the second?  That would be awful.

The problem I have with all of this discussion is that it appears to be solving
a non-problem.  I like Lisp syntax and don't find any problem with it at all.
It's not like other language syntaxes, so takes a little explaining for people
who are used to another, but it's otherwise quite natural and extremely 
powerful in terms of textually manipulating grouped expressions, which is
what people do a lot of.  If there's a problem there, I just don't see it.
And so I don't see solving it.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like       significant   indentation?
Date: 
Message-ID: <39946CC5.625D5789@kurtz-fernhout.com>
Kent-

Thanks for the great post. Some comments below.

Kent M Pitman wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > Mostly that impression is from comments on this newsgroup to this
> > posting. The possibility that an indentational syntax might make cut and
> > paste more difficult seems to be a source of strong objections to an
> > indentationally significant syntax (not that there aren't others).
> 
> I use "cut and paste" (per se) very little in Lisp code.  That is, I rarely
> specify a region by start and end and then use Emacs control-w (kill region).
> Instead, I tend to use Emacs control-meta-k (kill-sexp) which knows how to
> pick up a Lisp expression to be moved elsewhere.  The advantage here is being
> able to point at a single end of an expression and have the other end of the
> expression unambiguously known.

Good point.

> Consider, by contrast, infix languages where you have a situation like:
> 
>   a*b+c
>   ^
> 
> with the cursor at the indicated point and you want to grab the expression
> after the cursor.  You can't.  You don't know if "the expression" is a,
> a*b, or a*b+c because the situation is ambiguous.  In Lisp, the presence of
> parens means that
>   (+ (* a b) c)
>   ^
> is distinguished from
>   (+ (* a b) c)
>      ^
> is distinguished from
>   (+ (* a b) c)
>         ^
> 
> In each case, the cursor position unambiguously identifies a "next expression"
> so there is always a place to point to for each expression which designates
> both ends of an expression to be grabbed.

This is a fantastic example. I learned a lot from it. I had never though
about the limitations of infix notation in this way before. Wow. Thanks!

To translate your example using indentational syntax (pardon the extra
blank lines to fit the caret in -- though they are permissible in the
indentational syntax):

    +
   ^
      * a b

      c

is distinguished from:

    +

      * a b
     ^
      c

is distinguished from:

    +

      * a b

      c
     ^

The way to think about this is that every line in indentational syntax
represents the start of an S-expression. So, moving to the start of an
S-expression in indentational syntax is as simple as moving the cursor
to the beginning of a line. Selecting an entire S-expression is as
simple as selecting the line you are on and all the lines below that are
indented more than the current line (up to the first line indented equal
to or less than the current line).

> I suspect when Lispers get all excited about cut-and-paste being destroyed,
> they are specifically talking about the loss of understanding of balanced
> components... certainly that's my immediate concern.

Good point. Hopefully the above helps address some of those concerns. 

> My concern would also be about subtleties like:
>  (setq x f)
> vs
>  (setq x (f))
> Were I to replace parens with indentation, it's not obvious to me how to
> easily distinguish these two items.  Do I add "a little extra" identation
> for the second?  That would be awful.

Well, I admit that getting something like this correct is always an
issue. But let me give this a try:

For example:

  (setq x f)

can be represented indentationally (using the five rules) as:

  setq x f

or:

  setq x
    f

or:

  setq
    x
    f

Of these three, in this case the first would probably be clearest.
Indented items can just be thought of as being added onto the end of the
parent list. If indented items have more than one item, they are treated
as a sublist.

For your other example:

  (setq x (f))

can be represented as:

  setq x (f)

or:

  setq x
    (f)

or:

  setq 
    x
    (f)

This is a special case (rule 3) where a single item on a line without
parentheses is treated as a single item, not a list. So, it needs
parentheses. 

As an alternative, using "..." to indicate the start of a list, one
could also represent "(setq x (f))" as:

  setq x
    ... f

or:

  setq x
    ...
      f

or: 

  setq 
    x
    ... f

or:

  setq 
    x
    ...
      f

Wow. I hadn't realized at first that there were seven ways to indent
that expression that all are equivalent! For this specific case, of all
the possibilities:

  setq x (f)

seems the obvious choice (because it  is simplest and has the least
lines).

So to recap, what you present could be translated as:

  setq x f

versus:

  setq x (f)

> The problem I have with all of this discussion is that it appears to be solving
> a non-problem. I like Lisp syntax and don't find any problem with it at all.
> It's not like other language syntaxes, so takes a little explaining for people
> who are used to another, but it's otherwise quite natural and extremely
> powerful in terms of textually manipulating grouped expressions, which is
> what people do a lot of.  If there's a problem there, I just don't see it.
> And so I don't see solving it.

I agree there is a lot of value to the Lisp syntax. It is well worth
learning and using.  In part I did not focus on "the problem" because I
didn't want to come off as putting down Lisp syntax (any more than I
already did). And it is obvious from the posters on this newsgroup that
parentheses management is not considered to be a problem for the posters
in practice. From the replies on this thread, one can see that current
Lisp syntax works for many people, and it works well -- better than
alternatives. 

Obviously, if you look at the comp.lang.lisp posts related to this
thread, whether Lisp developers would want to use such a typographic
convention is a subject of strong feelings (currently overwhelmingly
negative). However, naturally the comp.lang.lisp group is in part
self-selected to feel this way. What I mean by that is that people who
don't like or can't get used to consistent use of parentheses would not
stay Lisp developers for very long or be likely to hang around
comp.lang.lisp. (I don't know what percentage of users that might be of
the people who try to learn Lisp -- it might well be very tiny.
Obviously TeachScheme! is meeting with great success.) It does seem
clear that most if not all Lisp developers feel the parentheses clutter
"melts away" sometime after sufficient familiarity, and the consistency
provides great benefits, and they also feel that any parentheses
management difficulties are easily managed by a smart editor like emacs
or DrScheme. 

Thus, Lisp developers don't like people complaining about all the
parentheses, and are even tired of saying "newbie, get over it". :-) I
can't blame them. And frankly, I can't deny I am a Lisp newbie, in the
sense that I've used Lisp syntax dialects for maybe a total of three or
four person-months, spread out over perhaps twenty years (each time
being for only a few weeks, including my current go round).

It is a very different question though to ask, for example, if novices
would feel the same way as experienced Lisp developers do, given a
choice of the two alternatives. Another different question is whether
such a convention might make Lisp family languages more attractive, for
example, to Python developers. For the record, a couple of people who
used both Python and Lisp said they wouldn't like indentational syntax
in Lisp. Of course, these are individuals hanging out in comp.lang.lisp
(and I might add as possibly (but not certainly) a symptom of "the
problem" that comp.lang.lisp has far less traffic at the moment than
comp.lang.python). There are of course deeper issues than parentheses
when people consider using other languages if they know one or more
already, and issues deeper still when someone learns to program for the
first time.

But to address more directly the issue of what I see "the problem" to
be:

How long does it take for the eye to get used to lots of parentheses?
Does everyone get used to them in the end? How intimidating are they at
the start? From what I read on newsgroups and elsewhere, and personal
experience, the visual clutter produced by using parentheses exclusively
to define structure obviously is an "adoption barrier" for many users
preventing them from even going down the road where they might get past
this. The fact that it may be a common complaint is an issue, whether it
is a justified complaint or not (which is a different issue). There is
truth that the phrase "Lots of Infernal Stupid Parentheses" reflects
many people's opinions on Lisp family languages (whether justified or
not) and thus prevents them from trying or sticking with Lisp or Scheme. 

Obviously, all languages have tradeoffs. So I find it quite acceptable
for one to admit Lisp family languages have issues with managing lots of
parentheses (which ultimately just reflect defining a nested structure,
where defining structure itself is absolutely required as part of almost
any programming task), and at the same time not find it inconsistent for
one to also believe other benefits can outweigh the costs and initial
discomforts related to only using parentheses (and braces, and brackets)
to define structure, given that other languages (C++, Pascal, Smalltalk,
Python, etc.) have their own costs which might outweigh the costs of
using Lisp or Scheme in various settings. And obviously, those costs of
managing lots of parentheses can be minimized by using an editor like
emacs that is good at that sort of task. But that doesn't mean there
isn't a cost to using lots of parentheses. One just calculates how big
the cost is relative to the advantages and the costs of other
approaches.

Let me try to define "the problem" in another way:

Speaking in terms of psycho-physiology, it is hard to tell the
difference between, for example, two or three parens, thus "))" is
difficult to distinguish between ")))", where it is easier to
distinguish the difference between ")" and " " (a difference much more
common when edge parentheses are removed using an indentational
syntax).  If one did some sort of physiological studies on this issue,
one might find out (guessing here) that something like "))))))"
stimulates pretty much the same mental pathways at nearly the same
frequency as ")))))))" (compared to either having a paren or not having
a paren). Thus, a Lisp program for a novice is from a perceptual point
of view filled with large chunks of high frequency "noise" that are not
readily distinguishable (except by conscious effort, or eventually
unconsciously only after significant experience leads to such items
being unconsciously "chunked" into non-noise objects). Again, as a
disclaimer, just because I think Lisp or Scheme might have this
weakness, this does not mean I think that the benefits of consistency
don't outweigh this disadvantage greatly.

However, given that I think there is a problem, I am trying to see if
one can separate the other features of Lisp or Scheme (in practice) from
the typographical convention of full parenthesization with redundant
indentation. It may turn out that the ability to parse text that is
properly parenthesized somehow is extremely essential to the language's
versatility (in such a way that an alternative could not as well be
supported) and also essential to the user's enjoyable experience and
long term productive use of the language. However, at the very least,
removing some parentheses and keeping everything else the same might
help create an experiment where the impact of parentheses as a
structure-defining convention could be better understood.

Still, I would think most people on this newsgroup would agree with you.
It's obvious that most experienced Lisp users do not consider managing
or viewing lots of parentheses to be a problem.
 
-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
From: Joseph Oswald
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like        significant   indentation?
Date: 
Message-ID: <o5gg0ob3xvl.fsf@is06.fas.harvard.edu>
Paul Fernhout <··········@kurtz-fernhout.com> writes:
>(Quoting KMP example)

>>infix
>>   a*b+c
>>   ^

vs. Lisp prefix
>>   (+ (* a b) c)
>>   ^

vs. proposed "indentational prefix"
>     +
>     ^
>       * a b
>       c

This is what I find most objectionable about this scheme. Instead of a
simple, robust, clean, unambiguous, one line expression, Paul seems to
find preferable a three-line, hard to visually parse, difficult to
properly quote on Usenet, over-white-spaced abomination. Pardon me if
I sound too grumpy about this.

Instead of a proven, robust, reliable method of including bodies, for
instance, in let blocks, Paul seems to prefer introducing another
extra line containing some syntactic sugar '...'.

Come on! Paul, you are totally underestimating the benefits of having
explicit parentheses, and totally overestimating the "benefits" of
making white space significant. 

If you really want to remove parentheses from your screen, have your
editor color them with a foreground color identical to your background
color. Then see how easy it is to write Lisp. Your editor will still
be able to indent using the invisible parentheses, so you'll get *all*
the benefits of your scheme, without changing Lisp one bit. I think
most programmers would quickly go bonkers using my method, which as
far as I can tell is equivalent in most respects to yours, except the
'...'.

Yet another subtlety that I think is missed in this discussion is the
special treatment of certain macros, which take ordinary arguments and
&body lists. They get indented specially, in my experience, although
the Lisp reader doesn't care. Will this scheme enforce certain
behaviors on the part of the programmer for these macros to be
properly parsed???

I think that whatever utility Python people get from their whitespace
is far overwhelmed by the utility that Lisp people get from their own
uniform, robust, unambiguous, and simple use of parentheses. Pardon me
if this is obvious to all you Lispers.

--Joe
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like         significant   indentation?
Date: 
Message-ID: <3995C238.7890F7E@kurtz-fernhout.com>
Joe-

Thanks for the reply. 

I put that example on multiple lines to amplify the difference.
You are right, it seems like a gratuitous use of indentation.
In practice I might well write "(+ (* a b) c)" depending on the context.

For example:

define (foo a b c)
  let 
    ...
     y (+ (* a b) c)
    print y

Someone else has suggested mapping the font of parentheses to another
color or size. This would not work in my approach because I am not
eliminating all parentheses, just the ones at the edges of expressions. 

For example, the Scheme expression conatining parentheses:

  define (foo x)
    print x

would be OK in the approach I outlined. Note this has a paren on a
"edge", but it is not from the entire S-expression consisting of a line;
instead it is related to an internal nested S-expression.

My current thinking is that as soon as the parser encountered an open
paren, it would start using conventional Lisp reader parsing rules. 

In this case, I think the only different behavior one encounters from
conventional Lisp behavior (regarding parens) would be when one had
multiple expressions on a top level line, like "reader> (foo) (bar)
(baz)" which indentational syntax would parse as the Lisp equivalent of
"reader> ((foo) (bar) (baz))" (because of the rule that multiple
S-expressions on a line are gathered together as a list). Everything
else I think would work the same, as this gathering rule would not apply
once one had descended under the sea of parens with the first one, and
until coming to the surface of that sea with the matching one.
Obviously, this might in some cases make error detection and providing
correction suggestions harder.

Regarding the "syntactic sugar" of "...", it is a needed way to indicate
that a blank line represents the start of a nested list. I would be glad
to see a better alternative. Right now, in terms of just textual
represnetaion, instead of "...", I am considering "~", "[", "\" and ".".
Of these, "\" and "[" seems the strongest candidates to me right now for
various reasons. However, short of allowing indentation to increase by
more than one step at a time, such an operator is unfortunately needed
for this approach.

You may well be correct that I am overestimating one set of benefits and
underestimating another. However, I hope Lisp developers might be
willing to consider the same, if I have a working system which I can
demonstrate and it works effectively. Since I do not have one yet, I am
mainly looking for useful feedback at this point on refining the
approach, and whether it can work technically -- whether or not it is
desirable, which, frankly, I myself will have to see work in practice
before I will make stronger arguments on its behalf. I obviously believe
in its potential value, or I would not be pursuing it. 

I do not full understand Lisp macros. I have a partial understanding of
Scheme macros. So it may well be there is something fundamental I have
missed. I would be grateful for an example of a macro where that macro
can not be represented using syntactically significant indentation. I
wouldn't say I'd be happy about it, but I would rather find out now than
after investing time trying to make an indentational system work.

Your point on Python vs. Lisp is well made. There certainly are many
advantages Lisp has that Python lacks when code and data have the same
format.

-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


Joseph Oswald wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> >(Quoting KMP example)
> 
> >>infix
> >>   a*b+c
> >>   ^
> 
> vs. Lisp prefix
> >>   (+ (* a b) c)
> >>   ^
> 
> vs. proposed "indentational prefix"
> >     +
> >     ^
> >       * a b
> >       c
> 
> This is what I find most objectionable about this scheme. Instead of a
> simple, robust, clean, unambiguous, one line expression, Paul seems to
> find preferable a three-line, hard to visually parse, difficult to
> properly quote on Usenet, over-white-spaced abomination. Pardon me if
> I sound too grumpy about this.
> 
> Instead of a proven, robust, reliable method of including bodies, for
> instance, in let blocks, Paul seems to prefer introducing another
> extra line containing some syntactic sugar '...'.
> 
> Come on! Paul, you are totally underestimating the benefits of having
> explicit parentheses, and totally overestimating the "benefits" of
> making white space significant.
> 
> If you really want to remove parentheses from your screen, have your
> editor color them with a foreground color identical to your background
> color. Then see how easy it is to write Lisp. Your editor will still
> be able to indent using the invisible parentheses, so you'll get *all*
> the benefits of your scheme, without changing Lisp one bit. I think
> most programmers would quickly go bonkers using my method, which as
> far as I can tell is equivalent in most respects to yours, except the
> '...'.
> 
> Yet another subtlety that I think is missed in this discussion is the
> special treatment of certain macros, which take ordinary arguments and
> &body lists. They get indented specially, in my experience, although
> the Lisp reader doesn't care. Will this scheme enforce certain
> behaviors on the part of the programmer for these macros to be
> properly parsed???
> 
> I think that whatever utility Python people get from their whitespace
> is far overwhelmed by the utility that Lisp people get from their own
> uniform, robust, unambiguous, and simple use of parentheses. Pardon me
> if this is obvious to all you Lispers.
> 
> --Joe
From: Seth Gordon
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like         significant   indentation?
Date: 
Message-ID: <399821D6.E6FF554F@kenan.com>
Paul Fernhout wrote:

> Someone else has suggested mapping the font of parentheses to another
> color or size. This would not work in my approach because I am not
> eliminating all parentheses, just the ones at the edges of expressions.

Emacs can set fonts based on regular-expression matches, not just based on
characters.  You could make parentheses invisible by default, and then make
visible any parenthesis that has a matching parenthesis on the same line (or
is in a comment or a string...).

(Yeah, I know, regular expressions can't count, so you can't really write
one that keeps track of nested parentheses.  However, if you assume that,
say, no line will have more than ten sets of parentheses on it, the problem
becomes tractable.)

Disclaimer: I'm not volunteering to write an indentational-syntax-lisp.el
module, since (a) I don't have a lot of elisp programming experience, and
(b) I don't consider parenthetical syntax to be a problem in Lisp.

--
--Why is it that most kids are attracted to computers while
  most adults are quite wary of computers?
--Most adults are smarter than most kids. ["Ask Uncle Louie"]
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <B5BA97CF.5351%page@best.NOSPAM.com>
in article ·················@kurtz-fernhout.com, Paul Fernhout at
··········@kurtz-fernhout.com wrote on 2000.08.11 14:14:

> Speaking in terms of psycho-physiology, it is hard to tell the
> difference between, for example, two or three parens, thus "))" is
> difficult to distinguish between ")))"

Exactly. Simply from a typographical standpoint, long strings of parenthesis
are undesirable. However, the readability can be improved with a little
typographical help without changing the language. For example, outer
parenthesis can be displayed in a larger size, or a heavier weight, or by
using glyphs that have different amounts of curvature. Going further, one
can begin to vary the symbols used: {[(

And I think the reference to typography here is of prime importance.
Parenthesis, white space, and semicolons, for example, are fluid things in
the world of publishing. They can be displayed in many different ways, to
make the text easier to read, and sometimes to add meaning.

I hope that single-font, single-size, mono-space, plain text editors are
finally replaced by something richer soon.

[And when I use the future tense in any of my postings on this topic, I'm
not trying to say that these haven't been tried or don't exist, but that
they aren't found in common usage. And if that isn't enough of a
qualification for some of you, I'll add: Found in common usage in the world
of consumer software development.]

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <3995C35D.3B6C690@kurtz-fernhout.com>
Chris-

Thanks for this and the other great replies on this topic. 

I picked up the concept of discussing "typography" as opposed to deep
structure from your post on the future of editing programs. It is a
great distinction.

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

Chris Page wrote:
> 
> in article ·················@kurtz-fernhout.com, Paul Fernhout at
> ··········@kurtz-fernhout.com wrote on 2000.08.11 14:14:
> 
> > Speaking in terms of psycho-physiology, it is hard to tell the
> > difference between, for example, two or three parens, thus "))" is
> > difficult to distinguish between ")))"
> 
> Exactly. Simply from a typographical standpoint, long strings of parenthesis
> are undesirable. However, the readability can be improved with a little
> typographical help without changing the language. For example, outer
> parenthesis can be displayed in a larger size, or a heavier weight, or by
> using glyphs that have different amounts of curvature. Going further, one
> can begin to vary the symbols used: {[(
> 
> And I think the reference to typography here is of prime importance.
> Parenthesis, white space, and semicolons, for example, are fluid things in
> the world of publishing. They can be displayed in many different ways, to
> make the text easier to read, and sometimes to add meaning.
> 
> I hope that single-font, single-size, mono-space, plain text editors are
> finally replaced by something richer soon.
> 
> [And when I use the future tense in any of my postings on this topic, I'm
> not trying to say that these haven't been tried or don't exist, but that
> they aren't found in common usage. And if that isn't enough of a
> qualification for some of you, I'll add: Found in common usage in the world
> of consumer software development.]
> 
> --
> Chris Page
> Mac OS Guy
> Palm, Inc.
> 
> let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like        significant   indentation?
Date: 
Message-ID: <sfwaeegtmnm.fsf@world.std.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Kent M Pitman wrote:
...
> > My concern would also be about subtleties like:
> >  (setq x f)
> > vs
> >  (setq x (f))
> > Were I to replace parens with indentation, it's not obvious to me how to
> > easily distinguish these two items.  Do I add "a little extra" identation
> > for the second?  That would be awful.
> 
> Well, I admit that getting something like this correct is always an
> issue. But let me give this a try: 
> For example: [... discussion of (setq x f) elided ...]
> For your other example:
> 
>   (setq x (f))
> 
> can be represented as:
> 
>   setq x (f)
> 
> or:
> 
>   setq x
>     (f)
> 
> or:
> 
>   setq 
>     x
>     (f)
> 
> This is a special case (rule 3) where a single item on a line without
> parentheses is treated as a single item, not a list. So, it needs
> parentheses. 
> 
> As an alternative, using "..." to indicate the start of a list, one
> could also represent "(setq x (f))" as:
> 
>   setq x
>     ... f
> 
> or: [...etc.  Other examples of literal "..." elided.]

I have to say that I find this a bigger problem than you probably do.

The problem here is that the language builds up an obvious expectation that
parens can be avoided, and then hits you with some fairly obvious cases
where they cannot.

As an aside, my personal "analogy engine" coughs up an example from Lisp
where this same issue arises.  People have (rightly) criticized LOOP for
offering a certain interesting power but in the veil of being "easy to read",
or worse, "easy to write".  The problem is that when one writes LOOP one has
to know one is NOT writing English.  One is crafting a very specific kind of
specialized stuff that is intended to look vaguely Englishy but which 
certainly cannot be written by anyone who thinks they are merely writing
English and probably cannot be read, except in the most common an fortuitous
cases, by someone who thinks the mere look of English is enough to see all
of the subtleties.  As such, any appeal of being "English-like" rather than
a formal syntax that is utterly alien is highly dubious.  The result, some
claim, is that people are likely to want to use LOOP for the wrong reasons,
likely to use it when they are too little familiar with its subtleties, likely
not to see bugs due to being thrown off by the "obvious false cognate meaning",
etc. etc.  Simple LOOPs should not use LOOP, but simple LOOPs are probably
the only case where it is "safe" to use LOOP.  Complex LOOPs are where you
really need them, because the alternative is much harder to write longhand
in DO or recursion or whatever other thing you might use, and yet complex LOOPs
are very hard to write, to read, and to debug.  

I suspect most of the same can be said for the "clever" indentation of
Python.  It's more deceptively simple than it looks, leading one to a false
sense that it is "sufficiently powerful", and then to an unfair sense of having
"failed" when one fails to find a non-parenthensized form of certain obvious
things.

HyperTalk made a similar attempt to never use parens, but there are certain
kinds of things that are very hard to write without them, and then result is
again a sense of "failure" in those who don't realize that they have in fact
reached the limitation of the design and who instead feel that they "just must
be doing something wrong if they've had to resort to parentheses in a language
that so obviously intends parens not to be the answer".

- - - - -

Incidentally, I experimented a little with audio programming languages, and
this same issues arises.  I found it useful to use the notation "of" after
a function call and found the odd situation of needing to say "f of" to denote
functions of no arguments, since "f" denoted a variable.  I found myself
prefering to say "f of nothing" and to have the parser special-case this.
You might find it useful to think about having Python permit something like:

   f
     nothing

rather than

   ... f

as a more natural way to express the issue, though either is obviously a 
kludge.

- - - - - 

The other thing that troubles me about this indentation-oriented thing is
something that various text editors just don't deal well with and  that's
a 1-d text model.  The problem is Emacs control-x n feature (recently, due
to some stupidity i shall never understand, renamed to control-x n n, but
in either case being about narrowing buffer bounds).  Since Emacs has a 
linear buffer model, you can pick any two points in the buffer and ask that
they be treated as buffer start and buffer end, and all commands work as if
the rest of the buffer is not there.  This puts an ENORMOUS burden on the
user of a language like Python never to narrow buffer bounds around a region
of Python code except at start of line, since otherwise you'll be at some
weird place with respect to understanding the nesting of those components
that follow the "virtual start of buffer".  

Note that there was a text editor that I never used but that the guys at
Yale when I was there used to swear by in which text regions were always
marked in 2d and screen rectangles operated on.  In that model, of course,
lisp code was always problematic but python code would be fine.

I guess I don't mean this to be a criticism of python or of lisp, so much as
an observation that languages often make assumptions about the text editors
they will be used with, and vice versa.

- - - - -

MIT Lisp Machine Lisp (the so-called "LMITI", or LMI/MIT/TI system) had a
feature for a while, as I recall, and maybe still does, where it would be
willing to signal a paren-balancing error if the file compiler ever saw an
open or close paren at a point that didn't make sense for the indentation 
level.  Allowing indentation to be used as a double-check, but not as a 
primary carrier of information, much as the human eye would use indentation.
That seemed like an interesting option to have, but I think it would have
annoyed me and I'd probably eventually have turned it off; I used the 
Symbolics branch of Lisp Machine Lisp, so I never experienced the feature
first hand.  
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like         significant   indentation?
Date: 
Message-ID: <399AA050.E04B04E6@kurtz-fernhout.com>
Kent-

I really enjoyed your post.

To amplify your point on languages, I've heard that there is a "Basic
Aviation English" of one hundred (or one thousand?) words or so for all
airline pilots to know so that they can land at any airfield anywhere in
the world. It consists of words like "Roger", "Turn", "Left", "One"
"Hundred", "Degrees", etc. It turns out the pilots who have the hardest
time using aviation English properly are those pilots who speak --
English! This is because they do not easily remember (especially
instantly) what English words they can say, and what English words they
can't in the limited "Aviation English" context. I've seen the same
issue with limited vocabulary speech recognition systems -- where people
have a conversational vocabulary expectation of something just
supporting a few commands and have trouble remembering what exactly the
system can respond to.

Erik brought up an excellent point in another part of this thread that
one reason Lisp may be hard to learn for some people knowing other
computer languages is that so many of the base words (and related
concepts) are different from what other languages present as base words
and concepts. This does seem true -- especially for example in the
Scheme case where tail-recursion is so heavily promoted. I guess this in
part reflects Lisp's theoretical and mathematical heritage.

In a language like Smalltalk, at least the odd words are grouped by the
system around specific browseable classes -- whereas in Lisp or Scheme
the odd words and related concepts (car, cdr, replaca, set-cdr!, map, to
name a few) are all sort of at the top level (except as organized by
good documentation). Obviously, one can do OO in Lisp, via classes or
multimethods, so there are other ways of organizing aditional functions
in Lisp.

Still, I see no reason why Lisp and Scheme can't have analogus
constructs to most other languages -- for example, it would be easy to
implement a "(for-in x a-list (command) ...)" function in Scheme that
worked like "for x in aList: statements" in Python. The LOOP word you
reference may or may not work in practice for complex things, but maybe
other simple looping constructs for common use might work well.

I especially liked your suggestion of a "nothing" word. Python has that
for statements by using "pass". I use that occasionally, especially when
I am prototyping a structure of class functions that I will fill in
later. I'll have to think about that.

As a motivational example, changing:

  print 
    foo
      * 5 3

to:

  print 
    foo

changes the meaning from printing a foo function call on a computed
value 
"(print (foo (* 5 3)))" to just printing the value bound to the foo
symbol, as in "(print foo)". It would be nice when changing this
expression to have an option along the lines of what you suggest:

  print
    foo
      nothing

Then, the reference to foo remains as a function call, but this time
with no arguments, as "(print (foo))".

You have a very good point that it is hard to eliminate all parens, and
that what one might have left afterwards might look awkward or unwieldy
or unuseable. Hopefully this proposal at this point can support writing
code in a useful middle ground (relying on indentation but using parens
within a line as desired), while still supporting either extreme (no
parens or all parens).

At this point, I'm starting to think one can provide indentational
syntax as a "supplement" to parenthesized notation in a Lisp or Scheme
reader. It turns out, that since I invoke regular parsing rules on
encountering a paren until the closure of the paren, and almost all
useful top level Lisp expressions are in parens, that the two
conventions can mostly coexist. The only odd cases I can think of are
where there is more than S-expression on a top level line, or where an
S-expression at the top level starts with some indentation, or one
S-expression follows another multi-line one on the same line the other
ends.

Thanks again for the interesting comments, especially about "nothing".
:-).

-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

Kent M Pitman wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > Kent M Pitman wrote:
> ...
> > > My concern would also be about subtleties like:
> > >  (setq x f)
> > > vs
> > >  (setq x (f))
> > > Were I to replace parens with indentation, it's not obvious to me how to
> > > easily distinguish these two items.  Do I add "a little extra" identation
> > > for the second?  That would be awful.
> >
> > Well, I admit that getting something like this correct is always an
> > issue. But let me give this a try:
> > For example: [... discussion of (setq x f) elided ...]
> > For your other example:
> >
> >   (setq x (f))
> >
> > can be represented as:
> >
> >   setq x (f)
> >
> > or:
> >
> >   setq x
> >     (f)
> >
> > or:
> >
> >   setq
> >     x
> >     (f)
> >
> > This is a special case (rule 3) where a single item on a line without
> > parentheses is treated as a single item, not a list. So, it needs
> > parentheses.
> >
> > As an alternative, using "..." to indicate the start of a list, one
> > could also represent "(setq x (f))" as:
> >
> >   setq x
> >     ... f
> >
> > or: [...etc.  Other examples of literal "..." elided.]
> 
> I have to say that I find this a bigger problem than you probably do.
> 
> The problem here is that the language builds up an obvious expectation that
> parens can be avoided, and then hits you with some fairly obvious cases
> where they cannot.
> 
> As an aside, my personal "analogy engine" coughs up an example from Lisp
> where this same issue arises.  People have (rightly) criticized LOOP for
> offering a certain interesting power but in the veil of being "easy to read",
> or worse, "easy to write".  The problem is that when one writes LOOP one has
> to know one is NOT writing English.  One is crafting a very specific kind of
> specialized stuff that is intended to look vaguely Englishy but which
> certainly cannot be written by anyone who thinks they are merely writing
> English and probably cannot be read, except in the most common an fortuitous
> cases, by someone who thinks the mere look of English is enough to see all
> of the subtleties.  As such, any appeal of being "English-like" rather than
> a formal syntax that is utterly alien is highly dubious.  The result, some
> claim, is that people are likely to want to use LOOP for the wrong reasons,
> likely to use it when they are too little familiar with its subtleties, likely
> not to see bugs due to being thrown off by the "obvious false cognate meaning",
> etc. etc.  Simple LOOPs should not use LOOP, but simple LOOPs are probably
> the only case where it is "safe" to use LOOP.  Complex LOOPs are where you
> really need them, because the alternative is much harder to write longhand
> in DO or recursion or whatever other thing you might use, and yet complex LOOPs
> are very hard to write, to read, and to debug.
> 
> I suspect most of the same can be said for the "clever" indentation of
> Python.  It's more deceptively simple than it looks, leading one to a false
> sense that it is "sufficiently powerful", and then to an unfair sense of having
> "failed" when one fails to find a non-parenthensized form of certain obvious
> things.
> 
> HyperTalk made a similar attempt to never use parens, but there are certain
> kinds of things that are very hard to write without them, and then result is
> again a sense of "failure" in those who don't realize that they have in fact
> reached the limitation of the design and who instead feel that they "just must
> be doing something wrong if they've had to resort to parentheses in a language
> that so obviously intends parens not to be the answer".
> 
> - - - - -
> 
> Incidentally, I experimented a little with audio programming languages, and
> this same issues arises.  I found it useful to use the notation "of" after
> a function call and found the odd situation of needing to say "f of" to denote
> functions of no arguments, since "f" denoted a variable.  I found myself
> prefering to say "f of nothing" and to have the parser special-case this.
> You might find it useful to think about having Python permit something like:
> 
>    f
>      nothing
> 
> rather than
> 
>    ... f
> 
> as a more natural way to express the issue, though either is obviously a
> kludge.
> 
> - - - - -
> 
> The other thing that troubles me about this indentation-oriented thing is
> something that various text editors just don't deal well with and  that's
> a 1-d text model.  The problem is Emacs control-x n feature (recently, due
> to some stupidity i shall never understand, renamed to control-x n n, but
> in either case being about narrowing buffer bounds).  Since Emacs has a
> linear buffer model, you can pick any two points in the buffer and ask that
> they be treated as buffer start and buffer end, and all commands work as if
> the rest of the buffer is not there.  This puts an ENORMOUS burden on the
> user of a language like Python never to narrow buffer bounds around a region
> of Python code except at start of line, since otherwise you'll be at some
> weird place with respect to understanding the nesting of those components
> that follow the "virtual start of buffer".
> 
> Note that there was a text editor that I never used but that the guys at
> Yale when I was there used to swear by in which text regions were always
> marked in 2d and screen rectangles operated on.  In that model, of course,
> lisp code was always problematic but python code would be fine.
> 
> I guess I don't mean this to be a criticism of python or of lisp, so much as
> an observation that languages often make assumptions about the text editors
> they will be used with, and vice versa.
> 
> - - - - -
> 
> MIT Lisp Machine Lisp (the so-called "LMITI", or LMI/MIT/TI system) had a
> feature for a while, as I recall, and maybe still does, where it would be
> willing to signal a paren-balancing error if the file compiler ever saw an
> open or close paren at a point that didn't make sense for the indentation
> level.  Allowing indentation to be used as a double-check, but not as a
> primary carrier of information, much as the human eye would use indentation.
> That seemed like an interesting option to have, but I think it would have
> annoyed me and I'd probably eventually have turned it off; I used the
> Symbolics branch of Lisp Machine Lisp, so I never experienced the feature
> first hand.
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like          significant   indentation?
Date: 
Message-ID: <sfwpun9b0wy.fsf@world.std.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> As a motivational example, changing:
> 
>   print 
>     foo
>       * 5 3
> 
> to:
> 
>   print 
>     foo
> 
> changes the meaning [...]

Worse, it means that expressions at the bottom of the screen can never be
understood without scrolling.  That seems the most damning thing I've heard
about this notation.

At least in Lisp, while you might not know if the expression is yet closed,
that is, you can't tell the difference between "(foo" at the bottom of the
screen meaning (foo x) and (foo x ...)
without finding what's on the next line.  And usually we recommend close
parens on the same line, unlike other languages, so even then it doesn't
really happen. So nearly always "(foo" means (foo x ...), since otherwise one
would have seen "(foo)".  But in Python, apparently, the above example doesn't
allow me to tell visually which of two very unrelated semantics there should
be.

This argues for python being a single-namespace language [is it?] in order to
reduce the likelihood that there is both a foo variable and a foo function
active in the same situation.

> You have a very good point that it is hard to eliminate all parens, and
> that what one might have left afterwards might look awkward or unwieldy
> or unuseable. Hopefully this proposal at this point can support writing
> code in a useful middle ground (relying on indentation but using parens
> within a line as desired), while still supporting either extreme (no
> parens or all parens).

Well, my real point, lest it get lost, is that the naive user is unable to
tell whether they have "reached the right place to use parens" or "failed
at understanding how to get rid of the parens", and that this can be 
demoralizing.  The answer to the question you ask here can only be answered
by a sophisticated user, who has the perspective to know if he has succeeded
or failed.  Novices will, in my experience, just assume they have failed.

Analogy time, to drive the point home:  People who play solitaire often 
conclude that they have lost when they have played optimally with a deck 
dealt to fail.  This is, I assume, is because they don't have the mathematical
sophistication to understand the true consequences of the familiar phrase
"the deck was stacked against you", and becuase they assume it's only someone
trying to make them feel better (rather than an actual truth) when someone 
says "you played fine".

> At this point, I'm starting to think one can provide indentational
> syntax as a "supplement" to parenthesized notation in a Lisp or Scheme
> reader.

I think not, but you probably won't agree with my reason.  I believe it 
fragments the community badly to do this.  The problem is that a single
READ operation can't distinguish whether PRINT was done with your printer
or mine.  We, in the Lisp community, tolerate a great deal of variety.
Uppercase input and lowercase input, varying levels of indentation and
whitespace control, vertical bars vs backslash, explicit vs implied package
references, etc.  And READ (as well as a qualified human reader)
can canonicalize all of these in a way that makes it not matter that people
differ in style.  But the difference in style you propose is more like 
changing the readtable, and mostly although the capability exists, I don't 
recommend people do this except for unusual domain-specific needs because
it does not encourage good programmer interchange.

> It turns out, that since I invoke regular parsing rules on
> encountering a paren until the closure of the paren, and almost all
> useful top level Lisp expressions are in parens, that the two
> conventions can mostly coexist.

I don't doubt this can be made to work from a self-consistency point of view.
I just think it's better to get used to Lisp syntax.  Just social advice; not 
technical.

> The only odd cases I can think of are
> where there is more than S-expression on a top level line, or where an
> S-expression at the top level starts with some indentation, or one
> S-expression follows another multi-line one on the same line the other
> ends.

I have no opinion here.  Afraid I can't quite bring myself to spend 
the brain power proving it's possible to do something that I'm sure it's
possible to do, only to an end I don't really think will serve either you
or me...
 
> Thanks again for the interesting comments, especially about "nothing".
> :-).

"Thanks for nothing.", eh?   Uh, sure.  Any time. ;-)
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <B5BAAEBF.5363%page@best.NOSPAM.com>
in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.11 10:32:

> Consider, by contrast, infix languages where you have a situation like:
> 
> a*b+c
> ^
> 
> with the cursor at the indicated point and you want to grab the expression
> after the cursor.  You can't.  You don't know if "the expression" is a,
> a*b, or a*b+c because the situation is ambiguous.

This may be a bit difficult with some text editors, but it doesn't mean that
it can't be handled. Take a look at Graphing Calculator (the one that comes
with Mac OS) for an example. When dragging the mouse over an expression it
automatically selects sub-expressions, rather than just characters. If you
drag over "*b" it selects "a*b". If you continue dragging to include "+", it
selects "a*b+c". [If you actually try this, you'll find that it doesn't draw
the "*", since "ab+c" is sufficient.]

There's an implicit set of parenthesis around the entire expression and
precedence implies internal parenthesis. They're there, they just aren't
displayed -- for clarity.

Of course when you say "the situation is ambiguous" you mean "the situation
is ambiguous for a text editor that knows nothing about the language". If
nothing else can be learned from the example of emacs, it must be true that
(at least some) people desire smart editors.

> My concern would also be about subtleties like:
>  (setq x f)
> vs
>  (setq x (f))
> Were I to replace parens with indentation, it's not obvious to me how to
> easily distinguish these two items.  Do I add "a little extra" identation
> for the second?  That would be awful.

I'm pretty sure the original proposal for indentation-sensitivity allowed
for parenthesis to remain in the language. So you could keep the parenthesis
around "f" if they're significant. I think all you've shown is that
programmers would still need the option of using parenthesis.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <3995C470.8CB5AAE3@kurtz-fernhout.com>
Chris -

Thanks for the great comments.

You are quite right in pointing out that parentheses are still supported
in the approach. Here is my current thinking on them.

As soon as a paren "(" or quote paren "'(" is encountered, significant
indentation and bracket rules are suspended until the close paren, to
constuct an embedded S-expression. At that point, indentation rules
resume as if the entire paren expression was a single item on one line.
The start paren or quote of such an expression must still be indented
properly however.

Example:

  define foo '(this is a very
long list of symbols
         being strangely wrapped) 
  print foo 

=> '(this is a very long list of symbols being strangely wrapped)

Example:

  define (foo x)
   (let ((y 20)
        (print 
(* x y)))
   print "done"

is equivalent to:

  (define (foo x)
   (let ((y 20)
    (print (* x y)))
   (print "done"))

Note however, that more than one parenthesized S-expression on a line
outside of a parenthesized expression will still be taken together to
form a list.

Thus, in indentational syntax:

  (foo x) (bar x) (baz x)

is equivalent in conventional Lisp syntax to:

 ((foo x) (bar x) (baz x))

which is not what someone used to working in the old convention might
expect for evaluation of a top level line.

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

Chris Page wrote:
> 
> in article ···············@world.std.com, Kent M Pitman at
> ······@world.std.com wrote on 2000.08.11 10:32:
> 
> > Consider, by contrast, infix languages where you have a situation like:
> >
> > a*b+c
> > ^
> >
> > with the cursor at the indicated point and you want to grab the expression
> > after the cursor.  You can't.  You don't know if "the expression" is a,
> > a*b, or a*b+c because the situation is ambiguous.
> 
> This may be a bit difficult with some text editors, but it doesn't mean that
> it can't be handled. Take a look at Graphing Calculator (the one that comes
> with Mac OS) for an example. When dragging the mouse over an expression it
> automatically selects sub-expressions, rather than just characters. If you
> drag over "*b" it selects "a*b". If you continue dragging to include "+", it
> selects "a*b+c". [If you actually try this, you'll find that it doesn't draw
> the "*", since "ab+c" is sufficient.]
> 
> There's an implicit set of parenthesis around the entire expression and
> precedence implies internal parenthesis. They're there, they just aren't
> displayed -- for clarity.
> 
> Of course when you say "the situation is ambiguous" you mean "the situation
> is ambiguous for a text editor that knows nothing about the language". If
> nothing else can be learned from the example of emacs, it must be true that
> (at least some) people desire smart editors.
> 
> > My concern would also be about subtleties like:
> >  (setq x f)
> > vs
> >  (setq x (f))
> > Were I to replace parens with indentation, it's not obvious to me how to
> > easily distinguish these two items.  Do I add "a little extra" identation
> > for the second?  That would be awful.
> 
> I'm pretty sure the original proposal for indentation-sensitivity allowed
> for parenthesis to remain in the language. So you could keep the parenthesis
> around "f" if they're significant. I think all you've shown is that
> programmers would still need the option of using parenthesis.
> 
> --
> Chris Page
> Mac OS Guy
> Palm, Inc.
> 
> let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Duane Rettig
Subject: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <4zomimp21.fsf_-_@beta.franz.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Paolo-
> 
> Mostly that impression is from comments on this newsgroup to this
> posting. The possibility that an indentational syntax might make cut and
> paste more difficult seems to be a source of strong objections to an
> indentationally significant syntax (not that there aren't others).

I think that the reason why you are seeing so many objections to the
idea of removing parens in lisp is due to a subconscious mental process
that nobody has yet been able to articulate, though some have come very
close by noting the code-and-data aspect of lisp.  Let me try to make that
articulation, by posing a puzzle:

How many parens, left and right, are in Lisp code?

Answer:  very few.


To illustrate this, let's take a couple of examples:

Example 1:

How many parens are in the following code?

(defun foo (a b)
  (let ((c (+ a b)))
    (list a b c)))


Answer: 0


Example 2:

How many parens are in the following code?

(defun foo ()
  #\()

Answer: exactly 1 left paren.


The problem with actually _describing_ the lisp code that is
associated with the above _text_ in a newsgroup such as this
one is that the communication must be made by textual means,
and thus the program content cannot be easily transferred without
using some representation that would probably include parens.

Let me buck this tendency, however, and show you two ways to
represent a lisp program without parens:

Method 1: Replace parens with something else.

Unfortunately, the Allegro CL reader has been optimized to recognize
parens, and thus is not general enough to do this.  Perhaps there
is another CL out there that is general enough.  But conceptually,
it should be easy to reconfigure both the reader and the printers
(pretty and non-pretty) to recognize and print the following code:


[defun foo [a b]
  [let [[c [+ a b]]]
    [list a b c]]]

Which describes _precisely_ the same program in Example 1, above,
or to recognize and print the following code:

[defun foo []
  #\(]

as the same program as in Example 2, above.  Note that my answers to
the puzzle are much more evident in these textual representations than
in the more traditional and standard CL representations, above.


Method 2: Represent code with pointers and pictures.

This is _much_ harder to do, and so I will create a more trivial
example, the expression (+ a b), to illustrate.  This is the way
most lisp books teach inner lisp list structure.

The list (+ a b) is represented internally as


  ---------       -------       -------
 |    |    | --> |   |   | --> |   |   | --> nil
  ---------       -------       -------
   |               |             |
   v               v             v

   +               a             b

Where each box represents a cons cell, with the left half being the
car and the right half being the cdr.


In CL, a parenthesis is a mechanism to trivially transform between
a textual representation of lisp code, and the lisp code itself.
Some people call this code "the internal form", but I don't
believe that this does it justice; I view it as the "real" form
of the lisp code; it is simply a hard form to describe without
a textual representation of some sort.

Finally, you have seen many Lispers point out that parens disappear
for them.  What is this phenomenon, and when does it happen?  I
believe that it occurs when the programmer realizes that lisp code
is not "what you see", but instead what it actually represents.




-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Paul Fernhout
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses  ...)
Date: 
Message-ID: <3995D148.FAB5733B@kurtz-fernhout.com>
Duane-

A very thought provoking post. Thanks!

I guess I am seeing Lisp or Scheme programming right now as primarily
involving defining tree structures. That is done with a typographical
convention involving nesting parenthetical lists. 

I have no interest in replacing the parens with similar character
symbols or other graphical contentions (although that certainly is an
interesting idea, and could be quite useful for illustrating to newbies
how Lisp works, as such diagrams are frequently seen in introductory
texts at the start.)

If Lisp code is what it represents, than one could view what I am
proposing as a way to create Lisp and Scheme representations so that
"what you see" is as close as possible to that underlying structure,
with a minimum of extra characters, given that 2D space layouts can in
some circumstances make sense to the human eye. In effect, I am trying
to make the tree structure implicit in all Lisp S-expressions explicit
on the page, and without anything unneeded. 

[Yes, I know in Scheme for example you can define joined branches to
form a web using special techniques, etc.]
 
I really am trying to look into the possibility of a fundamental
improvement in Lisp language family typography -- hopefully without
affecting any other aspects of the language. My direction is in the
direction Edward Tufte might call "removing Chart Junk" where I define
edge parentheses as "Chart Junk". I can't say Tufte would necessarily
agree with anything I have said, but I certainly personally feel the use
of syntactically significant indentational whitespace in programming
languages would be something he might find interesting and of which he
might approve. Anyone out there at Yale and also willing to ask him for
an opinion?

Tufte links:
  http://www.cs.yale.edu/people/faculty/tufte.html
  http://public.logica.com/~stepneys/bib/nf/tufte.htm
  http://www.washington.edu/computing/training/560/zz-tufte.html
  http://www.mousetrap.net/~mouse/uta/transatlantic/tufte.html

I have been thinking of moving to indentation style of one space only,
on the argument the burden of proof should be to show this is not enough
to distinguish nesting levels. The advantage to this approach is then a
single space key press nests an expressions, and a single delete key
press unnests. So there is a direct mapping of single common keystrokes
to list sub-expression promotion and demotion. Obviously, a fancy editor
or printing package could know if desired how to draw spaces to the left
of expression perhaps much wider than spaces within expressions, or to
draw such spaces using other conventions.

My current thinking on indenting is below. Note that parens suspend
indentational syntax rules and revert to regular conventional Lisp
parsing rules (explained in other posts).

========= Indenting Rules ================

Indenting is done by a single space. [Previously I had suggested two
spaces, which was similar to Occam.]

A line containing one expression (symbol, list, quoted list) returns
that expression, unless it has children. These expressions are processed
using conventional Lisp S-expression rules.

Example:

  define 
   foo
   "hello"

is equivalent to:

  (define 
   foo 
   "hello")

A line containing two or more expressions, or one expression with
children, returns a list of those expressions.

Example:

  define
   foo string
   print string
   print
    string-length string

Is equivalent to:

  (define (foo string)
   (print string)
   (print
    (string-length string)))

Example:

  define
    foo string
    print string

or:

  define (foo string) (print string)

is equivalent to:

  (define (foo string) (print string))

=========================

The only equivalent to the paren I have been thinking about is the idea
of a bracket which is automatically closed at the end of a line. This
would take the place of the "..." I introduced in the original proposal.
I think using an open bracket is a real possiblity. However, I am also
considering the "\" symbol, which sort of indicates indentation to me
(implying the following is on a lower level sliding down the symbol). I
might have used "/" except for it's meaning as divides, and "." except
it has several menanings in Lisp already. I don't think "\" has a
meaning outside of a string (in Scheme at least). [Feel free to point
out a useage for "\" if I am wrong -- I haven't researched this one
detail very far.]

Here is my current thinking on this idea of terminating common short
lists at the end of a line:

========== Bracket Rules ================

If starting a line by itself, an open bracket indicates start of list
(with children or empty)

Example:

  define (foo)
   let
    [
     x 10
    print x

is equivalent to:

  (define (foo)
   (let
    (
     (x 10))
    (print x)))

Example:

  define empty-list
   quote
    [

is equivalent to:

  (define empty-list
    (quote
      ())

Example:

  define (print-sum)
   print
    [
     +
     2
     3

is equivalent to:

  (define (print-sum)
   (print
    (
     +
     2
     3)))

If starting a line with one expression (symbol or parenthesized list, or
quoted list), an open bracket indicates a list containing that
expression as a single element.

Example:

  define 
   [print2
   print "2"

is equivalent to:

  (define 
   (print2)
   (print "2"))

If starting a line with two or more expressions, an open bracket is
ignored, except as a placeholder if there is another bracket following.

Example:

  define
   [foo x
   [print x

is equivalent to:

  (define 
   (foo x)
   (print x))

Example:

  define (foo x)
   let
    [[x 10
    print x

is equivalent to:

  (define (foo x)
   (let 
    ((x 10))
    (print x)))

Note that both open brackets are required, lest "[[x 10" be interpreted
as just a list of "(x 10)" as opposed to the list of a list as in the
expression "((x 10))".

If in the middle of a line, an open bracket indicates the start of a
list that ends with the end of the line.

Example:

  define [foo x
   print x

is equivalent to:

  (define (foo x)
   (print x))

Example:

  define [foo
   let [[x 10
    print x

is equivalent to:

  (define (foo)
   (let ((x 10))
    (print x)))

Undecided: close brackets are optional? Or are not allowed?

* The quote operator or "'" works the same as in Lisp/Scheme.

Example:

  define foo '[1 2 3 4

is equivalent to:

  (define foo '(1 2 3 4))

==================================

An example in indentational Scheme:

; let for only one variable
define let-be 'to-be-written  

; for-in works like python "for x in array:"
define for-in 'to-be-written 

define joy-is
 lambda
  write "Joy is:"
  newline
  let-be clutter '[ "parentheses matching effort" "extra keystrokes"
"Chart Junk"
   for-in annoyance clutter
    write " programming without: "
    write annoyance
    newline
  let-be good-things '[ "elegance" "directness" "smart editors"
"S-expressions"
   for-in good-thing good-things
    write " programming with: "
    write good-thing
    newline

(joy-is)

=====================================

Thanks again for the thought provoking reply.

-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

Duane Rettig wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > Paolo-
> >
> > Mostly that impression is from comments on this newsgroup to this
> > posting. The possibility that an indentational syntax might make cut and
> > paste more difficult seems to be a source of strong objections to an
> > indentationally significant syntax (not that there aren't others).
> 
> I think that the reason why you are seeing so many objections to the
> idea of removing parens in lisp is due to a subconscious mental process
> that nobody has yet been able to articulate, though some have come very
> close by noting the code-and-data aspect of lisp.  Let me try to make that
> articulation, by posing a puzzle:
> 
> How many parens, left and right, are in Lisp code?
> 
> Answer:  very few.
> 
> To illustrate this, let's take a couple of examples:
> 
> Example 1:
> 
> How many parens are in the following code?
> 
> (defun foo (a b)
>   (let ((c (+ a b)))
>     (list a b c)))
> 
> Answer: 0
> 
> Example 2:
> 
> How many parens are in the following code?
> 
> (defun foo ()
>   #\()
> 
> Answer: exactly 1 left paren.
> 
> The problem with actually _describing_ the lisp code that is
> associated with the above _text_ in a newsgroup such as this
> one is that the communication must be made by textual means,
> and thus the program content cannot be easily transferred without
> using some representation that would probably include parens.
> 
> Let me buck this tendency, however, and show you two ways to
> represent a lisp program without parens:
> 
> Method 1: Replace parens with something else.
> 
> Unfortunately, the Allegro CL reader has been optimized to recognize
> parens, and thus is not general enough to do this.  Perhaps there
> is another CL out there that is general enough.  But conceptually,
> it should be easy to reconfigure both the reader and the printers
> (pretty and non-pretty) to recognize and print the following code:
> 
> [defun foo [a b]
>   [let [[c [+ a b]]]
>     [list a b c]]]
> 
> Which describes _precisely_ the same program in Example 1, above,
> or to recognize and print the following code:
> 
> [defun foo []
>   #\(]
> 
> as the same program as in Example 2, above.  Note that my answers to
> the puzzle are much more evident in these textual representations than
> in the more traditional and standard CL representations, above.
> 
> Method 2: Represent code with pointers and pictures.
> 
> This is _much_ harder to do, and so I will create a more trivial
> example, the expression (+ a b), to illustrate.  This is the way
> most lisp books teach inner lisp list structure.
> 
> The list (+ a b) is represented internally as
> 
>   ---------       -------       -------
>  |    |    | --> |   |   | --> |   |   | --> nil
>   ---------       -------       -------
>    |               |             |
>    v               v             v
> 
>    +               a             b
> 
> Where each box represents a cons cell, with the left half being the
> car and the right half being the cdr.
> 
> In CL, a parenthesis is a mechanism to trivially transform between
> a textual representation of lisp code, and the lisp code itself.
> Some people call this code "the internal form", but I don't
> believe that this does it justice; I view it as the "real" form
> of the lisp code; it is simply a hard form to describe without
> a textual representation of some sort.
> 
> Finally, you have seen many Lispers point out that parens disappear
> for them.  What is this phenomenon, and when does it happen?  I
> believe that it occurs when the programmer realizes that lisp code
> is not "what you see", but instead what it actually represents.
> 
> --
> Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
> 1995 University Ave Suite 275  Berkeley, CA 94704
> Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Duane Rettig
Subject: Re: What are parentheses for?
Date: 
Message-ID: <4itt5llqa.fsf_-_@beta.franz.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Duane-
> 
> A very thought provoking post. Thanks!

You're welcome.

> I guess I am seeing Lisp or Scheme programming right now as primarily
> involving defining tree structures. That is done with a typographical
> convention involving nesting parenthetical lists. 

Yes, and tree structures are often represented textually in intented
outline form.  However, it is a very space-intensive representation,
and takes up a lot of vertical real-estate.

> I have no interest in replacing the parens with similar character
> symbols

But don't you see?  That's precisely what you're doing!  You are
replacing some of the parens with newlines and appropriate tabs.
There are two ways to do this:

 1. Replace _all_ parens with newline/tab combinations for a completely
paren-free representation.

 2. Replace only parens that span across line boundaries, leaving
parens intact within a line.

#1 has the disadvantage of being extremely wasteful of vertical
space.  I assume from your posts that you do not propose or approve
of this method.

#2, which you seem to be espousing, is more complex because
it does not have one way to represent form, but two.  This
carries with it the added burden of not being able to see that
two forms are identical.  Note that you give an example of precisely
this ambiguity:

> Example:
> 
>   define
>     foo string
>     print string
> 
> or:
> 
>   define (foo string) (print string)
> 
> is equivalent to:
> 
>   (define (foo string) (print string))

Note that the traditional lisp/scheme syntax has only one form of
the expression, though you have much freedom to add or remove
line real-estate to make the form more readable, as in

(define (foo string)
  (print string))

or

(define
 (foo string)
 (print string))

Though the lines are different, the forms are the same and retain their
identity no matter how you edit them, and comparison tools that ignore
whitespace will tell you that the forms are all identical.  Your proposal
does not allow this. In fact, the only way to actually make it consistent
is to go to style #1 (above) and remove the redundancy that hybrid
indentation/parens gives.

My final points are

 - Parens _are_ the simplest representation of the "internal" lisp code
structure, and all other ways to represent such structure are either
identity transforms on the paren style, or else more complex.

 - If you want to program in CL, you need to get past the syntax issue
and learn how to program lisp code, rather than worrying about text.
If you are coming from a scheme background, it will be harder, but a
few months diving into a well-written CL program will give you a good
feel for why CL programmers tend to ignore the paren issue.

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Paul Fernhout
Subject: Re: What are parentheses for?
Date: 
Message-ID: <3996B7FA.A4A043A8@kurtz-fernhout.com>
Duane-

Thanks for the reply.

Regarding vertical space intensiveness of the format, you definitely
have a point. A fully indented S-expression will undoubtedly cover more
lines than a fully parenthesized one. I think this is a weakness to the
approach, because in general, the more of a routine I can see at once
the better I can understand it (and the quicker). However, by including
some parenthesized or open-bracket expressions, the number of lines can
be brought to a comparable number (and with slightly less total width).
One can always hope that if the expression is vertical enough, it would
be narrow enough that one might have multiple columns on the screen at
once (like reading chinese characters). Whether this would work out in
practice is another story.

You have a very good point that I am replacing parens with other
characters. I was specifically referring to your bracket example when I
said "similar", but nonetheless you point holds.

I think the issue of whether it is easier to see the identicality of a
fully parenthesized S-expressions with multiple indentations, as opposed
to various indentational styles (some including parens, some not) in a
syntactically significant indentational style is well made. However,
this may be more an issue of experience. I don't know for sure. 

I think the whitespace comparison is also well put. However, in
practice, in say a version control system, one could compare the actual
S-expressions or perhaps accept that sometimes you'd see a change in
appearance when there was no change in structure when doing your diffs
in a version control system. I think there are some cases in Lisp as
well where something similar might be the case -- such as if an argument
could either be a symbol or a list with one symbol and they are
processed the same. Granted, the structure is not the same in such a
case, but the behavior might be.

To an extent, "simplest" may be in the eyes of the beholder, based on
what one already knows how to do, and what one values (or what one
readily "chunks"). Having prior experience with Python and Occam,
indentation to me seems "simplest" (granted I don't know from experience
whether this could really work out well in Lisp). For one with lots of
Lisp experience, one would expect parentheses to seem "simplest". This
applies even if the various representational systems can be easily
transformed into each other (and thus define the same S-expressions).
What we could do is quantify each approach -- number of keystrokes to
enter (with or without a good editor), number of total characters on the
screen, number of non-white space characters on the screen, complexity
of parsing or printing code, number of formatting rules to learn,
similarity to what people are used to in other contexts (say outlines),
or compatibility with existing editing and communications infrastructure
(re whitespace preservation). Most of those have been several subtopics
within this thread (although maybe exact figures were never listed).
Still, even if one had all those figures, deciding which ones were most
important (how to weight them) could still be a subject of personal
opinion -- especially since we are at this point comparing an approach
that works (Lisp fully parenthesized) with an approach that is still at
this point vaporware (syntactically meaningful indentation in a
Lisp/Scheme context).

I think almost everyone on this newgroup would agree with you -- that is
is a common experience that if one sticks with Lisp or Scheme long
enough (however long that is, certainly a few months sounds long enough,
though some might argue a few days or weeks is good enough) the
parentheses disappear. One analogy would be that parentheses disappear
to experienced Lisp programmers like water must disappear to fish (or
air to humans). And I certainly would agree this learning curve is worth
following, given the absence of other in-place options and the power and
elegance of Lisp and Scheme.

Thanks again for your 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


Duane Rettig wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > Duane-
> >
> > A very thought provoking post. Thanks!
> 
> You're welcome.
> 
> > I guess I am seeing Lisp or Scheme programming right now as primarily
> > involving defining tree structures. That is done with a typographical
> > convention involving nesting parenthetical lists.
> 
> Yes, and tree structures are often represented textually in intented
> outline form.  However, it is a very space-intensive representation,
> and takes up a lot of vertical real-estate.
> 
> > I have no interest in replacing the parens with similar character
> > symbols
> 
> But don't you see?  That's precisely what you're doing!  You are
> replacing some of the parens with newlines and appropriate tabs.
> There are two ways to do this:
> 
>  1. Replace _all_ parens with newline/tab combinations for a completely
> paren-free representation.
> 
>  2. Replace only parens that span across line boundaries, leaving
> parens intact within a line.
> 
> #1 has the disadvantage of being extremely wasteful of vertical
> space.  I assume from your posts that you do not propose or approve
> of this method.
> 
> #2, which you seem to be espousing, is more complex because
> it does not have one way to represent form, but two.  This
> carries with it the added burden of not being able to see that
> two forms are identical.  Note that you give an example of precisely
> this ambiguity:
> 
> > Example:
> >
> >   define
> >     foo string
> >     print string
> >
> > or:
> >
> >   define (foo string) (print string)
> >
> > is equivalent to:
> >
> >   (define (foo string) (print string))
> 
> Note that the traditional lisp/scheme syntax has only one form of
> the expression, though you have much freedom to add or remove
> line real-estate to make the form more readable, as in
> 
> (define (foo string)
>   (print string))
> 
> or
> 
> (define
>  (foo string)
>  (print string))
> 
> Though the lines are different, the forms are the same and retain their
> identity no matter how you edit them, and comparison tools that ignore
> whitespace will tell you that the forms are all identical.  Your proposal
> does not allow this. In fact, the only way to actually make it consistent
> is to go to style #1 (above) and remove the redundancy that hybrid
> indentation/parens gives.
> 
> My final points are
> 
>  - Parens _are_ the simplest representation of the "internal" lisp code
> structure, and all other ways to represent such structure are either
> identity transforms on the paren style, or else more complex.
> 
>  - If you want to program in CL, you need to get past the syntax issue
> and learn how to program lisp code, rather than worrying about text.
> If you are coming from a scheme background, it will be harder, but a
> few months diving into a well-written CL program will give you a good
> feel for why CL programmers tend to ignore the paren issue.
> 
> --
> Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
> 1995 University Ave Suite 275  Berkeley, CA 94704
> Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Paolo Amoroso
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses  ...)
Date: 
Message-ID: <QbWXOTVrlqjKKdy1qRvRQRAMXM6u@4ax.com>
On Sat, 12 Aug 2000 18:35:52 -0400, Paul Fernhout
<··········@kurtz-fernhout.com> wrote:

> affecting any other aspects of the language. My direction is in the
> direction Edward Tufte might call "removing Chart Junk" where I define
> edge parentheses as "Chart Junk". I can't say Tufte would necessarily

Charts are mainly intended for presentation and are not usually edited,
compiled or processed with other tools. For presentation purposes
pseudocode may be better than actual source code.


Paolo

P.S.
Speaking of visual clutter: what about reducing the amount of material
quoted in your articles? :)
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Chris Page
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses  ...)
Date: 
Message-ID: <B5BD39AC.54F9%page@best.NOSPAM.com>
in article ····························@4ax.com, Paolo Amoroso at
·······@mclink.it wrote on 2000.08.14 04:00:

> On Sat, 12 Aug 2000 18:35:52 -0400, Paul Fernhout
> <··········@kurtz-fernhout.com> wrote:
> 
>> affecting any other aspects of the language. My direction is in the
>> direction Edward Tufte might call "removing Chart Junk" where I define
>> edge parentheses as "Chart Junk". I can't say Tufte would necessarily
> 
> Charts are mainly intended for presentation and are not usually edited,
> compiled or processed with other tools. For presentation purposes
> pseudocode may be better than actual source code.

One of my guiding principles about programming is:

    Code is read a lot more times than it is written. The moment after a
programmer finishes typing a piece of code, working with the code becomes a
maintenance task.

So, being able to read and explore code is of paramount importance. Having
advanced browsing tools is far more important than having an advanced editor
(not that that's not important).

But most important of all is that the code be presented in the most readable
way possible. "Chart Junk" should be removed. The challenge is to create an
editor that can present code sans "Chart Junk", yet still allow for easy
editing.

For example, in C, the braces { } that delimit blocks are noise if the code
is indented correctly. They are just there to help the parser, since it
knows nothing about indentation. Humans have no trouble reading correctly
indented C code without the braces.

So an editor with good presentation could omit displaying the braces, but
still allow them during input. They could be treated as editor commands (to
start/end a block) and not literally part of the program being edited.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: What are parentheses for? (was Lisp/Scheme with less 	parentheses  ...)
Date: 
Message-ID: <sfwu2cnluku.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> But most important of all is that the code be presented in the most readable
> way possible.

I partly agree with this.  

This is why I don't want a program necessarily changing the presentation 
from what I specify as author.  Until someone solves the
AI problem in its full generality, I think it's improper to suppose
that a tool will have better sense than a person about how to
optimally present a piece of code.

Also, there's a statistically quite high probability that the maintainer
will be the author.  And then I *definitely* think the author's idea of how
it should have been presented, even if it's "upside down and backward",
exceeds whatever the machine can offer.

On the other hand, surely no one would argue with a tool that provides a 
temporary, side-effect free, re-presentation of a program in whatever chart
or tabular format as long as it doesn't lose the original authoring shape.
Such a tool is simply useful to whoever wants to use it on whatever occasion
they want to call it but is not required to be called by anyone and won't 
have any effect where not requested.

This discussion can only be meaningful when the effect is forced on the 
author by later tools without cooperation of the author.

> Chris Page
> Mac OS Guy
> Palm, Inc.
> 
> let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");

For example, you might think this was the best presentation of your name, but
my tool might prefer to re-present this mail-to information without all those
messy parens and double-quotes, so my fellow newsgroup readers could see a 
"sketch" of your address in clearer form.  You wouldn't want that happening
automatically, would you?  Feeling a sudden urge for the author to retain
after-the-fact control of presentation?  Heh heh...
From: Chris Page
Subject: Re: What are parentheses for? (was Lisp/Scheme with less  parentheses  ...)
Date: 
Message-ID: <B5BE3F07.566C%page@best.NOSPAM.com>
in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.14 08:40:

> On the other hand, surely no one would argue with a tool that provides a
> temporary, side-effect free, re-presentation of a program in whatever chart
> or tabular format as long as it doesn't lose the original authoring shape.
> Such a tool is simply useful to whoever wants to use it on whatever occasion
> they want to call it but is not required to be called by anyone and won't
> have any effect where not requested.

I think a truly useful dynamic display-based editor would allow for authors
to add information about how to present the code. A simple example is the
ability to manually add line-breaks. A more advanced case to consider is
when it's desirable to layout several lines of code with tabs at various
points in each line to produce columns that highlight the differences in
each line.

I'm not suggesting that the displayer try to be overly smart about code
formatting, either. I'm suggesting that it allow each human reader to decide
how to display the program, hopefully based upon simple rules, and that one
or more professionally designed display formats be included with the tool to
minimize the typical amount of customization per user.

> This discussion can only be meaningful when the effect is forced on the
> author by later tools without cooperation of the author.

But even if authors are given the option to control the presentation,
readers should still be allowed to ignore or override them if they wish. You
already have this ability today with plain text files and a text editor.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Paul Fernhout
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses  ...)
Date: 
Message-ID: <3999C697.97434DDD@kurtz-fernhout.com>
Darius Bacon wrote:
> 
> In comp.lang.lisp you write:
> 
> >If Lisp code is what it represents, than one could view what I am
> >proposing as a way to create Lisp and Scheme representations so that
> >"what you see" is as close as possible to that underlying structure,
> >with a minimum of extra characters, given that 2D space layouts can in
> >some circumstances make sense to the human eye. In effect, I am trying
> >to make the tree structure implicit in all Lisp S-expressions explicit
> >on the page, and without anything unneeded.
> 
> You might like to check out a similar scheme I posted to comp.lang.scheme
> about a couple years ago (sorry, I don't have the text handy right now
> but it's probably easily findable).  It was different in using an
> offsides rule for indentation, like Haskell or Python, rather than
> making spaces directly significant.  Also I used the : character for
> lists to the end of the current line.  So code looked like this:
> 
> define: factorial n
>   if: = n 0
>       1
>       * n
>         factorial: - n 1
> 
> -Darius

Darius-

Ah, now this was more the sort of response I was looking for. There are
rarely any new ideas. Thanks for the pointer. I guess great minds think
alike! :-)

I looked for your article in DejaNews (all posts) but it may have
scrolled from their archive as I couldn't find it. Can you (or someone
else) point me to another archive which has your comments and the
replies? It wasn't in this FAQ:
 
http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/lang/scheme/part2/faq-doc-3.html

If not, can you summarize people's reactions briefly (same as
currently?)

How did you handle indenting lists of lists?

Did you get anything to work? 
If so, what was the result? 
Did you or others like using it? 

I have implemented a parser before (in Python) that used arbitrary
indentation for outline processing, but I went for rigid spacing in this
proposal to avoid some (minor) practical problems that come up
(especially involving tabs) when several developers work on the same
Python code.

I got your email Sunday; I've been slow in replying because I've been
coding.

You might be interested in the implementation for Scheme I just posted
on comp.lang.lisp. I didn't want to crosspost [to comp.lang.scheme].
I guess discussing the details for Scheme should move there. 

It looks from the header that you posted this also to comp.lang.lisp,
although my news server still hasn't show it yet.
That is why I felt it OK to include the newsgroup on this reply
(also, to ensure you get proper credit for previously suggesting this).

Thanks again for the email.

-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
From: ············@my-deja.com
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <8nea2v$soq$1@nnrp1.deja.com>
In article <·················@kurtz-fernhout.com>,
  Paul Fernhout <··········@kurtz-fernhout.com> wrote:
[snip]

While a Lisp where indenting is significant has problems people have
been pointing out, I think the problems are parochial; you can largely
avoid them with a new language similar in spirit to Lisp that doesn't
try to be perfectly compatible.  I'll sketch out how after answering
your questions.

> Ah, now this was more the sort of response I was looking for. There
are
> rarely any new ideas. Thanks for the pointer. I guess great minds
think
> alike! :-)
>
> I looked for your article in DejaNews (all posts) but it may have
> scrolled from their archive as I couldn't find it. Can you (or someone
> else) point me to another archive which has your comments and the
> replies? It wasn't in this FAQ:
>
>
http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/lang/scheme/part2/faq-doc-3.html

You're right, deja's discarded all my posts older than 15 months.
Bother.  We need an archive we can depend on...

> If not, can you summarize people's reactions briefly (same as
> currently?)

There were apparently no replies at all.

> How did you handle indenting lists of lists?

At the time I figured falling back on regular Lisp notation would do
for a start; but see below for my new design.

> Did you get anything to work?
> If so, what was the result?
> Did you or others like using it?

Never bothered implementing it, since I didn't plan to use it.  I
decided to keep it in mind as a project to return to since it looked
like there were more designs worth exploring.  I guess now's the time.

[snip]
> It looks from the header that you posted this also to comp.lang.lisp,
> although my news server still hasn't show it yet.
> That is why I felt it OK to include the newsgroup on this reply
> (also, to ensure you get proper credit for previously suggesting
this).

Thanks.  My ISP's news setup is broken so I can't post directly (and
didn't try with that email, but I'll try deja.com this time).

Let's look at the possibilities if we were designing a new language
from scratch where code and data share the same notation: some way of
depicting tree structures with indentation.  Tree structures don't
have to be built out of cons pairs -- Prolog represents them with
terms like tag(leaf, leaf) where the tag is always a symbol.  If we
just follow Prolog's lead then we don't have to deal with stuff like
((())).  So what's the simplest possible format?  Maybe like

  define: factorial: n
	  if: =: n
		 0
	      1
	      *: n
		 factorial: -: n
			       1

where ``foo: bar baz'' is a tree node tagged foo with branches bar and
baz.  But that's not very fun to read; so allow multiple arguments on
the same line:

  define: factorial: n
	  if: =: n 0
	      1
	      *: n
		 factorial: -: n 1

and some freedom in where to indent a first following line:

  define: factorial: n
    if: =: n 0
	1
	*: n
	   factorial: -: n 1

All those colons for tree construction are kind of annoying, though,
so why not make them implicit, and instead put a comma where there are
two atoms *without* a colon between them:

  define factorial n
    if = n, 0
       1
       * n
	 factorial - n, 1

Another way of seeing that: it takes

  define factorial n
	 if = n
	      0
	    1
	    * n
	      factorial - n
			  1

and allows moving a line up into the preceding line if you add a
comma.  (However, now we need some extra notation for a tree node with
just a tag and no branches, to distinguish it from a simple variable.)
That's starting to look reasonable to me -- time for a bigger example.
I scanned my BDD package for a hairy-looking function and found this
one:

(define (make-node hashtable var then-node else-node)
  (if (eq? then-node else-node)
      then-node
      (let ((new-node
	     (vector
	      var then-node else-node
	      (combine-hashes
	       (hash-symbol var)
	       (combine-hashes
		(if (node? then-node) (node-hash then-node) 0)
		(if (node? else-node) (node-hash else-node) 0))))))
	(hashtable-access hashtable new-node
			  (lambda (put!) (put! #t) new-node)
			  (lambda (existing value put!) existing)))))

We can't translate it directly since it's not a Prolog-style tree
structure.  So change the notation a bit first:

(define (make-node hashtable var then-node else-node)
  (if (eq? then-node else-node)
      then-node
      (bind (val new-node
		 (vector
		  var then-node else-node
		  (combine-hashes
		   (hash-symbol var)
		   (combine-hashes
		    (if (node? then-node) (node-hash then-node) 0)
		    (if (node? else-node) (node-hash else-node) 0)))))
	(hashtable-access hashtable new-node
			  (lambda put! (put! #t) new-node)
			  (lambda (tuple existing value put!) existing)))))

Then that becomes

define make-node hashtable, var, then-node, else-node
  if eq? then-node, else-node
     then-node
     bind val new-node
	      vector var, then-node, else-node
		     combine-hashes hash-symbol var
				    combine-hashes if node? then-node
						      node-hash then-node
						      0
						   if node? else-node
						      node-hash else-node
						      0
       hashtable-access hashtable, new-node
			lambda put!
			  put! #t
			  new-node
			lambda tuple existing, value, put!
			  existing

which still looks nice enough.  I could get used to life without
parentheses.  We might still want a shorthand notation for trees that
are lists -- Prolog has one -- but that doesn't have to dominate the
language design.

I've put a crude implementation of the colon version of the notation
at http://www.smop.com/software/indent and I'll probably code up the
later stuff soon.

-Darius



Sent via Deja.com http://www.deja.com/
Before you buy.
From: Paul Fernhout
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses  ...)
Date: 
Message-ID: <399AC10C.A804BEF7@kurtz-fernhout.com>
Darius-

Thanks for the note and the replies to my questions.

You present a very interesting way to work through the identation issue.
I see you're coming at it from a slightly different perspective than I
(Prolog?) -- focusing on the issue of "branching" more than "listing".
Both are in some way equivalent, but each way of thinking produces
somewhat differing resulting styles. 

If I understand the approach you outlined, I see you use an internal
space as a sort of "join, starting a new embedded list except when after
a first element in a list" operator, and "," as sort of as a "join in
the same list" operator, and indentation as sort of another "join,
starting a new embedded list" operator (but without the extra
qualification regarding being a first element).

I didn't quite follow why one has to change the notation -- example,
replacing "(put!)" with "put!" or introducing "tuple". (I'm not up on
Prolog, beyond playing with TurboProlog for a few hours a few times a
very long time ago.)

While there is a lot of value to defining completely new languages, and
I can see the potential value of maybe starting a new culture unfettered
by the prejudices of the old (and perhaps having its own ones :-), I was
trying to make as small a change as I could to Lisp and Scheme to make
syntactically significant indentation work (focusing on the issue of
eliminating only parentheses on the "edges" of lines). Thus, one rarely
has to use any extra punctuation not found in Lisp or Scheme (the
exception is currently a "." used to indicate a list starting typically
with a list). It is true in practice one would use parens in many lines,
for short expressions, although once can code without parens if desired
as in your approach (but still requiring the "." operator and many extra
lines, probably many more than your approach, as yours definitely seems
to be more line efficient for these (and perhaps all) examples). 

On the other hand, sometimes if you are going to do things differently,
it's best to do them really differently so people don't get
unintentionally confused by unexpect behavior in something that looks
otherwise normal.

By the way, I ran the example you gave through the IndentWriter.scm code
I posted and got this:

define
 make-node hashtable var then-node else-node 
 if
  eq? then-node else-node 
  then-node
  let
   .
    new-node
     vector
      var
      then-node
      else-node
      combine-hashes
       hash-symbol var 
       combine-hashes
        if (node? then-node) (node-hash then-node) 0 
        if (node? else-node) (node-hash else-node) 0 
   hashtable-access
    hashtable
    new-node
    lambda (put!) (put! #t) new-node 
    lambda (existing value put!) existing 

Textually, if you put parens on the edges (accounting for indentation,
and replacing "." with "(", and not adding parens when there is just one
element on a line), you get back the same Lisp expression.

I read that resulting indented expresiosn using the IndentReader.scm and
after hand indenting the single line result in DrScheme, I got back:

(define 
  (make-node hashtable var then-node else-node) 
  (if (eq? then-node else-node) 
    then-node 
    (let ((new-node 
           (vector 
            var then-node else-node 
            (combine-hashes 
             (hash-symbol var) 
             (combine-hashes 
              (if (node? then-node) (node-hash then-node) 0) 
              (if (node? else-node) (node-hash else-node) 0)))))) 
      (hashtable-access hashtable new-node 
                        (lambda (put!) (put! #t) new-node) 
                        (lambda (existing value put!) existing)))))

Thanks again for the note. I'd like to get updates on how the approach
you outline works out in practice. 

-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


············@my-deja.com wrote:
> 
> In article <·················@kurtz-fernhout.com>,
>   Paul Fernhout <··········@kurtz-fernhout.com> wrote:
> [snip]
> 
> While a Lisp where indenting is significant has problems people have
> been pointing out, I think the problems are parochial; you can largely
> avoid them with a new language similar in spirit to Lisp that doesn't
> try to be perfectly compatible.  I'll sketch out how after answering
> your questions.
> 
> > Ah, now this was more the sort of response I was looking for. There
> are
> > rarely any new ideas. Thanks for the pointer. I guess great minds
> think
> > alike! :-)
> >
> > I looked for your article in DejaNews (all posts) but it may have
> > scrolled from their archive as I couldn't find it. Can you (or someone
> > else) point me to another archive which has your comments and the
> > replies? It wasn't in this FAQ:
> >
> >
> http://www.cs.cmu.edu/Web/Groups/AI/html/faqs/lang/scheme/part2/faq-doc-3.html
> 
> You're right, deja's discarded all my posts older than 15 months.
> Bother.  We need an archive we can depend on...
> 
> > If not, can you summarize people's reactions briefly (same as
> > currently?)
> 
> There were apparently no replies at all.
> 
> > How did you handle indenting lists of lists?
> 
> At the time I figured falling back on regular Lisp notation would do
> for a start; but see below for my new design.
> 
> > Did you get anything to work?
> > If so, what was the result?
> > Did you or others like using it?
> 
> Never bothered implementing it, since I didn't plan to use it.  I
> decided to keep it in mind as a project to return to since it looked
> like there were more designs worth exploring.  I guess now's the time.
> 
> [snip]
> > It looks from the header that you posted this also to comp.lang.lisp,
> > although my news server still hasn't show it yet.
> > That is why I felt it OK to include the newsgroup on this reply
> > (also, to ensure you get proper credit for previously suggesting
> this).
> 
> Thanks.  My ISP's news setup is broken so I can't post directly (and
> didn't try with that email, but I'll try deja.com this time).
> 
> Let's look at the possibilities if we were designing a new language
> from scratch where code and data share the same notation: some way of
> depicting tree structures with indentation.  Tree structures don't
> have to be built out of cons pairs -- Prolog represents them with
> terms like tag(leaf, leaf) where the tag is always a symbol.  If we
> just follow Prolog's lead then we don't have to deal with stuff like
> ((())).  So what's the simplest possible format?  Maybe like
> 
>   define: factorial: n
>           if: =: n
>                  0
>               1
>               *: n
>                  factorial: -: n
>                                1
> 
> where ``foo: bar baz'' is a tree node tagged foo with branches bar and
> baz.  But that's not very fun to read; so allow multiple arguments on
> the same line:
> 
>   define: factorial: n
>           if: =: n 0
>               1
>               *: n
>                  factorial: -: n 1
> 
> and some freedom in where to indent a first following line:
> 
>   define: factorial: n
>     if: =: n 0
>         1
>         *: n
>            factorial: -: n 1
> 
> All those colons for tree construction are kind of annoying, though,
> so why not make them implicit, and instead put a comma where there are
> two atoms *without* a colon between them:
> 
>   define factorial n
>     if = n, 0
>        1
>        * n
>          factorial - n, 1
> 
> Another way of seeing that: it takes
> 
>   define factorial n
>          if = n
>               0
>             1
>             * n
>               factorial - n
>                           1
> 
> and allows moving a line up into the preceding line if you add a
> comma.  (However, now we need some extra notation for a tree node with
> just a tag and no branches, to distinguish it from a simple variable.)
> That's starting to look reasonable to me -- time for a bigger example.
> I scanned my BDD package for a hairy-looking function and found this
> one:
> 
> (define (make-node hashtable var then-node else-node)
>   (if (eq? then-node else-node)
>       then-node
>       (let ((new-node
>              (vector
>               var then-node else-node
>               (combine-hashes
>                (hash-symbol var)
>                (combine-hashes
>                 (if (node? then-node) (node-hash then-node) 0)
>                 (if (node? else-node) (node-hash else-node) 0))))))
>         (hashtable-access hashtable new-node
>                           (lambda (put!) (put! #t) new-node)
>                           (lambda (existing value put!) existing)))))
> 
> We can't translate it directly since it's not a Prolog-style tree
> structure.  So change the notation a bit first:
> 
> (define (make-node hashtable var then-node else-node)
>   (if (eq? then-node else-node)
>       then-node
>       (bind (val new-node
>                  (vector
>                   var then-node else-node
>                   (combine-hashes
>                    (hash-symbol var)
>                    (combine-hashes
>                     (if (node? then-node) (node-hash then-node) 0)
>                     (if (node? else-node) (node-hash else-node) 0)))))
>         (hashtable-access hashtable new-node
>                           (lambda put! (put! #t) new-node)
>                           (lambda (tuple existing value put!) existing)))))
> 
> Then that becomes
> 
> define make-node hashtable, var, then-node, else-node
>   if eq? then-node, else-node
>      then-node
>      bind val new-node
>               vector var, then-node, else-node
>                      combine-hashes hash-symbol var
>                                     combine-hashes if node? then-node
>                                                       node-hash then-node
>                                                       0
>                                                    if node? else-node
>                                                       node-hash else-node
>                                                       0
>        hashtable-access hashtable, new-node
>                         lambda put!
>                           put! #t
>                           new-node
>                         lambda tuple existing, value, put!
>                           existing
> 
> which still looks nice enough.  I could get used to life without
> parentheses.  We might still want a shorthand notation for trees that
> are lists -- Prolog has one -- but that doesn't have to dominate the
> language design.
> 
> I've put a crude implementation of the colon version of the notation
> at http://www.smop.com/software/indent and I'll probably code up the
> later stuff soon.
> 
> -Darius
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
From: ··········@my-deja.com
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <8nda5u$oie$1@nnrp1.deja.com>
What are parentheses for?

This is a question I've been wanting to ask about for a long time.
I've read all sorts of lisp books and haven't got an adequate answer
----------------------------------------------------------
my understanding:
lambda expression evaluation/reduction
all lisp languages are based on the lambda calculus

lisp function:       (f x y z)
prolog function:   f(x,y,x)

but....
-----------------------------------------------------------

Why cons cells,
Why s-expressions?

Are there straightforward ways to think about the mapping between them?
For instance if you have trees represented one way by lists/s-expressions
and you want to transform these trees to another tree format?

Lisp-lists/cons-cell-structures sure do allocate a lot of storage
but you don't seem to be able to do much with them.
Can you index into big cons trees and change values or
insert cons cells (cons cell surgery)  (set-cdr in scheme can do this),

there seems to be a real limit to what you can do destructively in lisp
you can destructively push onto the front of a list, but you have to write
your own macro if you want to push onto the end (compare push shift in
Perl)

These are questions/observations I have from experimenting with Lisp.

Any answers would be appreciated.

Jon Fernquest
··········@hotmail.com


Sent via Deja.com http://www.deja.com/
Before you buy.
From: Erik Naggum
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <3175408485778175@naggum.net>
* ··········@my-deja.com
| all lisp languages are based on the lambda calculus

  Lambda calculus is a means of reasoning about computation.  It is
  universal, like mathematics, not limited to any particular languages.

| Why cons cells,

  Why are you concerned about them?  They're an implementation of
  lists, which is a way to describe nested structure neatly.  In
  principle, any other implementation would be just as useful, even
  something as uselessly complex like DOM used with XML, but that
  serves no purpose at all.

| Why s-expressions?

  You're looking for the history of Lisp.  But note that atoms, like
  symbols, numbers, vectors, etc, are symbolic expressions.

| Are there straightforward ways to think about the mapping between
| them?

  Huh?

| For instance if you have trees represented one way by lists/
| s-expressions and you want to transform these trees to another tree
| format?

  It's extremely unclear what you really are asking for.  Of course
  it's trivial to express a tree any other way, but that is not a
  transformation, and transformations aren't related to formats of
  representation.

| Lisp-lists/cons-cell-structures sure do allocate a lot of storage

  Oh, really?  Well, this statement marks you as clueless and arrogant
  enough to post unfounded statements without any shame.  What are you
  _really_ after?

  Any list structure (that is, not vectors), will have to consist of
  at least one pointer per element, called "next".  If you should be
  able to make lists of all kinds of objects, you can either have a
  "next" element in all kinds of objects (or arrange for different
  kinds of objects in the free and in lists, which is even dumber) or
  you can have a cons cell which consists of two pointers, one to the
  object, one to the next element.  Since most naive programmers who
  implement lists think they need doubly-linked lists, which they
  don't except in very rare cases, you don't waste any space at all.

  It is regrettable that Lisp systems let users see allocation data
  when they are so amazingly clueless as to be unable to understand
  the choice of models involved and what the information means and
  doesn't mean.

| but you don't seem to be able to do much with them.

  *laugh*

| Can you index into big cons trees and change values or insert cons
| cells (cons cell surgery)  (set-cdr in scheme can do this),

  Yes.  (Obviously.)

| there seems to be a real limit to what you can do destructively in
| lisp

  Why do you flaunt your ignorance so shamelessly?  Just flame bait?
  Aren't you even aware that programmers have been using Lisp for over
  40 years?  Do you believe that you're the only non-idiot to have
  picked up Lisp?

  People don't use destructive operations as much in Lisp because they
  have better ways of doing what is normally done destructively, and
  they don't want to get into object ownership protocols, but when you
  have to, everything you need is there.  Of course.

| you can destructively push onto the front of a list, but you
| have to write your own macro if you want to push onto the end
| (compare push shift in Perl)

  Oh, geez, it's a Perl-head.  What do you think the "macro" does if
  you can't already do it in the language?  Sheesh.  If you really
  have to, do:

(setf (cdr (last <list>)) (list <whatever>))

| These are questions/observations I have from experimenting with Lisp.

  Really?  What do you think happens if you "experiment" with a hammer
  and a bunch of nails?  Do you get a useful grasp of the art and
  craft of carpentry, even an inkling of what is involved?  After
  pounding a dozen nails into your living room table, do you exclaim
  "you can't possibly build anything with this!"?

| Any answers would be appreciated.

  It will require concentration and effort, but try a textbook.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: ··········@my-deja.com
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <8nfn2c$ibc$1@nnrp1.deja.com>
Erik Naggum writes:
>Cons cells are "an implementation of   lists, which is a way to describe
>nested structure neatly. "

Isn't notation supposed to convey the structure of the thing
represented, well:

for the s-expression: (a b c d e f)
the cons-structure is a binary tree:
(a (b (c (d (e (f ()))))))
(a . (b . (c . (d . (e . (f . ()))))))

> (setf x '(a . (b . (c . (d . (e . (f . ())))))) )
(A B C D E F)

Dot notation conveys the structure of cons cell trees better
than s-expression's do.

---------------------------------------------------------

I wrote:
>> you can destructively push onto the front of a list, but you
>> have to write your own macro if you want to push onto the end
>> (compare push shift in Perl)

Erick Naggum wrote:
>Oh, geez, it's a Perl-head.  What do you think the "macro" does if
you can't already do it in the language?  Sheesh.
If you really have to, do:

(setf (cdr (last <list>)) (list <whatever>))

I write:
What about:

>(setf x '(a b c d (e f g (h i))))
(A B C D (E F G (H I)))
> (setf (cdr (last x)) 'j)
j
> x
(A B C D (E F G (H I)) . J)

Now I don't even have a proper list anymore, but with:

(defmacro revpush (obj stack)
   `(if (null ,stack)
       (setf ,stack (cons ,obj ,stack))
       (nconc ,stack (list ,obj))
   )
)

(defmacro revpop (stack)
   `(prog1
      (car (last ,stack))
      (setf ,stack (subseq ,stack 0 (- (length ,stack) 1))) ))

> (setf x '(a b c d (e f g (h i))))
(A B C D (E F G (H I)))
> (revpush 'j x)
(A B C D (E F G (H I)) J)

which brings me to another point that I don't fully understand...
people tell you to avoid using eval because it is
expensive, but every macro call in lisp first does a
textual substitution followed by an eval, so doesn't this make all
macros expensive things to avoid if you want to write fast code?

-------------------------------------------------
SICP is full of examples where recursion makes a computation
concise and meaningful, but using recursion to read
records out of a simple sequential file like Slade's Lisp book?
Keep what is simple, simple...like Perl:

while ($line = <infile>) {
   print $line;
}

There's a regular expression matcher in the CMU AI
archive called matcher... two mutually recursive functions each with
multiple levels of embedded cond statements the second function uses
a continuation stack, not exactly easy to understand or modify and I had
to modify it because it doesn't collect the substrings it matches as it goes
along like most modern regular expression engines.

Using an iterator instead of recursion would have made it easier to
modify and reuse. "When trees have a dozen kind of nodes (like the
parse tree of a regular expression),  the recursive pattern becomes
larger and much harder to follow." (DDJ, July 2000, 12)

---------------------------------------------------------------------
> Aren't you even aware that programmers have been using Lisp for over
40 years?

Yep, what sustained it for so long? USA defense department star wars
big bucks funding research at a lot of universities maybe? Lack of
competition from languages with similar features? It's popularity zoomed
to an incredible peak in the late 80's (end of cold war) and is now at an all
time low. There must be something that people (outside of universities
and research institutions) find objectionable about it because they
voted with their feet which is what happens when consumer spending
rather than defense department spending drives the market for software.

------------------------------------------------------------

Erik Naggum writes:
> Lambda calculus is a means of reasoning about computation.
> It is universal, like mathematics, not limited to any particular languages

doing the lambda calculus (or evaling) is exactly what lisp lists are made
for. car gives a function, cdr gives a list of arguments to apply the function
to

but scheme lists are closer to the lambda calculus than common lisp lists
so I use Scheme...(examples supplied upon request)
------------------------------------------------------------
Erik Naggum writes:
>transformations aren't related to formats of representation

Here is the input to a popular linguistic diagrammer utility:

clig {tree {plain-text S}
      {tree {plain-text NP}
            {tree {plain-text DET}
                  {plain-text The}}
            {tree {plain-text N}
                  {plain-text postman}}}
      {tree {plain-text VP}
            {tree {plain-text V}
                  {plain-text bites}}
            {tree {plain-text NP}
                  {tree {plain-text DET}
                        {plain-text the}}
                        {tree {plain-text N}
                        {plain-text dog}}}}}

That creates a tree diagram for the following parse tree:
(S (NP (DET The) (N postman)) (VP (V bites) (NP (DET the) (N dog)
(ADV vigorously) ))

The transformation is straightforward, prefix all internal nodes
with "tree" and all leaf nodes with "plain-text."
It's trivial to do with regular expressions or a Perl list,
but could I do the transformation by recursing through lisp list?
Not in any natural way, because the cons cell
structure is a binary tree.

-----------------------------------------------------------------

Finally, if I have:

(setf x '(a b c d e f g h l))
(setf y '(i j k))

and I want:
(a b c d e f g h i j k l)

how do I splice in (i j k)

I know how I'd do it in Perl and Scheme, but in Common Lisp?

But I'll stop now, run back to my hole and hide from the evil lisp
ogre who chopped my initial posting to pieces.

Thank you for paying attention to me.

Bayinnaung
··········@hotmail.com









Sent via Deja.com http://www.deja.com/
Before you buy.
From: Erik Naggum
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <3175493964770936@naggum.net>
* ··········@my-deja.com
| Erick Naggum wrote:

  If you can't even pay enough attention to get people's names right,
  please drop programming.  Thank you.

  I suggested:

(setf (cdr (last <list>)) (list <whatever>))

  You tried:

(setf (cdr (last x)) 'j)

  and then you complained:

| Now I don't even have a proper list anymore ...

  So pay attention!  Sheesh!

| people tell you to avoid using eval because it is
| expensive, but every macro call in lisp first does a
| textual substitution followed by an eval, so doesn't this make all
| macros expensive things to avoid if you want to write fast code?

  This is all _completely_ wrong.  So wrong, in fact, that it won't do
  you any good to have it explained.  Go read a textbook, _now_!

| Yep, what sustained it for so long?

  People who were willing to study something before they make wildly
  exaggerated and completely idiotic claims about it.

| It's popularity zoomed to an incredible peak in the late 80's (end
| of cold war) and is now at an all time low.

  Really?  You _are_ just posting moronic flame bait.

| Thank you for paying attention to me.

  Yes, unlike you, I do pay attention.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Rainer Joswig
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <joswig-5064B0.06163317082000@news.is-europe.net>
In article <············@nnrp1.deja.com>, ··········@my-deja.com wrote:

> which brings me to another point that I don't fully understand...
> people tell you to avoid using eval because it is
> expensive, but every macro call in lisp first does a
> textual substitution followed by an eval, so doesn't this make all
> macros expensive things to avoid if you want to write fast code?

a) macros are not about "textual" substitution.
   Macros do their work on preparsed S-expressions.

b) Macros are expanded once at compile-time.

c) Read more about how macros work in Paul Graham's book
   "On Lisp". For reference material consult the Hyperspec.

> ---------------------------------------------------------------------
> > Aren't you even aware that programmers have been using Lisp for over
> 40 years?
> 
> Yep, what sustained it for so long? USA defense department star wars
> big bucks funding research at a lot of universities maybe? Lack of
> competition from languages with similar features? It's popularity zoomed
> to an incredible peak in the late 80's (end of cold war) and is now at an all
> time low.

No it isn't. Lisp is widely in use. We have several commercial
vendors, several high-quality free implementations and
several free implementations in development. Just
browse http://www.lisp.org/ for more information about
Lisp. Or see the list of customer's applications at the Franz
website http://www.franz.com/ .

Hey, even hip companies like CommerceOne are using Lisp in
their applications.

> but scheme lists are closer to the lambda calculus than common lisp lists
> so I use Scheme...(examples supplied upon request)

This sounds confused.

> Finally, if I have:
> 
> (setf x '(a b c d e f g h l))
> (setf y '(i j k))
> 
> and I want:
> (a b c d e f g h i j k l)
> 
> how do I splice in (i j k)
> 
> I know how I'd do it in Perl and Scheme, but in Common Lisp?

Destructive:

(let ((z (last x)))
  (nconc (nbutlast x) y z))

Non-destructive:

(append (butlast x) y (last x))

-- 
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: David Bakhash
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <m37l9gac3f.fsf@cadet.dsl.speakeasy.net>
Rainer Joswig <······@corporate-world.lisp.de> writes:

> b) Macros are expanded once at compile-time.

this line can be misleading too.  Macros are expanded at compile-time, 
but they are expanded recursively, over and over again (not really
"once") until they are done.  The point is that the guts of the
compiler are compiling code that has already been expanded, and so
while things are definitely being eval'd, it's happening in the
compiler's environment, and not at run-time (though it can happen then 
too, of course).

I know that that's more or less what Rainer meant; just wanted to
clarify it.

> ··········@my-deja.com wrote:

> SICP is full of examples where recursion makes a computation
> concise and meaningful, but using recursion to read
> records out of a simple sequential file like Slade's Lisp book?
> Keep what is simple, simple...like Perl:

> while ($line = <infile>) {
>    print $line;
> }

CL makes this particular example quite easy too:

;; unchecked...
(with-open-file (file "file.txt")
  (loop for line = (read-line file nil)
    while line
    do (print line)))

There are several ways to do this, as with Perl.  In some
implementations of loop you can even write extensions so that, if you
wanted, you could write something like:

(loop for line being the lines of "file.txt"
  do (print line))

Whatever.  It's just more expressive than what you get in these other
languages. Of course, your little program in Perl could have been
written:

open(FILE,"file.txt");
while (<FILE>) {
  print;
}

and WOW is that clear!  It's more concise than even my extended loop
syntax, but is it worthit?  I don't think so.  Sad thing is that tons
of Perl programmers write stuff like this, and it's not always evident 
what's going on (especially if someone set one of those darned magic
$<#\some-character> variables to some weird value somewhere else in
the code).

Even though I am (mysteriously) okay with Perl syntax (I say
mysteriously because I can't seem to grok C syntax, and I think Perl
is more wacky), I can see why it's hated here, and posting Perl code
here to be compared to Common Lisp code for simplicity is probably not 
going to convince people -- especially just because it's more
concise, or looks simpler to Perl hackers.  Writing trivial n-line
code where n << 100  does not say much about the language.  In fact,
if you look at the example above, even, both "regular" forms are 4
lines each, for CL and Perl.  So even there you're not getting very
much.

dave
From: Christopher Browne
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <slrn8pmudl.fr2.cbbrowne@knuth.brownes.org>
Centuries ago, Nostradamus foresaw a time when ··········@my-deja.com would say:
>Erik Naggum writes:
>>Cons cells are "an implementation of   lists, which is a way to describe
>>nested structure neatly. "
>
>Isn't notation supposed to convey the structure of the thing
>represented, well:
>
>for the s-expression: (a b c d e f)
>the cons-structure is a binary tree:
>(a (b (c (d (e (f ()))))))
>(a . (b . (c . (d . (e . (f . ()))))))
>
>> (setf x '(a . (b . (c . (d . (e . (f . ())))))) )
>(A B C D E F)
>
>Dot notation conveys the structure of cons cell trees better
>than s-expression's do.

Sure, using dot notation conveys the "physical representation" more
"precisely" than the contraction does.

In similar manner, disassembling the code into assembly language 
conveys the "physical representation" _even more precisely._  

But people wanting to _look_ at the code would generally rather have the
"higher level" representation as that may be read more conveniently.

And it is _often_ not important what the physical representation is.

Orthogonal to common bashing back and forth about "Lisp-1" (with 1
namespace) and "Lisp-2" (with more than 1 namespace) is the occasionally
expressed notion of having a Lisp that uses _vectors_ as the basic
data structure rather than _lists_.  That is effectively how APL is
implemented, which demonstrates that the idea is not utterly
preposterous, and while many properties assumed of lists wouldn't hold,
a "vector-based" system would have some useful properties of its own.

>I wrote:
>>> you can destructively push onto the front of a list, but you
>>> have to write your own macro if you want to push onto the end
>>> (compare push shift in Perl)
>
>Erick Naggum wrote:
>>Oh, geez, it's a Perl-head.  What do you think the "macro" does if
>you can't already do it in the language?  Sheesh.
>If you really have to, do:
>
>(setf (cdr (last <list>)) (list <whatever>))
>
>I write:
>What about:
>
>>(setf x '(a b c d (e f g (h i))))
>(A B C D (E F G (H I)))
>> (setf (cdr (last x)) 'j)
>j
>> x
>(A B C D (E F G (H I)) . J)
>
>Now I don't even have a proper list anymore, but with:
>
>(defmacro revpush (obj stack)
>   `(if (null ,stack)
>       (setf ,stack (cons ,obj ,stack))
>       (nconc ,stack (list ,obj))
>   )
>)
>
>(defmacro revpop (stack)
>   `(prog1
>      (car (last ,stack))
>      (setf ,stack (subseq ,stack 0 (- (length ,stack) 1))) ))
>
>> (setf x '(a b c d (e f g (h i))))
>(A B C D (E F G (H I)))
>> (revpush 'j x)
>(A B C D (E F G (H I)) J)
>
>which brings me to another point that I don't fully understand...
>people tell you to avoid using eval because it is
>expensive, but every macro call in lisp first does a
>textual substitution followed by an eval, so doesn't this make all
>macros expensive things to avoid if you want to write fast code?

The part that is "expensive" is the fact that eval compiles the
code at _RUNTIME_.

If you use other representations instead, those representations may be
compiled beforehand, and cost no time at runtime.

The more critical problem with the "abuse" of eval is that if you compile
code at runtime, you wind up losing some control over the environment
in which it gets compiled.

>SICP is full of examples where recursion makes a computation
>concise and meaningful, but using recursion to read
>records out of a simple sequential file like Slade's Lisp book?
>Keep what is simple, simple...like Perl:
>
>while ($line = <infile>) {
>   print $line;
>}

Which is why you might want to use the following macro:

(defmacro while (test &body body)
   '(do () 
        ((not ,test))
      ,@body))

Which defines a (while) structure much as you expect to find.

Alternatively, you might use something like:
(with-open-file (s "myfilename" :direction :input)
  (loop
     as line = (read-line s nil 'eof)
     until (eq line 'eof)
     do (format t "~A~%" line)))

>There's a regular expression matcher in the CMU AI
>archive called matcher... two mutually recursive functions each with
>multiple levels of embedded cond statements the second function uses
>a continuation stack, not exactly easy to understand or modify and I had
>to modify it because it doesn't collect the substrings it matches as it goes
>along like most modern regular expression engines.
>
>Using an iterator instead of recursion would have made it easier to
>modify and reuse. "When trees have a dozen kind of nodes (like the
>parse tree of a regular expression),  the recursive pattern becomes
>larger and much harder to follow." (DDJ, July 2000, 12)

... And Lisp implementations include iterators ...

It is highly common for courses on Lisp to direct themselves _solely_ to
presenting things in recursive form.  There are several reasons for this:

a) It is actually practical to do "just about everything" using
   recursion in Lisp.  In C?  Pretty impractical...

b) There's enough time in the typical "module" on Lisp to present only
   some parts of the language, usually just the stuff that was true
   of Lisp 30 years ago.

   You don't get around to presenting hash tables, arrays, and such
   in a 4 week module.

c) SICP specifically addresses itself to the theory of computer science;
   it is _not_, by a _distant_ shot, a complete presentation of Scheme.

   It doesn't touch on vectors or continuations, which are two of the
   critical control and data structures of Scheme.  By limiting yourself
   to what is presented in SICP, while you can get a _good_ grasp of
   computing, you're certainly _NOT_ getting a grasp of the idiomatic
   use of Lisp.

>> Aren't you even aware that programmers have been using Lisp for over
>40 years?
>
>Yep, what sustained it for so long? USA defense department star wars
>big bucks funding research at a lot of universities maybe? Lack of
>competition from languages with similar features? It's popularity zoomed
>to an incredible peak in the late 80's (end of cold war) and is now at an all
>time low. There must be something that people (outside of universities
>and research institutions) find objectionable about it because they
>voted with their feet which is what happens when consumer spending
>rather than defense department spending drives the market for software.

There's a lot of politics go down the road, and Common Lisp decidedly
suffers from being along the intersection of the "battle of the political
routes" of the Lisps of the 1970s.

I _disagree_ that "popularity is at an all time low."  The number of
Lisp projects at SourceForge.net is _burgeoning_.  While that is not
perfectly representative of popularity, if Lisp were as _unpopular_
as you imply, there would not be the projects that there are.

While it is hard to draw hard-and-fast conclusions, "all time low" does
not seem too likely.

>Erik Naggum writes:
>> Lambda calculus is a means of reasoning about computation.
>> It is universal, like mathematics, not limited to any particular languages
>
>doing the lambda calculus (or evaling) is exactly what lisp lists are made
>for. car gives a function, cdr gives a list of arguments to apply the function
>to
>
>but scheme lists are closer to the lambda calculus than common lisp lists
>so I use Scheme...(examples supplied upon request)

You can build lambda functions in Common Lisp, Scheme, ML, and _Python_.
And Perl too.

Scheme probably more strongly encourages the direct use of lambda
functions in "ordinary code" than any of the others; using this as the
basis for choosing one language over another isn't terribly sensible...

>Erik Naggum writes:
>>transformations aren't related to formats of representation
>
>Here is the input to a popular linguistic diagrammer utility:
>
>clig {tree {plain-text S}
>      {tree {plain-text NP}
>            {tree {plain-text DET}
>                  {plain-text The}}
>            {tree {plain-text N}
>                  {plain-text postman}}}
>      {tree {plain-text VP}
>            {tree {plain-text V}
>                  {plain-text bites}}
>            {tree {plain-text NP}
>                  {tree {plain-text DET}
>                        {plain-text the}}
>                        {tree {plain-text N}
>                        {plain-text dog}}}}}
>
>That creates a tree diagram for the following parse tree:
>(S (NP (DET The) (N postman)) (VP (V bites) (NP (DET the) (N dog)
>(ADV vigorously) ))
>
>The transformation is straightforward, prefix all internal nodes
>with "tree" and all leaf nodes with "plain-text."
>It's trivial to do with regular expressions or a Perl list,
>but could I do the transformation by recursing through lisp list?
>Not in any natural way, because the cons cell
>structure is a binary tree.

I don't think you quite understand lists.  

A cons may consist of a head and a tail; this is quite sufficient to
unambiguously construct arbitrary tree structures.

If you build data structures sufficiently complex that conses get "too
expensive," there are other alternatives you can use, such as structures,
hash tables, and arrays.

>Finally, if I have:
>
>(setf x '(a b c d e f g h l))
>(setf y '(i j k))
>
>and I want:
>(a b c d e f g h i j k l)
>
>how do I splice in (i j k)
>
>I know how I'd do it in Perl and Scheme, but in Common Lisp?

This sort of begs the question of what you're really trying to
do here.

You seem to imply here that these lists are ordered.  I'd be
inclined to combine them via:

(setf z (union x y))
resulting in
(a b c d e f g h l i j k)

If that truly needs to be sorted, I'd think it appropriate to splice,
then sort the list...

(setf z
   (sort (union x y)
        (lambda (x y) 
           (string< 
             (symbol-name x) (symbol-name y)))))

If this was a list so large that this proved expensive, that
would probably indicate that it shouldn't be a list, but should
rather be processed using an array or perhaps even a tree, at
which point algorithms change _substantially_.

If I was doing a lot of this sort of thing, I think I'd consider
using the SERIES functions <http://series.sourceforge.net/> to
do more sophisticated things with these lists.
-- 
·····@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/lisp.html>
"X is like pavement:  once you figure out how to lay  it on the ground
and  paint yellow  lines on  it, there  isn't much  left to  say about
it. The exciting new developments  are happening in things that run ON
TOP of  the pavement, like  cars, bicycles, trucks,  and motorcycles."
-- Eugene O'Neil <······@cs.umb.edu>
From: David Bakhash
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <m3aeed1sq2.fsf@cadet.dsl.speakeasy.net>
··········@my-deja.com writes:

> What are parentheses for?
> [...]
> lambda expression evaluation/reduction
> [...]
> Why cons cells,
> Why s-expressions?
> 
> Are there straightforward ways to think about the mapping between them?

Just think of it like this for now:

Most other languages use infix notations, with complicated precedence
orderings, etc.  Lisp is prefix, e.g. (+ 2 3) or more generally

(f x-1 x-2 ... x-n)

But since functions take arbitrary arguments, you need some sort of
delimiter around calls.  For now, that should be a good enough reason.

> Lisp-lists/cons-cell-structures sure do allocate a lot of storage
> but you don't seem to be able to do much with them.
> Can you index into big cons trees and change values or
> insert cons cells (cons cell surgery)  (set-cdr in scheme can do this),

If you want O(1) access time, use arrays; if you want to be able to
insert things, use cons lists (i.e. cons cells).  You can't really
have both, but if you _want_ both, then build your own home-grown data 
structure for it.  No language can make that happen more easily.

> there seems to be a real limit to what you can do destructively in lisp
> you can destructively push onto the front of a list, but you have to write
> your own macro if you want to push onto the end (compare push shift in
> Perl)

This is because Perl's list/array structure is _not_ really a list; it
is an array with start and end pointers whose indices can change.  If
you read the perlguts manpage, you'll see that there really are only
four basic operations possible: push(), pop(), shift() and unshift().
It is fairly rare to use unshift() _and_ push() in the same program,
on the same object, but let's say you do.  Realize that insertion
doesn't come cheap.  But in CL, you can use displaced arrays with fill 
pointers, or lists, or in a few minutes write your own doubly linked
list data structure, with pointers to the start and end nodes (of
course, simple data structures like this are easily found on the
Net).

It's true, though, that Perl data structures have some different
features.  But did you ever notice how much better CL's hashtables are 
than those in Perl, which kinda suck?  For example, if you want to
make a hash-table in Perl in which strings used as keys are
case-insensitive, you have to downstring everything before looking it
up!  And since the "magic" Perl syntax is the "great" feature of Perl, 
if you wanted to abstract away the downstring call, you end up not
being able to use the basic hash access syntax of Perl hashtables
directly; instead you have to enclose it in a subroutine.

Perl does something I _don't_ like.  It clumps together lists and
arrays.  I hate that.  They're very different to me, and I want to
keep them separate.  Of course, Perl arrays are very neat, and there's 
a lot going on under the hood there.

dave
From: Lyman Taylor
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses  ...)
Date: 
Message-ID: <399AB55F.559085D5@mindspring.com>
James Hague wrote:
> 
> David Bakhash <·····@alum.mit.edu> wrote:
> 
> >This is because Perl's list/array structure is _not_ really a list; it
> >is an array with start and end pointers whose indices can change.
> 
> You're getting tangled up in implementation details here.  You could
> write a Lisp that, internally, used vectors to implement lists. 

  Errrr, exactly how are you going to implement the semantics of 
  "sharing tails"? 

USER(1): (defvar my-tail '(this is a tail ))
MY-TAIL
USER(2): (defvar head1  (append '(head 1 ) my-tail) )
HEAD1
USER(3): head1
(HEAD 1 THIS IS A TAIL)
USER(4): (defvar head2  (append '(head 2 ) my-tail ) )
HEAD2
USER(5): head2
(HEAD 2 THIS IS A TAIL)
USER(6): (setf (third my-tail) 'the )
THE
USER(7): head1
(HEAD 1 THIS IS THE TAIL)
USER(8): head2
(HEAD 2 THIS IS THE TAIL)


  I suppose it could be done, but it would likely overly complicated. 

  In a context where you have value semantics where the list operations
  all create copies I vectors would probably fly.

Lyman
From: Johan Kullstam
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <m3aeedjfem.fsf@sysengr.res.ray.com>
······@volition-inc.com (James Hague) writes:

> David Bakhash <·····@alum.mit.edu> wrote:
> 
> >This is because Perl's list/array structure is _not_ really a list; it
> >is an array with start and end pointers whose indices can change. 
> 
> You're getting tangled up in implementation details here.  You could
> write a Lisp that, internally, used vectors to implement lists.

all lisps do this.  a cons cell is essentially a simple vector (as in
non type specific) of two elements.

-- 
J o h a n  K u l l s t a m
[········@ne.mediaone.net]
sysengr
From: Kent M Pitman
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <sfwhf8lujv1.fsf@world.std.com>
Johan Kullstam <········@ne.mediaone.net> writes:

> ······@volition-inc.com (James Hague) writes:
> 
> > David Bakhash <·····@alum.mit.edu> wrote:
> > 
> > >This is because Perl's list/array structure is _not_ really a list; it
> > >is an array with start and end pointers whose indices can change. 
> > 
> > You're getting tangled up in implementation details here.  You could
> > write a Lisp that, internally, used vectors to implement lists.
> 
> all lisps do this.  a cons cell is essentially a simple vector (as in
> non type specific) of two elements.

Well, the key difference is not conceptual but implementational: a
vector typically has implementation overhead in speed and space for
dealing with the fact that vectors can be of any length (up to
most-positive-fixnum).  The net effect is the need to reserve all or
part of a word to hold the count of allocated slots, and the need to
check that value during execution of safe code for aref (or even
svref).  By contrast, a cons is type-safe for accessing these two
slots (since all conses have them) and does not need to allocate
storage for a byte count (since all conses have size 2).

Now if you *really* wanted a case to make about redundancy, you could
go back to maclisp where there was a datatype called HUNK which came in
allocated sizes of HUNK2, HUNK4, etc. up to HUNK256 or HUNK512 (memory
escapes me and I'm too lazy to look it up).  These were useful as 
"conses with middles" and had accessors which were (cxr i hunk).  You
could actually make a hunk3, but it was allocated as a hunk4 with a special
marker in one cell saying "don't look here".  In that space, you could 
argue that a CONS and a HUNK2 were redundant.  Indeed, for a long time
they printed identically, though later we adopted the notation (a . b .)
for a hunk2, to slightly distinguish it from a cons...  I really kinda 
miss HUNKs.  There were all kinds of cool things you could do with them.
But what mostly one ended up doing with them was simulating class instances
before there was a class system, and eventually we just added a class system
so they went away.  For numerical access, arrays are better suited.  For
named slot access, classes are better suited.

HOWEVER, if what David means is that you could implement (list a b c)
as (vector a b c), I don't think that's fair.  You'd have a really hard
time with RPLACD.  On the Lisp Machine, (list a b c d) *does* allocate
four sequential memory slots using something called "cdr coding" to help
with the bookkeeping (cost = 2 bits per cons cell), but if you rplacd one
of those sequentially-allocated lists, you end up consing in order to make
the new arrangement work.  It wouldn't be possible to do without either
special hardware/microcode as on the lispm, or without making every array
access an extra memory cycle or two or four to accomodate all the bit
decoding that has to be done... which is why it's not conventionally done on
stock hardware.
From: David Bakhash
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <m37l9h16l6.fsf@cadet.dsl.speakeasy.net>
Kent M Pitman <······@world.std.com> writes:

> HOWEVER, if what David means is that you could implement (list a b c)
> as (vector a b c), I don't think that's fair.  You'd have a really hard
> time with RPLACD. [...]

Huh!?!?

I _never_ implied that.  Please go back and read my post.  While I
don't know the details of every implementation of lists, I was
specifically implying that lists *are* and *should* be implemented
differently, and that while Common Lisp has both types, Perl's
array/list type is one big thing, and (if you look inside it) it's
really an array-style struct, and _not_ a list in the Lisp sense, and
therefore certain ops were definitely more expensive, such as
insertion.

I was also implying that while you could trivially do all four of the
aforementioned Perl array operations on Lisp lists, not all of them
are O(1) with respect to the length of the list, as they are in Perl.
One can argue that Perl wins overall since when you insert something
into an array, it might do a memcopy() on the rest of the array, or
something fancy like that.  In fact, I think I recall looking into the 
implementation of Java's Vector class, and seeing a call to the
System.arraycopy() method in the insertion method.  In any particular
Java implementation, the System.arraycopy() method is probably pretty
fast, especially if it little more than a memcopy().

dave
From: Kent M Pitman
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <sfwlmxw50u4.fsf@world.std.com>
David Bakhash <·····@alum.mit.edu> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > HOWEVER, if what David means is that you could implement (list a b c)
> > as (vector a b c), I don't think that's fair.  You'd have a really hard
> > time with RPLACD. [...]
> 
> Huh!?!?
> 
> I _never_ implied that.  Please go back and read my post.

I was responding only to what James (I think it was) had quoted.
That's why I responded in the conditional.  I guess what you meant was
not that, in which case the "then" of my remarks is never
reached... :-) Sorry for the confusion.  Didn't mean to cast any undue 
aspersions on anyone.

Regarding Java's vectors, btw, I'm a little surprised that it doesn't
just implement what Teco called the "gap".  Early Teco was frustrated
by a problem where if you inserted characters in a buffer, you had to
keep sliding all the remaining characters down the line.  Eventually
buffers came to be maintained in two pieces, with a gap separating for
a small amount of insertion room.  Periodically, the gap would be widened
again if you didn't seem to be desisting in inserting characters there.
If you moved elsewhere in the buffer, things were slid back and forth only
to the gap, not to end of buffer.  This meant that insertion at the
"wrong end" didn't end up nearly as bad as you'd expect it.   Seems to me
a similar scheme would have worked for Vectors, accomodating insertion
at either end with reasonable efficiency, with some minor overhead in
access time to accomodate triage of which block to access from.
Maybe it's fit that should be a different data structure, but I'm always
surprised it's omitted from the standard repertoire.
From: Peter Norvig
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses  ...)
Date: 
Message-ID: <399B1AD2.4BA0AD81@norvig.com>
The language Sather uses vectors with a gap like this for its
fundamental collection data type.

(Sather is a very nice language for its iteration/coroutine facility and
for its clean separation of implementation and inheritance as well.)

-Peter Norvig

Kent M Pitman wrote:
> 
> 
> Regarding Java's vectors, btw, I'm a little surprised that it doesn't
> just implement what Teco called the "gap".  Early Teco was frustrated
> by a problem where if you inserted characters in a buffer, you had to
> keep sliding all the remaining characters down the line.  Eventually
> buffers came to be maintained in two pieces, with a gap separating for
> a small amount of insertion room.  Periodically, the gap would be widened
> again if you didn't seem to be desisting in inserting characters there.
> If you moved elsewhere in the buffer, things were slid back and forth only
> to the gap, not to end of buffer.  This meant that insertion at the
> "wrong end" didn't end up nearly as bad as you'd expect it.   Seems to me
> a similar scheme would have worked for Vectors, accomodating insertion
> at either end with reasonable efficiency, with some minor overhead in
> access time to accomodate triage of which block to access from.
> Maybe it's fit that should be a different data structure, but I'm always
> surprised it's omitted from the standard repertoire.
From: Erik Naggum
Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
Date: 
Message-ID: <3175434977029708@naggum.net>
* James Hague
| You could write a Lisp that, internally, used vectors to implement
| lists.

  Yes, of course, as a cons cell is vector of two elements.

  I'm sure that's what you meant.  ;)

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <87hf8t55vk.fsf@piracy.red-bean.com>
Russell McManus <···············@msdw.com> writes:

> Just keep programming in Lisp, and the paren issue will cease to
> become a problem.

On that note, I can say that during my earlier days of learning Lisp
and scheme both, the parenthesis were never any problem at all,
neither confusing nor intimidating.  When I was trying to wrap my head
around the distinction between compile, eval, and load time or any of
the other concepts Lisp introduces that are MUCH more alienating and
tremendously more important than its syntax, the simplicity of lists
was a boon, not a burden.

I think the "common sense" understanding that parens are confusing and
intimidating to new users is utterly bogus.  It's like television
news, commenting on the most obvious, yet utterly unimportant details
of an event, meanwhile the more pressing implications of the event go
unaddressed.

Python was/is a pedagogical tool, and it's decision to make syntax
significant was based on that context.  It was designed to teach new
CS students better habits for the formatting of code, by making a
standard formatting schema mandatory.  Lisp already has
pretty-printers and editor support for encourgaing good formatting
habits.

-- 
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant   indentation?
Date: 
Message-ID: <39933C70.9C1D6CAA@kurtz-fernhout.com>
Craig-

A very interesting post. Some comments below.

Craig Brozefsky wrote:
> 
> Russell McManus <···············@msdw.com> writes:
> 
> > Just keep programming in Lisp, and the paren issue will cease to
> > become a problem.
> 
> On that note, I can say that during my earlier days of learning Lisp
> and scheme both, the parenthesis were never any problem at all,
> neither confusing nor intimidating.  

Just to be clear, I don't find the notion of parenthetical expressions
itself confusing. I agree it is elegant and consistent. It is just the
redundancy and visual clutter I find unappealing at the moment. But,
that is an opinion obviously not shared by many if not all experienced
Lisp developers on this newsgroup. I also see unnecessary work involved
in manipulating some parentheses at the edges of lines in addition to
managin indentation, but I am not a current emacs user like many of the
people on this newsgroup, and I can see how emacs or alternatives
environments like DrScheme can make many of these issues easy to manage.

> When I was trying to wrap my head
> around the distinction between compile, eval, and load time or any of
> the other concepts Lisp introduces that are MUCH more alienating and
> tremendously more important than its syntax, the simplicity of lists
> was a boon, not a burden.

Excellent point. In general, you are right on the mark. The really
complicated and difficult problems in computing have to do more with
understanding concepts and creating specific complex implementations
than with mastering any specific syntax. However, that is not to say an
inelegant syntax can't slow one down.
 
> I think the "common sense" understanding that parens are confusing and
> intimidating to new users is utterly bogus.  It's like television
> news, commenting on the most obvious, yet utterly unimportant details
> of an event, meanwhile the more pressing implications of the event go
> unaddressed.

Good point. Actually, looking at something like the TeachScheme!
project, 
  http://www.cs.rice.edu/CS/PLT/Teaching/
if anything it looks like a consistent use of parentheses with little
other arbitrary syntax makes it much easier for people to learn to
program in Scheme or Lisp than say in Pascal or C++. So this all
supports your point.

However, I should point out that I've programmed for 20+ years, and
tried Lisp a few times, even doing some small projects in it. Coming
back to it yet again from Python, Smalltalk, Delphi, and C++, I still
think that there might be some way the process of coding and reading
Lisp can be improved. But, of course, a lot of this is tradeoffs. 

The fact that this is a perennial "newbie" lament does, in my opinion,
point to an inelegance of some aspect of the Lisp family of languages.
However, that is not to say this price is not worth paying for the other
advantages that Lisp family languages provide. People on this newsgroup
seem sure it is, and further add that the problem appears to go away in
time as one becomes more experienced with the system. I am just trying
to seek a solution that keeps the Lisp elegance and minimizes this very
real "newbie" issue. 

Perhaps that is impossible, but people also said that of proving the
Fermat Conjecture ("Fermat's Last Theorem"). Of course, that work had to
be done in secret, less the mathematician involved risk his career. But
I was hoping to harness all the brainpower of this newsgroup to perhaps
improve the solution I proposed, or point out obvious technical flaws in
the concept.

> Python was/is a pedagogical tool, and it's decision to make syntax
> significant was based on that context.  It was designed to teach new
> CS students better habits for the formatting of code, by making a
> standard formatting schema mandatory.  Lisp already has
> pretty-printers and editor support for encourgaing good formatting
> habits.

I don't remember reading about the code formatting habit emphasis, but I
could believe it. Certainly after using Occam I used two spaces for
indentation when possible.
 
> Craig Brozefsky               <·····@red-bean.com>
> Lisp Web Dev List  http://www.red-bean.com/lispweb
> ---  The only good lisper is a coding lisper.  ---

Thanks for the interesting comments.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <3174983985849332@naggum.net>
* Craig Brozefsky <·····@red-bean.com>
| I think the "common sense" understanding that parens are confusing
| and intimidating to new users is utterly bogus.

  There _is_ empirical evidence that parentheses are used to mark
  something that is out of the ordinary and thus cause people to think
  of them as signs of something more complex than their absence.

| Python was/is a pedagogical tool, and it's decision to make syntax
| significant was based on that context.  It was designed to teach new
| CS students better habits for the formatting of code, by making a
| standard formatting schema mandatory.  Lisp already has
| pretty-printers and editor support for encourgaing good formatting
| habits.

  ... mumble ... languages to prove something ... mumble ... languages
  to do something ...   [If you catch the reference, don't remind me.]

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <87itt73dob.fsf@piracy.red-bean.com>
Erik Naggum <····@naggum.net> writes:

> * Craig Brozefsky <·····@red-bean.com>
> | I think the "common sense" understanding that parens are confusing
> | and intimidating to new users is utterly bogus.
> 
>   There _is_ empirical evidence that parentheses are used to mark
>   something that is out of the ordinary and thus cause people to think
>   of them as signs of something more complex than their absence.

That doesn't imply confusion and intimidation tho.

>   ... mumble ... languages to prove something ... mumble ... languages
>   to do something ...   [If you catch the reference, don't remind me.]

I'm curious about this reference.

-- 
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <3175100860911528@naggum.net>
* Craig Brozefsky <·····@red-bean.com>
| That doesn't imply confusion and intimidation tho.

  I think it does to a person who is stupid and incompetent in the
  face of complexity he is afraid of, especially if he has failed to
  handle some complex things in the past.  Many programmers should
  never have started down that carreer path.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Rudolf Schlatte
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <lxn1ikq9b1.fsf@ist.tu-graz.ac.at>
Erik Naggum <····@naggum.net> writes:

>   There _is_ empirical evidence that parentheses are used to mark
>   something that is out of the ordinary and thus cause people to think
>   of them as signs of something more complex than their absence.

Also, in an infix language, more than one or two pairs of parentheses
within, say, three lines indicate a complicated expression.  Given the
mess that operator precedence is in infix languages, this says
basically 

*** HERE BE BUGS ***

to the experienced programmer.  I imagine the reaction from a C
programmer upon seeing a Lisp program for the first time must be like
going into a room with flashing lights,sirens going off, the light
flickering and some people sitting peacefully at a table and drinking
beer.  "Why don't they FIX this mess already?"


Rudi (programming C++ during summer, just for the heck of it)
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <5=WTOZX8iPeX+HoAuZXgeFC5IYB6@4ax.com>
On 10 Aug 2000 11:27:11 -0700, Craig Brozefsky <·····@red-bean.com> wrote:

> On that note, I can say that during my earlier days of learning Lisp
> and scheme both, the parenthesis were never any problem at all,
> neither confusing nor intimidating.  When I was trying to wrap my head

I had a similar experience. My first approach with the Lisp family of
languages was with Scheme in 1990 (University of Milan, Italy). Since then
I attended other classes based on Scheme, and I had the opportunity of
watching hundreds of students learning the language. I occasionally
volunteered as an informal lab assistant.

Few of those students complained about parentheses or found them annoying.
When they used Lisp-aware editing environments such as those provided by
EdScheme or DrScheme, many students even considered editing Scheme a fun
activity.


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant   indentation?
Date: 
Message-ID: <39932838.5C201AF0@kurtz-fernhout.com>
Russell-

Thanks for the encouragement!

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


Russell McManus wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > I would think that rapidly seeing strucutre implied by spacing uses
> > visual perceptive abilities to see symmetry and consistency and grouping
> > most people have. I assume this, but I may be wrong. Perhaps some people
> > don't easily see the structure specified by the white space. Counting
> > parentheses may use different abilities -- perhaps ones I personally am
> > weaker in.
> 
> Lisp programmers use the indentation to see the structure of the code.
> The editor can reindent whole expressions with a keystroke.  The
> parens make it easy to implement the advanced editor features that
> have been discussed, without building a complete parser for the
> language you are editing into the editor.
> 
> Just keep programming in Lisp, and the paren issue will cease to
> become a problem.
> 
> -russ
> 
> --
> They don't make nostalgia like they used to.
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <3174983602960695@naggum.net>
* Paul Fernhout <··········@kurtz-fernhout.com>
| 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)?

  There isn't "a lot of" cut and paste in Lisp, but _when_ you want to
  move or copy whole expressions, Emacs users double-click on one of
  the parentheses and the whole expression is instantly highlighted
  and ready for copy (at least under X -- Windows requires a lot more
  manual labor, as is usual).  This is even used to see the whole
  expression better in a nested form.  Also, when people need to move
  expressions around, they have tools in Emacs like transpose-sexp,
  which I suppose you would do with transpose-lines or something...

  I once said: "Those who do not know Lisp are doomed to reinvent it"
  in an Emacs setting.  This is a Lisp setting, so maybe I should say:
  "Those who do not know Emacs are doomed to reinvent it".

| 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.

  Suppose you have an expression at indentation level N.  Copy it to a
  place where indentation level M prevails.  How much work do you need
  to do to get the indentation right?  In a fully parenthesized Lisp,
  you have tools to do this for you.  In a less parenthesized Lisp,
  you have no tools, but must shift the newly copied block of code
  right or left more or less by hand.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Rob Warnock
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant   indentation?
Date: 
Message-ID: <8n36o6$fll67$1@fido.engr.sgi.com>
Erik Naggum <····@naggum.net> wrote:
+---------------
| There isn't "a lot of" cut and paste in Lisp, but _when_ you want to
| move or copy whole expressions, Emacs users double-click on one of
| the parentheses and the whole expression is instantly highlighted and
| ready for copy...
+---------------

By the way, even "vi" lets you do this -- "y%" will copy (or "d%" will cut)
the following sexp into the anonymous buffer, and "p" (or "P") will paste.

+---------------
| Also, when people need to move expressions around, they have tools in Emacs
| like transpose-sexp, which I suppose you would do with transpose-lines or
| something...
+---------------

In "vi", to transpose two sexps, just type "d%%p".

+---------------
| "Those who do not know Emacs are doomed to reinvent it".
+---------------

I'm sure Emacs is the ultimate tool for this[*], but still, if you
use the mechanisms available in "vi", editing Lisp is pretty easy.


-Rob

[*] For those who can make their fingers work that way; mine can't seem to.

-----
Rob Warnock, 41L-955		····@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		PP-ASEL-IA
Mountain View, CA  94043
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant   indentation?
Date: 
Message-ID: <39960339.AEAA96BD@kurtz-fernhout.com>
Erik-

Your point about the power of emacs is well made. 

Still, there are some surprising things that are relatively easy to do
with an indentational syntax that don't require signifianct editor
support. In an indentational syntax, every line starts an S-expression,
and thus one can switch S-expressions mainly by just using the up and
down arrow keys. Embedded S-expressions may be defined using parentheses
within a line, and so do cause more difficulties (perhaps severe ones,
although in practice we will have to see). 

It is quite possible that similar operators to the ones mentioned for
emacs could be made for an indentational syntax. Do I have such
operators at the moment? No. Will I? Probably not as long as I keep
spending most of my free time replying to this thread. :-) And also,
since at the moment I use DrScheme and not emacs, there is no particular
reasons for me to enhance emacs. DrScheme may be a different story, and
then some of those ideas might be applicable to emacs.

However, many editors support block-shift-left and block-shift-right, so
I think this particular issue you raise at the end is already handled to
an extent with a minimum of keystrokes in practice. Will it always take
more keystrokes on average than a fully parenthesized system, requiring
only a paste and reformat? Perhaps. Perhaps not.

Could all this be handled even better in a specialized emacs editing
mode for indentational syntax? Most likely yes, given all the great
things people say about emacs. Given the hybrid of indentational and
parenthesization allowed, this mode might require some sophisticated
coding. 

To address your point in terms of future possiblities made easier by
indentational syntax, imagine basically dragging and dropping Lisp
expressions in a hierarchical tree editor on nested S-expressions.

Will such a mode ever be as good as what people have now for fully
parenthesized expressions? I don't know. We're comparing several decades
and hundreds of person-years of Lisp editor development against a new(?)
proposal. 

Obviously, one of the drawbacks of anything new or better (not to insist
this proposal is necessarily either) is that the existing system is in
place already and working. I guess this is one of the reasons "Worse is
Better", even when it comes to something about Lisp. <Ducks...> :-)
  http://www.jwz.org/doc/worse-is-better.html

(?) -- no one has yet pointed out this exact thing has been tried with
Lisp. I still find that hard to believe...

-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

Erik Naggum wrote:
> 
> * Paul Fernhout <··········@kurtz-fernhout.com>
> | 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)?
> 
>   There isn't "a lot of" cut and paste in Lisp, but _when_ you want to
>   move or copy whole expressions, Emacs users double-click on one of
>   the parentheses and the whole expression is instantly highlighted
>   and ready for copy (at least under X -- Windows requires a lot more
>   manual labor, as is usual).  This is even used to see the whole
>   expression better in a nested form.  Also, when people need to move
>   expressions around, they have tools in Emacs like transpose-sexp,
>   which I suppose you would do with transpose-lines or something...
> 
>   I once said: "Those who do not know Lisp are doomed to reinvent it"
>   in an Emacs setting.  This is a Lisp setting, so maybe I should say:
>   "Those who do not know Emacs are doomed to reinvent it".
> 
> | 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.
> 
>   Suppose you have an expression at indentation level N.  Copy it to a
>   place where indentation level M prevails.  How much work do you need
>   to do to get the indentation right?  In a fully parenthesized Lisp,
>   you have tools to do this for you.  In a less parenthesized Lisp,
>   you have no tools, but must shift the newly copied block of code
>   right or left more or less by hand.
> 
> #:Erik
> --
>   If this is not what you expected, please alter your expectations.
From: Marie-Noëlle Baechler
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant   indentation?
Date: 
Message-ID: <3991C116.DE5CFF93@bluewin.ch>
> - 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
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant   indentation?
Date: 
Message-ID: <39933E8C.F159CC95@kurtz-fernhout.com>
Marie-No�lle -

Thanks for the interesting comments and references.

Just to be clear though, I do want to keep all the advantages of Lisp. 

I am looking for a way to do this while still removing what I as someone
coming back to Lisp from a long hiatus sees as some excess visual
clutter. 

If anything, since I want to remove things, I'd certainly be against
personally using an Algol-like syntax if I'm programming in Lisp. 

I think the Lisp syntax is elegant and powerful. I just want to see if
it can still work with less parentheses on the edges of lines. 

In a way, along the lines of another post by Chris Page, it's really a
typographic convention I am proposing more than something fundamental.

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


Marie-No�lle Baechler wrote:
> 
> > - one of the points of the syntax of lisp is that it makes it very
> >   easy to parse; since devices without keyboards probably also are
> >   short on other ressources, increasing the complexity in central
> >   components may be the wrong way to go.
> 
> In addition, there has been myriads of Algol-like syntax implemented
> over a Lisp System. But none of these extensions did ever become
> popular. Even John MacCarthy mentions that S-Expressions  were
> originally only intended for data and that program had to be written
> in a more algol-like syntax called M-expressions(*). But S-expressions
> were used from the beginning and they are still there.
> 
> Lips syntax has other advantages beyond easy of parsing. It makes
> programs similar to data and reciprocally. With good macros, this
> gives a tremendous expressive power and I am not sure that it can
> be achieved with a more conventional system. Finally, Lisp makes
> it extremely easy to develop interpreters over an existing
> implementations. Even in the seventies, when he was testing the
> Actor model, Harold Abelson was developping and testing up to 10
> interpreters a week! (**) Once again, I doubt that such an expressive
> power can be achieved with a more conventional language.
> 
> (*) John McCarthy
>     History of Lisp
>     Stanford university, 12 February 1979
> 
> (**) Guy Steel Jr. & Richard P. Gabriel
>      The Evolution of lisp
>         ACM Sigplan Notices 28 3. (231-270), April 1993
> 
> Both are available on-line
> 
> Regards
> 
> Marie-No�lle Baechler
From: Paul Foley
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <m2em3y1xqt.fsf@mycroft.actrix.gen.nz>
On 08 Aug 2000 21:34:52 -0400, David Bakhash wrote:

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

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

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


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

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

(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Philip Lijnzaad
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <u7em3y4ody.fsf@o2-3.ebi.ac.uk>
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, ········@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
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <m3snselkvo.fsf@cadet.dsl.speakeasy.net>
Philip Lijnzaad <········@ebi.ac.uk> writes:

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

> >> I don't know how python continues to exist in its current state.
> 
> Paul> This is rather unfair.  The use of indentation as the block structure
> Paul> delimiter in Python is very nice, and works well *for Python*, 
> 
> I concur. 

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

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

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

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

dave
From: Fernando D. Mato Mira
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant   indentation?
Date: 
Message-ID: <3991ED78.F2CBB41C@iname.com>
David Bakhash wrote:

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

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

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

-- 
Fernando D. Mato Mira			   Phone    : +41 (78) 778 FDMM
 				           E-mail   : matomira AT acm DOT org
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant   indentation?
Date: 
Message-ID: <39916E38.46F12360@kurtz-fernhout.com>
David-

Thanks for the reply. No offense taken. 

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

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

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

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

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

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

David Bakhash wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > I'm interested in using significant indentation (like in Python)
> >   http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
> 
> I don't know how to respond to this post, and please, don't take
> offense at anything I say.
> 
> The idea of using whitespace to alter the meaning of code is absurd.
> I don't know how python continues to exist in its current state.
> However, by altering the semantics of Common Lisp by using
> indentation, you will surely lose.
> 
> one reason (that I'm sure someone will argue) is that lisp code is
> itself data, and the reader simply doesn't care about whitespace
> enough to handle this proposal.  The resulting code will be a mess, as
> will its rules, and doing quick-and-dirty stuff from the
> read-eval-print loop (lisp prompt) will become annoying, though this
> is the least of the problems I'm seeing.
> 
> When I first heard about Python and this indentation thing, I was
> incredulous.  But, of course, it turned out to be true.  But the line
> of thinking used for Python should never infect Common Lisp.  I don't
> think I've ever heard of a proposal for changing CL that's worse than
> this, except a CL that required type decls, but even there, he had a
> decent argument, which had to do with performance, but even that was
> tenuous, since an implementation may choose to optimize based on
> declarations, and it's hard enough to implement CL without these
> optimizations.
> 
> In a nutshell, this idea is incompatible with CL for many reasons, and
> if it ever happened, it would be disgraceful.  I think it's great when
> people look at some language feature like GC in CL and say "wouldn't
> it be cool if we made a C++ like language that had this feature (hence
> Java)", but _not_ when they take the crappiest "features" from other
> languages and try to infect CL with them.  This indentation-dependence
> "feature" is surely the worst of all features I've ever heard of.  How
> people deal with it is beyond me.
> 
> Paul Fernhout <··········@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
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3174842187091565@naggum.net>
* Paul Fernhout <··········@kurtz-fernhout.com>
| Has this been tried before?  If so, what was the outcome?

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

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

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

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

  Nonsense.

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

  This silly metric runs counter to much cognitive science.

  forinstanceithaslongbeenknownthataddingsuperfluouscharacterslike
  whitespaceandpunctuationmarksimprovereadabilitysignificantly

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

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

| Such code will be faster to create.

  Drop the marketing and your credibility will improve.

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

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

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

  Your credibility is suffering with this line, too.

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

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

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

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

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

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

  Predictable redundancy is what keeps people sane.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <87zommcdjy.fsf@piracy.red-bean.com>
Erik Naggum <····@naggum.net> writes:

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

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

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

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

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

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

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

-- 
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3174895060471363@naggum.net>
* Erik Naggum
| I think "down" and "up" are equally useful/likely "buttons".  I use
| Emacs with these operations all the time, in fact.  Very seldom do I
| type invididual parentheses.

* Craig Brozefsky
| How do you avoid that?  

  M-( inserts () and leaves point between them.  M-) leaves point
  after the closing paren.  (A numeric argument, n, to M-( wraps the
  next n s-exprs in parens.)  I have written similar functions for []
  and {}, as well as "" and **.  This means I don't generally have
  unmatched paired delimiters in my code.  (This is a simplification
  of the SGML code I wrote years ago to start with <></> and let each
  character (up to the first whitespace) in the start-tag also insert
  in the end-tag.)

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

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

  Look at Dylan.  It had a Lisp-like syntax at first, then lost it
  because of the syntactic changes in the "other" syntax.  If you
  don't constantly think in terms of LL(1) grammars and readers that
  return objects, someone will begin to think in other terms and win
  popularity because people generally just accept visible concepts,
  but don't think about them if they aren't immediately visible.

  So even if the significant-whitespace proposal is OK now, _because_
  of the explicit list structure, some next step will lose the list
  structure because someone will make another "innovation" that leaves
  that heritage behind.

| In R5RS any Expression will also parse as Datum (what read
| understands).

  In scheme, (if 1 2 3) and (if 1 2 . (3)) are identical as data, but
  as code, they are different.  [I think this is completely idiotic.]

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <87n1il58zx.fsf@piracy.red-bean.com>
Erik Naggum <····@naggum.net> writes:

>   M-( inserts () and leaves point between them.  M-) leaves point
>   after the closing paren.  (A numeric argument, n, to M-( wraps the

Schweet.  Makes LET expressions trivial to type and really cuts down
cursor moving when doing things like wrapping sexps in a conditional.
This is a very useful time saver.

> | In R5RS any Expression will also parse as Datum (what read
> | understands).
> 
>   In scheme, (if 1 2 3) and (if 1 2 . (3)) are identical as data, but
>   as code, they are different.  [I think this is completely idiotic.]

Ahh, the price of having all Expressions be Datum, but not all Datum
are Expressions.  Not until I thought of the programmatic
construction, spurred by this example, did I realize how big of an
issue it could be.


-- 
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: felix
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <sp6nc0gnn4t10@corp.supernews.com>
Erik Naggum wrote in message <················@naggum.net>...

>  In scheme, (if 1 2 3) and (if 1 2 . (3)) are identical as data, but
>  as code, they are different.  [I think this is completely idiotic.]



Microsoft(R) Windows 98                                    [<-- any
comments?]
   (C)Copyright Microsoft Corp 1981-1998.

C:\work>mzscheme
Welcome to MzScheme version 101, Copyright (c) 1995-99 PLT (Matthew Flatt)
> (if 1 2 . (3))
2
> (if #f 2 . (3))
3

C:\Stuff\scheme48>scheme48vm
Welcome to Scheme 48 0.53 (suspended image).
Copyright (c) 1993-1999 by Richard Kelsey and Jonathan Rees.
Please report bugs to ··············@martigny.ai.mit.edu.
Type ,? (comma question-mark) for help.
> (if #f 2 . (3))
3


(Hm, this doesn't look too bad)

In another posting you wrote:

>  ... Hell, they [the ones from the Scheme camp] don't even believe in
>  compile-time manipulation of the code...

Now, please, how exactly do you come to that conclusion?
(I expect you know about macros in Scheme, but perhaps I
have to alter my expectations)


felix
From: Pierre R. Mai
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <87ya23sd79.fsf@orion.bln.pmsf.de>
"felix" <·····@anu.ie> writes:

> Erik Naggum wrote in message <················@naggum.net>...
> 
> >  In scheme, (if 1 2 3) and (if 1 2 . (3)) are identical as data, but
> >  as code, they are different.  [I think this is completely idiotic.]

[ irrellevant samples of Scheme implementation behaviour cut ]

> (Hm, this doesn't look too bad)

You cannot demonstrate the truth of a statement about a language by
sampling a small subset of it's implementations.  You have to cite
normative references that demonstrate the truth of your statement.
Take a look at the section "Formal syntax and semantics" of R5RS,
where you will see that (if 1 2 . (3)) is not an expression, although
it is a datum:

"External representations

<Datum> is what the read procedure (section see section Input) successfully
parses. Note that any string that parses as an <expression> will also parse
as a <datum>.

<datum> --> <simple datum> | <compound datum>
<simple datum> --> <boolean> | <number>
     | <character> | <string> |  <symbol>
<symbol> --> <identifier>
<compound datum> --> <list> | <vector>
<list> --> (<datum>*) | (<datum>+ . <datum>)
       | <abbreviation>
<abbreviation> --> <abbrev prefix> <datum>
<abbrev prefix> --> ' | ` | , | ,@
<vector> --> #(<datum>*) 


Expressions

<expression> --> <variable>
     | <literal>
     | <procedure call>
     | <lambda expression>
     | <conditional>
     | <assignment>
     | <derived expression>
     | <macro use>
     | <macro block>

[...]

<conditional> --> (if <test> <consequent> <alternate>)
<test> --> <expression>
<consequent> --> <expression>
<alternate> --> <expression> | <empty>
"

That in "real live" many (though not all) Scheme implementations _do_
accept (if 1 2 . (3)), and treat it identically to (if 1 2 3) is a
different matter.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: felix
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <sp951mh1n4t174@corp.supernews.com>
Pierre R. Mai wrote in message <··············@orion.bln.pmsf.de>...

>You cannot demonstrate the truth of a statement about a language by
>sampling a small subset of it's implementations. You have to ...
> [blablabla]
>...That in "real live" many (though not all) Scheme implementations _do_
>accept (if 1 2 . (3)), and treat it identically to (if 1 2 3) is a
>different matter.


If you mean that the Scheme-standard is full of holes, yep, you're right
with
that. If you consider yourself a language lawyer, then there is absolutely
nothing to say about the enormous advantage that a huge and mature
standard gives to a language. I wished something like that would exist
for Scheme. But CL (and that includes its predecessors like MacLISP) had a
lot of time to evolve, and you see that everywhere in the language
specification.

But, I think I can very well take some of the most used Scheme
implementations and regard their behaviour as common practice.
No, I'm not talking about the language Scheme as defined in the
standards document, I'm talking about the language Scheme as
implemented, in "real live", as you call it.

I guess the authors of the various incarnations of the "Revised Report
on Scheme" had it in their mind to keep the language small. First, to
give implementors freedom in the range of implementation-techniques
(and that has resulted in some really interesting ideas), and second,
to keep the language open, and not to constrain it's development too early.
(Of course, I might be completely wrong)

BTW, how many CL implementations adhere *fully*, 100%, to the
Hyperspec? I'm sure every implementation has it's little incompatibilities
(especially in a *huge* language like Common LISP).

Anyway, I think you are right in that the R5RS isn't really that great.
But Scheme (and many of it's implementations) is! ;-)

(Sorry, I couldn't resist, I just can't stop teasing ;)


felix
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3175090263313160@naggum.net>
* "felix" <·····@anu.ie>
| If you mean that the Scheme-standard is full of holes, yep, you're
| right with that.

  The Scheme standard is possibly the single best standard there is,
  and such as snotty remark as your betrays utter ignorance of its
  contents.  Do yourself a favor, and don't do marketing for Scheme.

| But, I think I can very well take some of the most used Scheme
| implementations and regard their behaviour as common practice.

  There is no value at all in discussing them, since if you point out
  a problem in or with _Scheme_, somewhere, there is an implementation
  that gets that one problem solved in some way.

| No, I'm not talking about the language Scheme as defined in the
| standards document, I'm talking about the language Scheme as
| implemented, in "real live", as you call it.

  Some of us like to program to specifications, not just hope it works.

| BTW, how many CL implementations adhere *fully*, 100%, to the
| Hyperspec?

  None.  They adhere to the standard, ANSI X3.226-1994.

| I'm sure every implementation has it's little incompatibilities
| (especially in a *huge* language like Common LISP).

  Arguments from ignorance are _so_ powerful.

| Anyway, I think you are right in that the R5RS isn't really that
| great.  But Scheme (and many of it's implementations) is! ;-)

  None have said that R5RS isn't great.  It really is, as a standard.
  If you bothered to read it, instead of parroting comments you don't
  grasp, you would have the possibility of understanding this yourself.

  The reason Scheme sucks, and it does, is that a beautiful standard
  is not enough.  A necessary condition, but not a sufficient one in
  any capacity at all.  If all the good stuff is extra-standard, the
  _language_ has serious problems.

| (Sorry, I couldn't resist, I just can't stop teasing ;)

  I wonder who you think you're teasing, flaunting your ignorance.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Lieven Marchand
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <m366p34vi9.fsf@localhost.localdomain>
Erik Naggum <····@naggum.net> writes:

>   The Scheme standard is possibly the single best standard there is,
>   and such as snotty remark as your betrays utter ignorance of its
>   contents.  Do yourself a favor, and don't do marketing for Scheme.

I'm less impressed with the Scheme standard. 

I think the denotational semantics they add to describe each feature
is only understood by a very small percentage of the readers of the
standard and doesn't add much. People who understand this stuff can
write it for themselves if they need it. On the other hand, it could
have a negative effect on the evolution of the standard as it
discourages potentially useful features that are awkward to describe
in denotational semantics, such as the CL concept of designators.

Another gap is the exact definition of one of the features Scheme
afficionados insist upon: tail recursiveness. IIRC, even in the
current standard, the reader is referred to a forthcoming article.

One of the best standards I've read is the ANSI-C(89) one. ISO
mutilated it by eliminating the Rationale. The Ada-95 is very good to
and a vast improvement over the Ada-83.

-- 
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3175274726953827@naggum.net>
* Lieven Marchand <···@bewoner.dma.be>
| I think the denotational semantics they add to describe each feature
| is only understood by a very small percentage of the readers of the
| standard and doesn't add much.

  I considered it a show-off and paid no attention to it whatsoever.

| One of the best standards I've read is the ANSI-C(89) one.  ISO
| mutilated it by eliminating the Rationale. The Ada-95 is very good
| to and a vast improvement over the Ada-83.

  I worked a lot with Ada 83 in the mid- to late 80's and found it
  appealing that the compilers referred directly to the clauses in the
  standard.  That helped me familiarize myself with the standard in a
  useful way.  What little I have read of Ada 95 is indeed impressive
  in clarity and language, but it is not enough to pass judgment on
  the whole huge document.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Lieven Marchand
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <m3punbmrzr.fsf@localhost.localdomain>
Erik Naggum <····@naggum.net> writes:

> * Lieven Marchand <···@bewoner.dma.be>
> | I think the denotational semantics they add to describe each feature
> | is only understood by a very small percentage of the readers of the
> | standard and doesn't add much.
> 
>   I considered it a show-off and paid no attention to it whatsoever.
> 

A reasonable attitude. A few years ago, someone wrote a thesis in
which he wrote up the denotatial semantics for C. I'm still not sure
whether to be impressed or appalled.

>   I worked a lot with Ada 83 in the mid- to late 80's and found it
>   appealing that the compilers referred directly to the clauses in the
>   standard.  

I've seen it in action with a class of fairly inexperienced people and
it added more confusion than help for most. GNAT doesn't do it
intentionally. I liked it though.

>   What little I have read of Ada 95 is indeed impressive in clarity
>   and language, but it is not enough to pass judgment on the whole
>   huge document.

I don't know what is cause and effect, but there is a resemblance
between the communities in that they both understand the difference
between a language specification and an implementation, and that the
language specification is freely available. In the C and C++
communities there are a lot of people who think that experimenting
with their implementation will tell them something about the language
specification.

-- 
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Paul F. Dietz
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <39993084.6073A61E@interaccess.com>
Lieven Marchand wrote:

> A reasonable attitude. A few years ago, someone wrote a thesis in
> which he wrote up the denotatial semantics for C. I'm still not sure
> whether to be impressed or appalled.

I knew a fellow whose thesis was on the denotational semantics
of SNOBOL.

	Paul
From: Johan Kullstam
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <m3vgx2k6v1.fsf@sysengr.res.ray.com>
Lieven Marchand <···@bewoner.dma.be> writes:

> Erik Naggum <····@naggum.net> writes:
> 
> > * Lieven Marchand <···@bewoner.dma.be>
> > | I think the denotational semantics they add to describe each feature
> > | is only understood by a very small percentage of the readers of the
> > | standard and doesn't add much.
> > 
> >   I considered it a show-off and paid no attention to it whatsoever.
> > 
> 
> A reasonable attitude. A few years ago, someone wrote a thesis in
> which he wrote up the denotatial semantics for C. I'm still not sure
> whether to be impressed or appalled.

if it got them graduated, i'm impressed.  that is, after all, *the*
goal of writing a thesis.  anything else is just extra.

-- 
J o h a n  K u l l s t a m
[········@ne.mediaone.net]
sysengr
From: Espen Vestre
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <w6em3qohgi.fsf@wallace.nextel.no>
Erik Naggum <····@naggum.net> writes:

>   I considered it a show-off and paid no attention to it whatsoever.

I think it at least shows that the syntax and semantics of scheme is
a little more predictible than that of perl ;-) (but, if you fix your
version of perl to the third decimal position, you might even be able
to come up with a denotational semantics for *that*, too)
-- 
  (espen)
From: Kent M Pitman
Subject: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <sfwwvhj1k2x.fsf_-_@world.std.com>
Lieven Marchand <···@bewoner.dma.be> writes:

> I think the denotational semantics they add to describe each feature
> is only understood by a very small percentage of the readers of the
> standard and doesn't add much.

And introduces the potential for disagreement between the two specs, with
different kinds of users thinking, conflictingly, that they each have claim 
to the "obviously superior" description (the "formal" one vs the "intelligible"
one).

> it discourages potentially useful features that are awkward to describe
> in denotational semantics, such as the CL concept of designators.

Agreed. ... though my intuition is that the Scheme community would 
HATE designators.  More specifically, though, it has caused them to hate
multiple namespaces, even though I'm told it's very little difference in the
overall size of the formal semantics to accomodate them.  The denotational
semantics is jealously guarded and adding any text there is out of the 
question.  

Worse, though, now that I think about it, the same is true in the other
text, too.  I've asked for notes on portability, efficiency, error
handling behavior, etc. and have been told that these would be just
clutter, which would intrude on the tiny size of the document.  Just about
everything in the Scheme standard is about minimizing the size of the document,
not about care for the end user.

It reminds me of CLTL in style, which I would contrast with ANSI CL in the
following way:  In CLTL, the chore was to come up with words that we could all
say we agreed on, even if we didn't agree on the meaning of the words.  That
is, the impression of community unity was the goal.  Whether in fact any
implementation ran the same was not in issue; we knew implementations would
diverge wildly.  As long as each did something which could plausibly claim 
to be "textually compatible" with the standard was enough.  By the time of 
ANSI CL, the community had learned that merely having "warm and fuzzy words"
was not enough and people wanted precise details for porting, efficiency,
etc.  This lengthened the spec, but there was value in the longer version, 
and so people tolerated the result rather than live in the specificational
hell that Scheme has created where "if you do something you were told not 
to, you should expect to lose".  Textually compact, perhaps, but a bit hard
to debug.

It was all I could do to get them to acknowledge the horrible weakness in
call/cc in which it interacts horribly with unwind-protect, because the
language doesn't provide for unwind-protect and so they were mostly able to
sweep the problem under the rug (except for bad interactions with the 
with-open-file analog, whose name doesn't come to mind and I don't have a spec
handy, where there is some obscure admission that call/cc just can't really
work right for things like that).  This is a misdesign in the whole way
call/cc is done, and it took me forever to get an admission from some of the
core people that it was so, but I eventually got someone (Sussman, I think)
to at least acknowledge my claim on this.  But still no one wanted to fix it
or even really mention it because it would mess up the denotational semantics
everyone was used to and clutter the textual presentation.

The Scheme standard was not about portable code but about portable
textbooks, I was told once at one of the design meetings, when I
argued for more specificity in some of the definitions.

No, the Scheme standard doesn't get a vote from me for best standard.
I think it serves a certain community in a certain limited way.  It's a cute
toy language but it was kept from being anything real by an overzealous desire
to be textually compact.
From: Lieven Marchand
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <m3vgx1uj92.fsf@localhost.localdomain>
Kent M Pitman <······@world.std.com> writes:

> And introduces the potential for disagreement between the two specs, with
> different kinds of users thinking, conflictingly, that they each have claim 
> to the "obviously superior" description (the "formal" one vs the "intelligible"
> one).
> 

This could of course be solved by having the standard declare one or
the other authoritative in case of conflict, but I don't think it does
that.

> Agreed. ... though my intuition is that the Scheme community would 
> HATE designators.  More specifically, though, it has caused them to hate
> multiple namespaces, even though I'm told it's very little difference in the
> overall size of the formal semantics to accomodate them.  The denotational
> semantics is jealously guarded and adding any text there is out of the 
> question.  
> 
> Worse, though, now that I think about it, the same is true in the other
> text, too.  I've asked for notes on portability, efficiency, error
> handling behavior, etc. and have been told that these would be just
> clutter, which would intrude on the tiny size of the document.  Just about
> everything in the Scheme standard is about minimizing the size of the document,
> not about care for the end user.
> 

One of my pet peeves is that even there, they haven't produced an
optimal result. The Modula-3 core language specification is not much
bigger than RnRS and describes an IMHO more usable language. Then the
DEC SRC people just added additional functionality in layers, usually
described in high quality research reports, so you ended up with a
very powerful environment, that included portable threads, distributed
computing etc. Java hasn't copied enough of this.

To remain within the Lisp world, I find IS-LISP to be a better "small
Lisp" than Scheme. It reminds me of the original infix syntax
Dylan. The IS-LISP standard doesn't mention contributors. Was there
much overlap between the two design communities?

> It was all I could do to get them to acknowledge the horrible weakness in
> call/cc in which it interacts horribly with unwind-protect, because the
> language doesn't provide for unwind-protect and so they were mostly able to
> sweep the problem under the rug (except for bad interactions with the 
> with-open-file analog, whose name doesn't come to mind and I don't have a spec
> handy, where there is some obscure admission that call/cc just can't really
> work right for things like that).  This is a misdesign in the whole way
> call/cc is done, and it took me forever to get an admission from some of the
> core people that it was so, but I eventually got someone (Sussman, I think)
> to at least acknowledge my claim on this.  But still no one wanted to fix it
> or even really mention it because it would mess up the denotational semantics
> everyone was used to and clutter the textual presentation.
> 

I think they've had to come to terms with this in R5RS since they
added dynamic-wind. I've never gotten my head enough around call/cc to
check whether it really works in the weirder cases though.

They still say the behaviour if you escape from
with-{in,out}put-{from,to}-file is implementation dependent.

> No, the Scheme standard doesn't get a vote from me for best standard.
> I think it serves a certain community in a certain limited way.  It's a cute
> toy language but it was kept from being anything real by an overzealous desire
> to be textually compact.

I believe in a "conservation of complexity" law in programming. You
can try to sweep some complexity under the rug, but if you want to
solve real problems in the real world, it's bound to show up anyway.

When I was in college, all our programming assignments had a standard
sentence in them: You can assume all input is correct. I argued with
TA's that this simplified the problems by halve. Writing stuff that
has predictable behaviour and graceful failure mode when run with
incorrect input, with hard disks that are occasionally full and on a
network that can fail is something they should teach.

-- 
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Kent M Pitman
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <sfwn1ic516r.fsf@world.std.com>
Lieven Marchand <···@bewoner.dma.be> writes:

> To remain within the Lisp world, I find IS-LISP to be a better "small
> Lisp" than Scheme. It reminds me of the original infix syntax
> Dylan. The IS-LISP standard doesn't mention contributors. Was there
> much overlap between the two design communities?

(There's no hyphen in the name "IS-LISP".  ISLISP is, by informal 
agreement of those present when the name was chosen, an atomic name with
no subdividable meaning, and hence, I extrapolate, no appropriate name
subdivision.)

There wasn't much overlap between the Scheme and ISLISP design
communities.  There was briefly a Scheme liaison, but the Scheme
community more or less decided at some point that ISLISP was
irrelevant to them, so they stopped caring.  Form an official point of
view, they were never there in the first place, though since the only
official participants in ISLISP work are nations, not language bodies,
and X3J13 through Dick Gabriel and later me were the US delegates who
had much of any say.  There were a number of technical contributions
(e.g., by Japan, Germany, and France, who each had corresponding 
local standards efforts which influenced the design in various ways).
The US contribution was primarily editorial, though we contributed 
what I might whimsically characterize as "defensive" technical 
expertise, as probably did all committee participants at one time 
or another, both in the form of speaking against things we didn't like
(which I in my International Representative role took to mean "things
that were conceptually incompatible with Common Lisp") and helping to
craft compromises on things we found marginal but possibly survivable
if transformed appropriately.

> > It was all I could do to get them to acknowledge the horrible weakness in
> > call/cc in which it interacts horribly with unwind-protect, [...]

> I think they've had to come to terms with this in R5RS since they
> added dynamic-wind. I've never gotten my head enough around call/cc to
> check whether it really works in the weirder cases though.

This is not about dynamic-wind, which I see as an unrelated issue, indeed
requiring addressing, but being in fact addressed.  Dynamic wind is orthogonal
to the other issue I raise.

The issue, which really I'm the only one I've ever heard get excited about,
is that call/cc gets one too few bits as an argument, and so can't do the
right thing for gc.  The problem is that if you do a non-local throw (i.e.,
call to a continuation created outside the scope of the call/cc), you don't
know if you're going to return into the scope of the call/cc.  The consequence
is that only the gc can prove that it's safe to run the unwinds, and the
second order consequence is that the unwinds happen at an utterly random time.
So in the case of with-open-file kinds of operators, you know the file will
be closed but you don't know *when* it will be closed.  It will be closed
when the gc notices it's safe to call.  This problem could be corrected in
either of two obvious ways, and probably some others.  The two ways I've cited
are:

 (1) add an extra arg to call/cc saying if you want a one-time use 
     continuation.  in this way, you would know immediately when you
     called the continuation that it could not be invoked a second time.
     In this way, you'd know that any attempt to use this continuation
     would automatically void any possibility of re-returning from the
     continuation, thus making it immediately possible to finalize all 
     the other pending unwind actions below it.

 (2) keep call/cc as it is, but make every continuation take an argument
     saying if this is the last time it is to be used, effectively marking
     it void so it cannot be reused.  

Some examples where this comes up  in the real world relate to entertainment
facilities such as theme parks and movie theaters.  Imagine you are wathcing
a movie and you get up to go to the bathroom.  The projectionist, noticing
you are the last to leave, stops the film.  You return a half hour later,
annoyed that the show is not still running.  Indeed, you might have even
had to run home for a half hour and you might come back hoping to at least
catch the end.  A movie theatre technically can't reliably stop the film 
because it has no way to know whether your exit was a "final exit"; the ticket
you carry technically entitles you to infinite reentries (within a span of
time), even though practicality may suggest otherwise.  A theme park like
Disney World takes the opposite approach: if you leave,  you can't get back in
even during the day you'd contracted for unless you specifically tell them
at time of exit that you plan to re-enter and get your hand stamped. (Odds
are low that the park ever empties anyway, and especially low that on the
same day, no one thought to get a hand stamp, but even so, there's in 
principle the possibility that they all get to go home early guilt-free 
because at least entry/exit is guarded by this one extra piece of intent
info.

Dynamic-wind is effectively a mechanism for managing process switching, but
still doesn't address this issue of whether if a non-dynamic-wind continuation
is called, it's the last time it might.  

> They still say the behaviour if you escape from
> with-{in,out}put-{from,to}-file is implementation dependent.

I am moving to a new house and my copies are packed, but there was a change
in wording from R4 to R5 at my insistence to make this issue more apparent.
In the past, it was really obscure and harder to notice.  The change still
didn't make me that happy, but was an improvement.
 
> > No, the Scheme standard doesn't get a vote from me for best
> > standard.  I think it serves a certain community in a certain
> > limited way.  It's a cute toy language but it was kept from being
> > anything real by an overzealous desire to be textually compact.
> 
> I believe in a "conservation of complexity" law in programming. You
> can try to sweep some complexity under the rug, but if you want to
> solve real problems in the real world, it's bound to show up anyway.
> 
> When I was in college, all our programming assignments had a standard
> sentence in them: You can assume all input is correct. I argued with
> TA's that this simplified the problems by halve. Writing stuff that
> has predictable behaviour and graceful failure mode when run with
> incorrect input, with hard disks that are occasionally full and on a
> network that can fail is something they should teach.

I agree with you there.  See the footnote in CLTL2's error handling chapter
which I twisted Steele's arm to add to the error handling document he 
otherwise wanted to include literally from my X3J13 document; I'd given some
whimsy example of how you could "rely" on ERROR to stop your program and
was fearful of having that remark get out into the real world without some
caveats attached.  We ended up leaving the remark in place but footnoting the
possibility of miscompilations, parity errors, or something like that.
I don't remember precisely.  But it made me feel a little better.

One of my very first programs, which I wrote in the days when I really yet
had no instructor and was mostly teaching myself BASIC after only a bare-bones
course by someone else in FORTRAN left me in a situation where I had an IF
that had no "else" because "the situation was impossible".  Feeling odd about
that, I put in the classic PRINT "this can't happen"  expression and went
about the rest of my programming.  Within a few days, I saw the
"this can't happen" printed on the console, and learned something about
the importance of atomicity in data storage/retrieval.  (i'd aborted a tape
in mid-write and the data was in a format that no complete action of the
program could ever leave it.)  One just never knows.  And I agree with you
completely--they SHOULD teach that.
From: Lieven Marchand
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <m34s4jst2l.fsf@localhost.localdomain>
Kent M Pitman <······@world.std.com> writes:

> There wasn't much overlap between the Scheme and ISLISP design
> communities.  

Thanks for the background information, but I actually meant between
the Dylan and ISLISP communities.

-- 
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Kent M Pitman
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <sfw8ztvu0s9.fsf@world.std.com>
Lieven Marchand <···@bewoner.dma.be> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > There wasn't much overlap between the Scheme and ISLISP design
> > communities.  
> 
> Thanks for the background information, but I actually meant between
> the Dylan and ISLISP communities.

No overlap that I'm aware of.
From: Harley Davis
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <399c9cc8$0$226@newsreader.alink.net>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> Lieven Marchand <···@bewoner.dma.be> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > There wasn't much overlap between the Scheme and ISLISP design
> > > communities.
> >
> > Thanks for the background information, but I actually meant between
> > the Dylan and ISLISP communities.
>
> No overlap that I'm aware of.

Between the European Lisp communities (primarily England, France, Spain, and
Germany), the EEC-sponsored EuLisp evolving standard had a lot of at least
academic support, as well as industrial support from ILOG, the major non-CL
Lisp vendor at the time.  The EuLisp standard was influenced by Dylan, and
the goals were essentially the same, at least until Dylan diverged into
weirdness with its non-Lisp syntax.  There was some overlap with the
Harlequin Dylan group and the EuLisp group.  Almost all the European ISLisp
technical contributors were members of the EuLisp group, and pushed strongly
for a small (i.e., smaller than CL) but practical (i.e., more "good stuff"
than Scheme) Lisp - which was after all the goal of EuLisp.

-- Harley
From: Kent M Pitman
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <sfwu2cjkzoa.fsf@world.std.com>
"Harley Davis" <·············@nospam.museprime.com> writes:

> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
> > Lieven Marchand <···@bewoner.dma.be> writes:
> >
> > > Kent M Pitman <······@world.std.com> writes:
> > >
> > > > There wasn't much overlap between the Scheme and ISLISP design
> > > > communities.
> > >
> > > Thanks for the background information, but I actually meant between
> > > the Dylan and ISLISP communities.
> >
> > No overlap that I'm aware of.
> 
> Between the European Lisp communities (primarily England, France, Spain, and
> Germany), the EEC-sponsored EuLisp evolving standard had a lot of at least
> academic support, as well as industrial support from ILOG, the major non-CL
> Lisp vendor at the time.  The EuLisp standard was influenced by Dylan, and
> the goals were essentially the same, at least until Dylan diverged into
> weirdness with its non-Lisp syntax.  There was some overlap with the
> Harlequin Dylan group and the EuLisp group.  Almost all the European ISLisp
> technical contributors were members of the EuLisp group, and pushed strongly
> for a small (i.e., smaller than CL) but practical (i.e., more "good stuff"
> than Scheme) Lisp - which was after all the goal of EuLisp.

This is a good clarification.  I had interpreted the question literally as
"did dylan designers sit on the islisp committee", which probably was an 
overly restrictive view, and led me to probably an unhelpful answer.
Thanks for fixing it up.
From: Rob Warnock
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <8ngd7n$hb56r$1@fido.engr.sgi.com>
Kent M Pitman  <······@world.std.com> wrote:
+---------------
| The issue, which really I'm the only one I've ever heard get excited about,
| is that call/cc gets one too few bits as an argument...
| ...two obvious ways, and probably some others.  The two ways I've cited are:
|  (1) add an extra arg to call/cc saying if you want a one-time use ...
|  (2) keep call/cc as it is, but make every continuation take an argument...
+---------------

Several Schemes agree with the general sentiments you voice, but have
chosen to:

   (3) Leave call/cc as it is, and add a separate primitive to reify
       "one-shot" continuations.

[MzScheme calls this "call/ec" a.k.a. "call-with-escaping-continuation".
It also provide the convenience macros "let/cc" & "let/ec". More info
at <URL:http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node86.htm>.]


-Rob

-----
Rob Warnock, 41L-955		····@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		PP-ASEL-IA
Mountain View, CA  94043
From: Dorai Sitaram
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <8nh9u5$9fl$1@news.gte.com>
In article <··············@fido.engr.sgi.com>,
Rob Warnock <····@rigden.engr.sgi.com> wrote:
>Kent M Pitman  <······@world.std.com> wrote:
>+---------------
>| The issue, which really I'm the only one I've ever heard get excited about,
>| is that call/cc gets one too few bits as an argument...
>| ...two obvious ways, and probably some others.  The two ways I've cited are:
>|  (1) add an extra arg to call/cc saying if you want a one-time use ...
>|  (2) keep call/cc as it is, but make every continuation take an argument...
>+---------------
>
>Several Schemes agree with the general sentiments you voice, but have
>chosen to:
>
>   (3) Leave call/cc as it is, and add a separate primitive to reify
>       "one-shot" continuations.
>
>[MzScheme calls this "call/ec" a.k.a. "call-with-escaping-continuation".
>It also provide the convenience macros "let/cc" & "let/ec". More info
>at <URL:http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node86.htm>.]

I addressed Kent Pitman's point during a previous time
when someone raised it here, but maybe it bears
repetition:

A call/cc that produces one-shot continuations is
already too powerful for unwind-protect.  See the
Friedman & Haynes writeup on "Constraining Control"
(written in the early 80s, so it's a longstanding
result) where they show that such a call/cc can
be used to implement "regular" call/cc.  It will not
work any better with unwind-protect than "regular"
call/cc.

The flag argument, whether demanded of the reifier or
the continuation, doesn't really help.  I.e., even if
the flag were always said to the weaker value (say #t
for one-shot), unwind-protect won't deliver what we
expect of it.  (Obvious corollary of previous
paragraph.)

No, this is not intuitively obvious even after one
follows all the steps, but there it is.  

*

Escaping continuations, although one-shot, are a
different concept than one-shot continuations.  The
only way they would work with unwind-protect would be
if you only had escaping continuations (modulo syntax,
this degenerates to the CL scenario, where all
continuations are escaping).  The moment include
"regular" continuations also in the soup,
unwind-protect will cease to have its guarantee.

--d
From: Kent M Pitman
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <sfwaeebu0ta.fsf@world.std.com>
····@goldshoe.gte.com (Dorai Sitaram) writes:

> Escaping continuations, although one-shot, are a
> different concept than one-shot continuations.  The
> only way they would work with unwind-protect would be
> if you only had escaping continuations (modulo syntax,
> this degenerates to the CL scenario, where all
> continuations are escaping).  The moment include
> "regular" continuations also in the soup,
> unwind-protect will cease to have its guarantee.

I don't have a problem about this.  I basically think that one-shot
continuations are the "norm" upon which unwind-protect rests, and
that the reentrant continuations do necessarily create a mess that
they can then take responsibility for.  My problem is when people
use them because they have no other choice and are screwed by the 
(unwanted) overpower of them.
From: Dorai Sitaram
Subject: Re: best standard? [was Re: RFC: Lisp/Scheme ...]
Date: 
Message-ID: <8nhlv4$9p4$1@news.gte.com>
Kent M Pitman wrote: 
>····@goldshoe.gte.com (Dorai Sitaram) writes:
>> Escaping continuations, although one-shot, are a
>> different concept than one-shot continuations.  The
>> only way they would work with unwind-protect would be
>> if you only had escaping continuations (modulo syntax,
>> this degenerates to the CL scenario, where all
>> continuations are escaping).  The moment include
>> "regular" continuations also in the soup,
>> unwind-protect will cease to have its guarantee.
>
>I don't have a problem about this.  I basically think that one-shot
>continuations are the "norm" upon which unwind-protect rests, and
>that the reentrant continuations do necessarily create a mess that
>they can then take responsibility for.  My problem is when people
>use them because they have no other choice and are screwed by the 
>(unwanted) overpower of them.

These people should disable reentrant continuations.
Same paper I mentioned before tells how.

Perhaps the objection is that reentrant continuations
need to be explicitly taken out of circulation in
order for unwind-protect to work?  Well, that's an
unavoidable problem with any language that allows any
kind of reentrant continuation (one-shot, with flag
arguments, whatever).  There is nothing one can do
about it and no amount of band-aid will cure it.  Same
paper gives insight why this is.  (It doesn't come
right out and say it, probably because it is too
obvious if this is indeed the lesson you want to draw
(it is a paper about call/cc, not particularly
about unwind-protect).)

--d

ps:  Based on your text, either (1) you consider the
terms "one-shot continuation" and "escaping
continuation" to be synonyms, or (2) you tacitly
think they are operationally equivalent even if their
definitions differ.  I thought it was (2) at first,
but it seems like (1) now.

To clarify my usage:

One-shot == used only once.  

Escaping == can't be used outside the dynamic
extent of the corresponding call/cc call.

One-shot is-a-proper-superset-of Escaping. 
From: felix
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <speegjg1n4t127@corp.supernews.com>
Erik Naggum wrote in message <················@naggum.net>...

>* "felix" <·····@anu.ie>
>| If you mean that the Scheme-standard is full of holes, yep, you're
>| right with that.
>
>  The Scheme standard is possibly the single best standard there is,
>  and such as snotty remark as your betrays utter ignorance of its
>  contents.  Do yourself a favor, and don't do marketing for Scheme.

(Are we in a bad mood today, old friend?)

Perhaps we have a different view of the term 'holes', here. What I
mean is that the R5RS leaves (intentionally, I think) many things out
that are useful for practical programming.
(BTW, may I cite you in the future for calling it the "single best standard
there is" ?)

>| No, I'm not talking about the language Scheme as defined in the
>| standards document, I'm talking about the language Scheme as
>| implemented, in "real live", as you call it.
>

>  Some of us like to program to specifications, not just hope it works.


The CL specification won't help you writing networking code, or
graphics stuff.

>| BTW, how many CL implementations adhere *fully*, 100%, to the
>| Hyperspec?
>
>  None.  They adhere to the standard, ANSI X3.226-1994.


Sorry, I will try to be more precise the next time.

>| I'm sure every implementation has it's little incompatibilities
>| (especially in a *huge* language like Common LISP).
>
>  Arguments from ignorance are _so_ powerful.


What do you mean by that? (I'm a liitle bit slow, you know)

>| Anyway, I think you are right in that the R5RS isn't really that
>| great.  But Scheme (and many of it's implementations) is! ;-)
>
>  None have said that R5RS isn't great.  It really is, as a standard.
>  If you bothered to read it, instead of parroting comments you don't
>  grasp, you would have the possibility of understanding this yourself.


I'm sorry, but I thought this (part of this) thread was about the
specification
of Scheme's syntax, regarding things like '(if 1 2 . (3))'. The fact that
many
implementations handle this differently to the exact words of the standard
*can* be an indication for an insufficient specification.

>  The reason Scheme sucks, and it does, is that a beautiful standard
>  is not enough.  A necessary condition, but not a sufficient one in
>  any capacity at all.  If all the good stuff is extra-standard, the
>  _language_ has serious problems.


That depends largely on what you call "good" stuff.
I rather doubt that you can live without all those extras and goodies
provided
by the CL implementation you use, that are *not* mentioned in the
ANSI spec. And never will be, because a standard could never keep
pace with the pressure implementations put on language features, or
with "real world" demands. Some standards are just bigger right from
the start.
I would not say that CL "sucks", just because it's specification doesn't
cover all aspects of the language that are in use.

>| (Sorry, I couldn't resist, I just can't stop teasing ;)
>
>  I wonder who you think you're teasing, flaunting your ignorance.


Man, you defnitely have absolutely no sense of humor!
But thank you anyway for taking so much time to answer my posting.
Much appreciated!


Hugs and kisses,
felix


P.S.: You sound rather aggressive, Erik, old pal. Do you
have a blood-pressure problem? Are you consulting a
doctor regularly?
From: Pierre R. Mai
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <87itt441w2.fsf@orion.bln.pmsf.de>
"felix" <·····@anu.ie> writes:

> >  Some of us like to program to specifications, not just hope it works.
> 
> 
> The CL specification won't help you writing networking code, or
> graphics stuff.

[...]

> >  The reason Scheme sucks, and it does, is that a beautiful standard
> >  is not enough.  A necessary condition, but not a sufficient one in
> >  any capacity at all.  If all the good stuff is extra-standard, the
> >  _language_ has serious problems.
> 
> 
> That depends largely on what you call "good" stuff.
> I rather doubt that you can live without all those extras and goodies
> provided
> by the CL implementation you use, that are *not* mentioned in the
> ANSI spec. And never will be, because a standard could never keep
> pace with the pressure implementations put on language features, or
> with "real world" demands. Some standards are just bigger right from
> the start.
> I would not say that CL "sucks", just because it's specification doesn't
> cover all aspects of the language that are in use.

Well, what you seem to fail to notice is that there comes a point
where differences in quantity do indeed turn into differences in
quality:

It is fully possible to write major applications and libraries
staying wholly within the bounds of ANSI CL.  And there are even
more applications and libraries that can be written in ANSI CL with
just the use of 10-15 lines of implementation dependent code (where
the application in question is >> 10000 LoC).

Furthermore there exist a number of layered standards and de-facto
standards that extend ANSI CL in a _documented_ way.  If e.g. Franz
claims that ACL supports the MOP, then I can pretty well rely on the
behaviour documented in Ch. 5 + 6 of AMOP, and report any
discrepancies as bugs.  The same goes for all the other currently
supported CL implementations I'm aware of.

Still further, most CL implementors take the task of documenting their
extensions to ANSI CL quite seriously, so that I can still code to a
specification when I leave ANSI CL.

And finally most of the areas which the ANSI CL standard doesn't
define are not part of what I'd call language infrastructure,
i.e. stuff that different programmers have to agree on for their code
to interoperate usefully, stuff like exception signalling and
handling, structures and object system, the macro system, etc.

It's a huge difference whether one language doesn't include networking
control stuff (especially since at the time the standard was developed
BSD sockets were not as dominant as a OS networking interface as it
now is), or it doesn't include standardized ways to signal and handle
exceptions, handle tuple data types, etc.

And the Scheme comunity knows this!  That's one of the reasons they
have started the RFI process to extend the reach of consensus on the
important infrastructure stuff.

Whether that's the right approach for the Scheme comunity or not is
not for me to judge, since I'm not a part of it, and don't plan to
become one, since CL is much further along the curve of integrating
important and hard infrastructure stuff into the language standard,
and will IMHO be for a long time.

Would it be nice to have a standardized interface to BSD sockets,
especially now that it's quickly becoming the single surviving OS
networking interface?  Certainly.  Would it be nice to have a
standardized exception handling API?  Definitely not:  it would be a
_necessity_ before I'd even consider a language for any serious
project.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3175256362090366@naggum.net>
* "felix" <·····@anu.ie>
| (Are we in a bad mood today, old friend?)

  Do I know you?  Whence this repulsive friendliness?

| The CL specification won't help you writing networking code, or
| graphics stuff.

  Neither do ANSI standards for steel qualities.  So what's your point?

| The fact that many implementations handle this differently to the
| exact words of the standard *can* be an indication for an
| insufficient specification.

  Well, regardless of what _might_ be, it isn't.

| >  The reason Scheme sucks, and it does, is that a beautiful standard
| >  is not enough.  A necessary condition, but not a sufficient one in
| >  any capacity at all.  If all the good stuff is extra-standard, the
| >  _language_ has serious problems.
| 
| That depends largely on what you call "good" stuff.

  No, it doesn't.  It's an implication, the truth of which can very
  well be established without establishing or even agreeing on the
  truth of the premise.  But I guess you're as repulsively sloppy as
  you are repulsively friendly to strangers.  So why are you begging
  for small change on USENET?  Surely there must be a train station
  nearby where you can ingratiate yourself with and/or harrass some
  strangers in exchange for a few pennies?

  The language has serious problems even if only most of _whatever_
  counts as "the good stuff" is extra-standard.  Do you understand?

| I rather doubt that you can live without all those extras and
| goodies provided by the CL implementation you use, that are *not*
| mentioned in the ANSI spec.

  Look, the ANSI X3.226-1994 doesn't prescribe my nutrition, either.
  What's your point, other than spouting increasingly bland nonsense?

| I would not say that CL "sucks", just because it's specification
| doesn't cover all aspects of the language that are in use.

  Sad, because then you would _really_ be doing yourself a favor.

  Let's see if you can figure out where you lost track of what I said
  and this stupid notion cropped up that Scheme sucks "just because
  [its] specification doesn't cover all aspects of the language that
  are in use".  (Whoever talks about "all aspects of the langauge"?)

| Man, you defnitely have absolutely no sense of humor!

  That you don't understand something doesn't mean it doesn't exist.
  That you don't laugh indicates that you take things too personally,
  as indeed you do, abuser and reducer of phrases like "old friend".

  Someone as ridiculous as yourself may be used to people laughing,
  but trust me on this: If they do, it is not because of good humor.

| P.S.: You sound rather aggressive, Erik, old pal.  Do you have a
| blood-pressure problem?  Are you consulting a doctor regularly?

  Take your disgustingly fake personal concern for me and stuff it up
  your ass!  If you want to get personal, you have chosen the wrong
  medium.  Try one of those dating hotlines, instead.  Remember to say
  you like to act friendly with strangers so they can connect you with
  a suitable perversion.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: felix
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <sph2uprskn966@corp.supernews.com>
Mild-mannered Erik Naggum makes another subtle point...

[...]

Erik, again, thank you for putting so much time, effort and patience into
answering my posting! You are a real chum!


felix
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3175018360341788@naggum.net>
* "felix" <·····@anu.ie>

  Please appreciate the difference between a specification and its
  implementation.  Scheme has an excellent specififcation of so little
  that you guys have to rely on implementation-specific extensions to
  get any real work done, but that doesn't mean you should _forget_
  the specification.  The same applies to macros, of course.
 
#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Christopher Browne
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <slrn8p6t4h.psv.cbbrowne@dantzig.brownes.org>
Centuries ago, Nostradamus foresaw a time when felix would say:
>Erik Naggum wrote in message <················@naggum.net>...
>In another posting you wrote:
>
>>  ... Hell, they [the ones from the Scheme camp] don't even believe in
>>  compile-time manipulation of the code...
>
>Now, please, how exactly do you come to that conclusion?
>(I expect you know about macros in Scheme, but perhaps I
>have to alter my expectations)

A legitimate problem is that there's not a single scheme for
handling macros, but rather two or three, most of which are
somewhat less powerful than CL macros.
-- 
·····@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/linux.html>
"If you were plowing a field,  which would you rather use?  Two strong
oxen or 1024 chickens?"  -- Seymour Cray
From: felix
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <sp927l8kn4t50@corp.supernews.com>
Christopher Browne wrote in message ...

>A legitimate problem is that there's not a single scheme for
>handling macros, but rather two or three, most of which are
>somewhat less powerful than CL macros.


Most Scheme-implementations support the 'defmacro'-style
way of macros, like this:

(define-macro (when test . body)       ; or 'defmacro'
  `(if ,test (begin ,@body) #f) )

I don't see the difference to CL macros. I just don't see it.
(Those implementations that provide this type of macros also
have gensym, so it is *exactly* the same).

The 'define-syntax' stuff is something different, and I agree with
everybody who isn't particularly fond of them. But since the
oh-so-powerful CL-macros are easy to implement, many Scheme
implementations provide them.


felix
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3175089503873738@naggum.net>
* "felix" <·····@anu.ie>
| I don't see the difference to CL macros. I just don't see it.

  Open your eyes.  CL macros are in the language specification.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Robert Monfera
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <398A4217.72882A6A@fisec.com>
Craig Brozefsky wrote:
> 
> Erik Naggum <····@naggum.net> writes:
> 
> >   I think "down" and "up" are equally useful/likely "buttons".  I use
> >   Emacs with these operations all the time, in fact.  Very seldom do I
> >   type invididual parentheses.
> 
> How do you avoid that?

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

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

Robert
From: Tom Breton
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <m366p8pzr6.fsf@world.std.com>
> Robert Monfera <·······@fisec.com> writes:
> 
> > Is anyone using an editor such a way that hitting the left paren inserts
> > a matching right paren?   (|  ->   (|)

I am all the time.  I use (and wrote) sm-insert.el for emacs which
does the same for braces, brackets, anything the syntax table defines
as matching delimiters.

-- 
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.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <39922428.91B7C295@kurtz-fernhout.com>
Erik-

Ouch!

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

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

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

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

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

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

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

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

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

You wrote in response to my comment:
>> Lisp uses structure to replace much of what other languages do with
>> syntax.
>
>   This is simply WRONG.  

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

I appreciate your taking the time to respond to the proposal.
 
Anyway, hoping to keep things cordial.

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

Erik Naggum wrote:
> 
> * Paul Fernhout <··········@kurtz-fernhout.com>
> | Has this been tried before?  If so, what was the outcome?
> 
>   You have broken the property of Lisp that code can be read as data,
>   and code printed as text to be read back in.  You don't seem to be
>   aware of the fact that Lisp code is readable by the Lisp system, but
>   instead treat it as if Lisp were a language with a syntax it could
>   not itself simply "read", like Python.  And like Scheme.  This is
>   where Scheme departed most clearly from the Lisp camp, years ago.
>   Scheme code is made up of characters and tokens.  Lisp code is made
>   up of lists and elements.  The difference is _monumental_ in scope.
> 
> | One advantage to such an approach it that it might make it easier to
> | compose Lisp on devices without keyboards. An indent-line button and an
> | unindent-line button would be useful in that case.
> 
>   I think "down" and "up" are equally useful/likely "buttons".  I use
>   Emacs with these operations all the time, in fact.  Very seldom do I
>   type invididual parentheses.
> 
> | Significant indentation might make it easier for developers who don't
> | know Lisp well to understand a Lisp program's structure.
> 
>   Nonsense.
> 
> | Every additional character on the screen takes more time for the eye
> | and mind to process.
> 
>   This silly metric runs counter to much cognitive science.
> 
>   forinstanceithaslongbeenknownthataddingsuperfluouscharacterslike
>   whitespaceandpunctuationmarksimprovereadabilitysignificantly
> 
> | In practice, experienced Lisp developers will rely on the
> | indentation anyway -- as editors are used to count parentheses.
> 
>   If you rely on something, would you be happy if someone removed that
>   which what you rely on rests?  I would be unhappy, as that which I
>   rely on is now in danger of collapsing, as surely your syntax would
>   as soon as the next clever idea comes along.
> 
> | Such code will be faster to create.
> 
>   Drop the marketing and your credibility will improve.
> 
> | There is less typing, and no worry about unbalanced parentheses.
> 
>   Again, drop the marketing.  How do you determine the indentation?
>   That alone looks like _more_ typing to me.
> 
> | Also, with significant indentation, indentation can not as often be
> | misleading as it can be with parentheses.
> 
>   Your credibility is suffering with this line, too.
> 
> | ======= Some disadvantages =======
> |
> | I'm sure people will point out lots. Send 'em on!
> 
>   This idiocy hints that you're ill-prepared for your own proposal.
> 
> | The major one is that this is non-standard and not available.
> 
>   The major one is that you're breaking a very significant property of
>   the language, and you're not even aware of it.
> 
>   Oh, right, you're thinking in Scheme, which _is_ a language that
>   breaks this important property of Lisp, and has a character-level
>   syntax, like Algol.
> 
> | ======= More issues to consider =======
> |
> | One issue is that parenthesization is redundant when you use
> | indentation.
> 
>   Predictable redundancy is what keeps people sane.
> 
> | Another way to look at it is, in practice, a Lisp coder is already
> | doing these rules implicitly as part of the conventional indentation
> | process.
> 
>   You seem to think that Lisp "coders" indent their code by hand.
>   They don't.
> 
> | So this approach just loses some of the extra burden of worrying
> | about quite a few of the parentheses, which are syntactically
> | redundant if proper indentation is in place.
> 
>   Lisp programmers (I take exception to "coders") don't count parens,
>   but use automatic re-indentation to check that they got it right.
>   When you remove one of these "redundant" parts, you remove the tool
>   that makes indentation sufficient _after_the_fact_.
> 
> | Yes, people put down Lisp saying it stands for "Lots of Infernal Stupid
> | Parentheses".  Rather than be defensive, here is an approach that might
> | do something about what much of the world perceives as a difficulty in
> | reading and writing Lisp code.
> 
>   Rather than be defensive, be smart and ignore the infernal idiots.
> 
> | Making indentation significant works for Python.
> | Why not make it work for Lisp too?
> 
>   Because Lisp doesn't have _syntax_ the way Python has.
> 
>   You have redesign the Lisp reader and printer to be able to perform
>   this incredibly silly stunt, and you aren't even _aware_ of that,
>   either.  Go do your homework, and be creative when you know what
>   your "good ideas" are affecting.
> 
> | Learning from Python's mistakes (tabs are allowed and they are
> | expanded inconsistently on various systems) I would suggest always
> | requiring two spaces per level of indentation.
> 
>   But you don't even understand how the current indentation is used!
> 
> | I'm not going to say this wouldn't take some getting used to for
> | experienced Lisp hackers.
> 
>   Hey, not to worry, most of the experienced Lisp hackers around have
>   been to one more universities, and anyone who has been to any
>   university has seen the freshman who knows how to run the whole
>   place better than everybody who has ever actually run a university.
>   "Clever" novices is old hat to us old farts.
> 
> | ======= Psychobabble justification =======
> |
> | Some level of complexity in any task exists. It can often be pushed
> | around however, or refactored into different chunks. Sometimes, a
> | refactoring of compelxity will fit more naturally onto what most
> | human minds do well.
> 
>   Pardon me, but most human minds don't to programming well at all.
>   The few that do, tend to be very diverse.  Much more so than those
>   that do, e.g., plumbing or carpentry well.  Programming is like an
>   art in many ways because of this diversity of its performers.  Some
>   like Lisp because Lisp is Lisp.  You don't.  That may mean your mind
>   doesn't work the way that other Lisp programmers' minds work.  I
>   know my mind doesn't work the way Perl programmers' minds work, and
>   while I think Perl is the suckiest language ever, I don't handle the
>   way purely functional languages work very well, either, and while I
>   could be "proud" of being "above" Perl, I can't be proud of being
>   "below" functional languages, as those are somehow "better".  I have
>   come to recognize that I understood SGML very well because my mind
>   works very well with hierarchical, nested structures and languages
>   that describe them.  If your mind doesn't work that way, come to
>   peace with yourself and do something else: I have "decided" not to
>   work with Perl and C++ and such things, in the sense that I know
>   that I couldn't be so good at it that it would be rewarding in
>   itself to work with these languages.  It _is_ rewarding in itself to
>   work with Lisp.  For me.
> 
> | This is because the human mind is quirky that way.
> 
>   Some day, I hope you will recognize that "the human mind" is one of
>   the stupidest things you can say.  We're not 6 billion people who
>   differ only in fingerprints, you know.  We're surprisingly different
>   mentally, too.  _Diversity_ is the name of the game.  Accepting it
>   is not very different from getting used to people having different
>   color skins.  After you accept it, you automatically accept that
>   people who are like-minded in any of whole range of different ways
>   will congregate.  Lisp programmers congregate for such reasons, and
>   they don't _need_ your misplaced, misunderstood syntax.
> 
> | For example, it is easier to remember a seven digit phone number
> | than a fifteen digit number.
> 
>   But it's easier to remember an eight-digit phone number with a large
>   degree of systematic relation to something you know well, such as
>   geography, than to remember a six-digit phone number that appears to
>   be randomly allocated.  (Empirical results from the expansion of the
>   Norwegian phone number system, which went from 5- and 6-digit local
>   numbers with 1- or 2-digit area codes to a uniform 8-digit system.)
>   It's also easier to remember a ten-digit phone number than to take
>   short-cuts and remember only the seven last digits and _hope_ you're
>   in the right area.  (Empirical evidence from area code splits in the
>   U.S., repeated many times, and well documented in telephone circles.)
> 
> | Together these let you run about seven digits (each digit itself a
> | chunk) through your mind while you dial a seven digit telephone
> | number.
> 
>   Remembering phone numbers are similar to musical memory.  We don't
>   remember individual digits, but somehow find an internal "rhythm" to
>   them.  Much recent research into memory has concentrated on the
>   "rhythm" theories, both in spelling and remembering numbers, music,
>   exact quotes, poems, stories, names, etc.  People who are unable,
>   for a variety of reasons, to map events to rhythms, lose out.  This
>   has absolutely nothing to do with the theory you ascribe to numbers.
> 
> | ======= Conclusion =======
> |
> | Lisp uses structure to replace much of what other languages do with
> | syntax.
> 
>   This is simply WRONG.  Do your homework, and come back later.
> 
> | Have I missed something technical that makes indentation unworkable?
> | Obvious it faces an uphill battle for social acceptance and
> | implementation into specific Lisp and Scheme systems.
> 
>   You will meet much less resistance in the Scheme camps, as they have
>   already dispensed with the notion that code should be readable as
>   data.  Hell, they don't even believe in compile-time manipulation of
>   the code, so there's no _need_ to be able to read it as data.
> 
> | If people think this idea is interesting and has no obvious technical
> | flaws, I may proceed to try and see if I can get this to work in
> | DrScheme.
> 
>   That sounds like a good idea.  However, I suggest you keep Common
>   Lisp out of your experiment.
> 
> #:Erik
> --
>   If this is not what you expected, please alter your expectations.
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <m31yzxwr8x.fsf@cadet.dsl.speakeasy.net>
Erik Naggum <····@naggum.net> writes:

> * Paul Fernhout <··········@kurtz-fernhout.com>
> | Also, with significant indentation, indentation can not as often be
> | misleading as it can be with parentheses.
> 
>   Your credibility is suffering with this line, too.

In a case like this:

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

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

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

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

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

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

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

dave
From: David J. Cooper
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <pmq8zu7vzv3.fsf@lang.genworks.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

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

...

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


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


 -dave


-- 
David J. Cooper Jr, Chief Engineer	Genworks International
·······@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
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <39916558.8FF33A23@kurtz-fernhout.com>
David-

Thanks for the reply. 

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

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

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

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

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

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

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


"David J. Cooper" wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > I'm interested in using significant indentation (like in Python)
> >   http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
> >
> 
> > ======= Small example =======
> >
> 
> ...
> 
> >
> > Lisp uses structure to replace much of what other languages do with
> > syntax.
> > Understanding the physical tree structure of a Lisp program is paramount
> > to determining what it does. Why not let that structure be defined
> > syntactically by indentation as an option?
> >
> > Any comments? Have I missed something technical that makes indentation
> > unworkable? Obvious it faces an uphill battle for social acceptance and
> > implementation into specific Lisp and Scheme systems.
> >
> > If people think this idea is interesting and has no obvious technical
> > flaws, I may proceed to try and see if I can get this to work in
> > DrScheme.
> >   http://www.cs.rice.edu/CS/PLT/packages/drscheme/index.html
> >
> 
> If you are going to try to get this to work in something, why not try
> getting it to work in Emacs Lisp? I would think that to operate in
> this mode you would want to be able to have a buffer you could with a
> keychord switch between fully parentesized and significantly indented
> representations. The Emacs compile command could simply convert to
> parentesized mode before actually compiling, and files would also be
> saved out in fully parenthesized mode by default (so they can be
> compiled normally).
> 
>  -dave
> 
> --
> David J. Cooper Jr, Chief Engineer      Genworks International
> ·······@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
From: Rainer Joswig
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <joswig-9637CC.11502709082000@news.is-europe.net>
In article <·················@kurtz-fernhout.com>, Paul Fernhout 
<··········@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: ·············@corporate-world.lisp.de
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <399156EB.BA38AEEB@kurtz-fernhout.com>
Rainer-

Thanks for the reply. Some comments below.

Rainer Joswig wrote:
> 
> In article <·················@kurtz-fernhout.com>, Paul Fernhout
> <··········@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: ·············@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
From: Hartmann Schaffer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <39921279@news.sentex.net>
In article <·················@kurtz-fernhout.com>,
	Paul Fernhout <··········@kurtz-fernhout.com> writes:
> ...
> I think the answer is that when you copy and paste and code -- be it
> Lisp or C or whatever, you still need to make the indentation work out

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

> ...

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

-- 

Hartmann Schaffer
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <39929AF6.AA334112@kurtz-fernhout.com>
Hartmann -

Thanks for the comments.

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

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

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

Hartmann Schaffer wrote:
> 
> In article <·················@kurtz-fernhout.com>,
>         Paul Fernhout <··········@kurtz-fernhout.com> writes:
> > ...
> > I think the answer is that when you copy and paste and code -- be it
> > Lisp or C or whatever, you still need to make the indentation work out
> 
> you should eventualy, but with a delimiter based syntax you can feed
> it into the compiler o interpreter immediately (can help to determine
> whether what you want to do really works.  with an ndentation based
> syntax you must massage the code before you can try.  with some
> constructs it can also get considerably trickier (try inserting a
> block of code that ends with ifs nested several levels somewhere into
> i several level deep if structure and keep track which branch belongs
> to which level;  you'll love parentheses after that)
> 
> > ...
> 
> this is independent of the widespread (imo correct) opinion the too
> deep nesting should be avoided)
> 
> --
> 
> Hartmann Schaffer
From: Hartmann Schaffer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <39934ccd@news.sentex.net>
In article <·················@kurtz-fernhout.com>,
	Paul Fernhout <··········@kurtz-fernhout.com> writes:
> ...
> But, I think in practice, when indentation is significant, people tend
> to always do formatting right away when cutting and pasting anything --
> so as to always maintain the logical structure of the program. So, I

true, but contrary to the delimited syntax the whitespace syntax does
rely on errorfree editing.  in my experience (maybe it's just me, it
is quite easy to put the mark in the wrong place, leading to errors
that can be very hard to track down.  with a delimited syntax you the
cutted and pasted code being transferred with its delimiters simply
doesn't raise this problem, and if you made a mistake when cutting
(leaving out or adding a delimiter) you most likely will get a syntax
error. 

> don't see this being a big problem in practice, and in the Python or
> Occam case I don't remember ever experiencing such a problem (at least
> not down the road -- it may have been more of an issue at the start).

the problem with the white space syntax as i see it:  provided the
delimiters in the delimited syntax aren't too verbous, it buys you
very little in typing effort (in emac's python mode you have to use an 
extra keystroke to indicate that you want to revert the indentation to 
the previous level (at least most of the time), but it removes
valuable redundancy what you have when you combine a delimited syntax
with a pretty printer, where the programming environment uses what you 
typed to put the structure of your code on display.  i actually would
argue that the whitespace syntax, rather than being helpful and save
the programmer some work transfers a much harder burden (to keep track
of the structure) to the programmer.

I find typing an extra parenthesis no more burdensome than to hit a
key to tell the editor to reverse the indentation.  it might be a
little bit differend with very verbose delimiters (like mandatory 'end
keyword' etc)

-- 

Hartmann Schaffer
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant indentation?
Date: 
Message-ID: <39960932.DAC3212C@kurtz-fernhout.com>
Hartmann-

Thanks for the reply. You make some excellent points.

When discussing "error free" editing, I guess what it comes down to is
that the types of errors one can make using indentational syntax are
usually different from the ones made with explicit delimiters. Certainly
most programmers are used to explicit delimiters, and so one might
expect them to make less errors in that context as it is what they are
experienced with. And obviously, if the editing tools are set up to
support delimited syntax, that too makes it more likely programmers will
be more productive in such a setting. Whether indentational syntax used
for Lisp/Scheme in the hands of experienced programmers can ever meet
the standards of excellence maintained by programmers using the
conventional syntax is to me still an open question (although obviously
many people in this thread have pointed out difficulties which may or
may not be insurmountable in practice).

While I agree that an indentational syntax seems to put a heavier burden
on the programmer in terms of managing structure, it seems to me that in
some ways it just makes a burden that already exists more explicit, both
because the hierarchical structure of S-expressions is always visible,
and because it can be changed rapidly -- perhaps too rapidly, :-) as you
point out. The indentational syntax gives one a powerful tool to rapidly
change structure by deleting or adding some whitespace. One might argue
that managing whitespace is like having a chainsaw. Obviously, a
chainsaw is a dangerous tool -- and depending on the context, may be
quite inappropriate for the task at hand. I do remember seeing someone
sculpt wood with a chainsaw once -- most impressive (and scary!)

Still, ultimately, I am intrigued enough by it that I'd like to get to
the point where I could see it fail or succeed in practice. Famous last
words... :-) 

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

Hartmann Schaffer wrote:
> 
> In article <·················@kurtz-fernhout.com>,
>         Paul Fernhout <··········@kurtz-fernhout.com> writes:
> > ...
> > But, I think in practice, when indentation is significant, people tend
> > to always do formatting right away when cutting and pasting anything --
> > so as to always maintain the logical structure of the program. So, I
> 
> true, but contrary to the delimited syntax the whitespace syntax does
> rely on errorfree editing.  in my experience (maybe it's just me, it
> is quite easy to put the mark in the wrong place, leading to errors
> that can be very hard to track down.  with a delimited syntax you the
> cutted and pasted code being transferred with its delimiters simply
> doesn't raise this problem, and if you made a mistake when cutting
> (leaving out or adding a delimiter) you most likely will get a syntax
> error.
> 
> > don't see this being a big problem in practice, and in the Python or
> > Occam case I don't remember ever experiencing such a problem (at least
> > not down the road -- it may have been more of an issue at the start).
> 
> the problem with the white space syntax as i see it:  provided the
> delimiters in the delimited syntax aren't too verbous, it buys you
> very little in typing effort (in emac's python mode you have to use an
> extra keystroke to indicate that you want to revert the indentation to
> the previous level (at least most of the time), but it removes
> valuable redundancy what you have when you combine a delimited syntax
> with a pretty printer, where the programming environment uses what you
> typed to put the structure of your code on display.  i actually would
> argue that the whitespace syntax, rather than being helpful and save
> the programmer some work transfers a much harder burden (to keep track
> of the structure) to the programmer.
> 
> I find typing an extra parenthesis no more burdensome than to hit a
> key to tell the editor to reverse the indentation.  it might be a
> little bit differend with very verbose delimiters (like mandatory 'end
> keyword' etc)
> 
> --
> 
> Hartmann Schaffer
From: Hartmann Schaffer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant indentation?
Date: 
Message-ID: <399701d3@news.sentex.net>
In article <·················@kurtz-fernhout.com>,
	Paul Fernhout <··········@kurtz-fernhout.com> writes:
> Hartmann-
> 
> Thanks for the reply. You make some excellent points.
> 
> When discussing "error free" editing, I guess what it comes down to is
> that the types of errors one can make using indentational syntax are
> usually different from the ones made with explicit delimiters. Certainly
> most programmers are used to explicit delimiters, and so one might
> expect them to make less errors in that context as it is what they are
> experienced with. And obviously, if the editing tools are set up to

i don't see that.  when typing in new code you have to tell whatevever 
editing system you are talking to that you are at the end of a nesting 
level, and in my view there isn't much difference whether you type a
closing parenthesis, and 'end' or (as in emacs python mode
'backspace'.  the only difference i see that if i type ')' in lisp or
scheme mode the editor shows me where the beginning parenthesis is
(ither by highlighting it or by displaying the line where it is on in
the status line), while python mode apparently relies on the visual
information (which isn't of much use when the line has slipped out of
the window already).  with cutting and pasting you have to locate the
end of the nested structure and make sure that the nested structure
fits into its new environment, a task that ithink is much easier and
lends itself better to automated help from the editor if the code
comes with explicit delimiters.

> ...
> While I agree that an indentational syntax seems to put a heavier burden
> on the programmer in terms of managing structure, it seems to me that in
> some ways it just makes a burden that already exists more explicit, both
> because the hierarchical structure of S-expressions is always visible,

i am pretty sure that every experienced programmer uses indentation
when he types in his initial code.  my point is that with a delimited
syntax there is some redundancy that permits the tools i use to check
for and signal discrepancies:  if i type "indent region" and see some
lines shifting significantly, i know i have to check that area closely 
for typos.  similarly, if i hit 'tab' and the cursor moves to a point
where i don't expect it i better go chec and see why.  due to the
absence of delimiters, these aids are weaker with an indentation
syntax, and i don't think that this is a matter of what i am used to.

> and because it can be changed rapidly -- perhaps too rapidly, :-) as you
> point out. The indentational syntax gives one a powerful tool to rapidly
> change structure by deleting or adding some whitespace. One might argue

with delimiting syntax i can change the structure by inserting one
start and one end delimiter (i let the pretty printer built into the editor
take care of the indentation), while with indentation syntax i have to
shift a whole area.  seems to be very similar effort, with imo the
advantage going to the delimited syntax because i have to identify two 
points where i must apply the modifications while with indentation i
have to concentarte on a region instead.

> ...

-- 

Hartmann Schaffer
From: Rainer Joswig
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <joswig-23DEB0.16025009082000@news.is-europe.net>
In article <·················@kurtz-fernhout.com>, Paul Fernhout 
<··········@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.

-- 
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3991881D.A8DCBC1E@kurtz-fernhout.com>
Rainer -

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

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

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

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

If I may add something, when you wrote:

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

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

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

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

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

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

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

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

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

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

Rainer Joswig wrote:
> 
> In article <·················@kurtz-fernhout.com>, Paul Fernhout
> <··········@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.
> 
> --
> Rainer Joswig, Hamburg, Germany
> Email: ·············@corporate-world.lisp.de
From: Rainer Joswig
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <joswig-5E2843.21151709082000@news.is-europe.net>
In article <·················@kurtz-fernhout.com>, Paul Fernhout 
<··········@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.

-- 
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3991D898.636D5681@kurtz-fernhout.com>
Rainer-

Thanks for the further comments. 

You raise some excellent point. Comments below.

Rainer Joswig wrote:
> 
> In article <·················@kurtz-fernhout.com>, Paul Fernhout
> <··········@kurtz-fernhout.com> wrote:
> 
> > If I may add something, when you wrote:
> >
> >   (defun send-a-mail (from to subject)
> >     (let ((body (get-body 'introduction)))
> >
> > I had to actually count the parentheses to see if this was a complete
> > statement, to see if you were referring to inserting something within
> > the current structure or at the end of it. It wasn't immediately obvious
> > to me whether this fragment was a valid Lisp program or not. It is not.
> 
> I'm moving around in a Lisp buffer by Lisp expressions.
> I can easily "feel" whether this is valid or not, because
> I'm not only looking on the code, but I **feel** the code under
> the cursor. The belonging parentheses blinks if I place my cursor
> in front of the defun. If there is nothing blinking at the end
> I have a problem. If I move the cursor over the expression
> (c-m-forward or c-m-f) I see where it ends. Another keypress
> and the whole thing reindents. Another keypress: undo.
> I don't think about that - it's just learned and works
> intuitively.

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

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

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

> > If you had written (in indentational syntax, removing edge parentheses):
> >
> >   defun send-a-mail (from to subject)
> >     let
> >       ...
> >         body (get-body 'introduction)
> >
> > there would not be any question about validity. This has to be a valid
> > expression. At almost every point, an indentational syntax specification
> > is valid.
> 
> Not really. In Lisp you can write multiple level macros and
> Lisp expressions that have complex indentation descriptions.

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

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

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

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

It is valid. The equivalent Lisp is:

  (foo bar baz)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> How do add additional ways of code formatting?

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

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

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

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

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

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

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

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

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

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

  myfunction keyword1 value1
    keyword2
    value2
    keyword3
    value3

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

Since I am more interested in working in Scheme at this point, the
keyword issue is not as important to me (since I don't think Scheme
supports keywords).
 
Still, I think they are doable, but admittedly there is an awkwardness
perhaps.

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

Maybe it would be clearest if I had proposed a "indentational
preprocessor" for Lisp and Scheme. That is, it lets you write properly
indented code without the edge parentheses and then it puts them in.
Then it might be clearer that I am not in any way messing with the
notion of defining nested lists (hopefully, if the rules are correct).
I'm hopefully just changing something minor about the syntax involving
indentation and displaying edge parentheses, in the interest of what I
as an unseasoned Lisp user consider clarity.
  
> > features. But the technical question then is, could one have those
> > features and indentational syntax too?
> 
> You could have a lot of these. Hey, there was once a Haskell
> implementation written in Common Lisp. Haskell has also
> an indentation based syntax. AXIOM (a computer algebra system
> written in Common Lisp) also has an indentation based
> syntax (IIRC). So there might be some reason to experiment
> with it.

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

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

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

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

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

Thanks again. I've enjoyed all your 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
From: Eugene Zaikonnikov
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <6yog31jp8w.fsf@localhost.localdomain>
>>>>> "Rainer" == Rainer Joswig <······@corporate-world.lisp.de> writes:

[...]

    Rainer> Well, and this is still far from what the Lisp machine's
    Rainer> Zmacs does, where the editor for example parses the
    Rainer> buffers into definition chunks. So you edit a while in
    Rainer> your various Lisp buffers and after a while you say
    Rainer> "Compile Changed Definitions" and the Lisp system knows
    Rainer> what definitions you have changed and compiles them. And

IIRC, LispWorks IDE also has a feature like you described.

--
  Eugene.
From: Tom Breton
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <m33dke9r4x.fsf@world.std.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

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

-- 
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.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <39920DD6.F02721E3@kurtz-fernhout.com>
Tom-

Thanks for the comment. More comments below.

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

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

A simple example I can see that works might be:

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

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

  define (poo bar x y)

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

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

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

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

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

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

For example, in the following:
  
  A
    B
    C
     D

equivalent to:

  (A B (C D))

the four obvious valid S-expressions are:

1:
  A
    B
    C
     D

2:
    B

3:
    C
     D

4:
     D

I find all easily identifiable based on indentation.

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

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

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

Thanks again for the comments.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
From: Bruce Hoult
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <bruce-D4A1E2.09580310082000@news.akl.ihug.co.nz>
In article <·················@kurtz-fernhout.com>, Paul Fernhout 
<··········@kurtz-fernhout.com> wrote:

> Many people say of Python, "well if indentation is significant, how do I
> copy and paste code?"
> 
> I think the answer is that when you copy and paste and code -- be it
> Lisp or C or whatever, you still need to make the indentation work out
> to make the code readable. Often as not this is done by hand. Yes, some
> editors could pretty print the code after cut and paste, but for short
> things typically one may fix it up by hand, especially if you don't
> always agree with the pretty-printer. 
> 
> Editors designed to support indentation usually have block indent and
> block dedent commands. This makes the procedure of copying code more
> like: "cut", "paste" and then "block indent/dedent to desired nesting". 

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

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


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

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

-- Bruce
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <OIWRObK+YXDOqOWxbe9FJFyrn7xN@4ax.com>
On Wed, 09 Aug 2000 00:37:23 -0400, Paul Fernhout
<··········@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/
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <39919CF0.6F583B33@kurtz-fernhout.com>
Paolo-

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

Paolo Amoroso wrote:
> 
> On Wed, 09 Aug 2000 00:37:23 -0400, Paul Fernhout
> <··········@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
From: Rainer Joswig
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <joswig-76A671.21253909082000@news.is-europe.net>
In article <·················@kurtz-fernhout.com>, Paul Fernhout 
<··········@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.

-- 
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <3991CA48.78E5E9F7@kurtz-fernhout.com>
Rainer-

Thanks for the comments. Some more below.

Rainer Joswig wrote:
> 
> In article <·················@kurtz-fernhout.com>, Paul Fernhout
> <··········@kurtz-fernhout.com> wrote:
> 
> > But how many people are there out there who might develop in Lisp and
> > Scheme who never can get past the parentheses? Obviously, Lisp has not
> > caught on yet in commercial usage to the degree it deserves compared to
> > say C, considering the elegance and power of the system (notable
> > exceptions like http://www.franz.com/success/ excepted). Instead, more
> > people are doing C, Visual Basic, and Python etc. I understand there are
> > many, many reasons for a language's fate that have little to do with the
> > language itself, for example Java hype or even "Worse is Better".
> >   http://www.jwz.org/doc/worse-is-better.html
> > Still, maybe this indentational technique could help bring more people
> > into doing Lisp or Scheme?
> 
> Actually Lisp was very big at Apple years ago. Still Apple
> thought that Lisp syntax  was not for the end user.
> So we got AppleScript, NewtonScript, Sk8Script, HyperTalk, Dylan, ...
> These languages were all more or less based on Lisp's
> technology (objects, symbols, message passing, GC, ...).
> Still I think a multitude of syntaxes in a non-integrated
> way is not of benefit to the user. The development environments
> were always rewritten from scratch - often with poor editor
> support. But Apple always thought that the ordinary programmer
> was not ready for the complexity and the paradigm shift of
> Common lisp.

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

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

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

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

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

> > Python succeeds in part because of indentation. It also succeeds in part
> > because it looks a lot like C. Take both of those away, and one almost
> > might as well be using Lisp, Smalltalk, Perl, or Visual Basic. All one
> > would have left is a lot of nice libraries, a pure OO feel, portability,
> > and a permissive license.
> 
> Personally I'm interest in large complex Lisp systems (hey, some people
> call these applications) and it seems to me that Lisp *and*
> the syntax scales well. I'm not willing to give this up.

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

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

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

Build it and they will come! :-)

I woudn't think it would be that hard. 

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

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

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

Thanks again for your 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
From: Rainer Joswig
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <joswig-CEF233.17022610082000@news.is-europe.net>
In article <·················@kurtz-fernhout.com>, Paul Fernhout 
<··········@kurtz-fernhout.com> wrote:

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

Well, you can read about it in Dylan discussion archives
about switching the Dylan syntax.

> developers are often the ones most in need of things like version
> control or advanced editing or debugging features (or even just well
> tested stability!), and yet these are usually the last things to be
> added (if ever) to new experimental languages for novices.

The experimental multimedia development environment SK8 from
Apple had all this. It was written in Macintosh Common Lisp.
The source is still available.

> > Still I think there is good reason to experiment with a different
> > I/O system: surface syntax, reader, printer, editor support, ...
> > If it is good, people might use it.
> 
> Build it and they will come! :-)

"Demo or die".

-- 
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <1r6SOQwqQfejn+vyNe2gKZqkPZoz@4ax.com>
On Wed, 09 Aug 2000 14:03:28 -0400, Paul Fernhout
<··········@kurtz-fernhout.com> wrote:

> caught on yet in commercial usage to the degree it deserves compared to
> say C, considering the elegance and power of the system (notable
> exceptions like http://www.franz.com/success/ excepted). Instead, more

It should be noted that the availability of information on Lisp success
stories on Web sites or elsewhere is mainly related to the time people are
willing to spend to tell about them, not much with Lisp's actual
popularity. Take for example the commercial applications page at the ALU
site:

  http://www.alu.org/table/commercial-use.htm

It is out of date and the maintainer recently asked for help in order to
make it more current. I am not an industry insider, yet I was able to
contribute a few tens new entries, and I will submit some more.

So you are probably not going to find Lisp product ads in major newspapers
or glossy computer magazines. And you may not hear about hot quote-com
IPOs. But Lisp might be more widespread than many suspect.


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <A2ySOUXXOFTA8lNUuVKyRbcIylw2@4ax.com>
On Wed, 09 Aug 2000 18:22:36 +0200, Paolo Amoroso <·······@mclink.it>
wrote:

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

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

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


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <B5B7DDDA.4FEA%page@best.NOSPAM.com>
It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
To a great extent, it is. Most programming languages have a lot in common.

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

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

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

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

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

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

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

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

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

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

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

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like 	significant  indentation?
Date: 
Message-ID: <sfwu2ctx7re.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> Programmers should edit "programs" not "text files". How programs are
> displayed to programmers should be a flexible and dynamic affair.

I don't buy this.  If you'd just said

 Programmers should have the option to edit "programs" instead of "text files"
 if they so choose.  How programs are displayed to them should be possible to
 make flexible and dynamic if they find that useful.

I would not have any problem.

Writing programs is a form of expression, and I think it's fair to leave
the programmer whatever control he/she wants.

When I play Scrabble(R), I observe that some people have to always face the
board to play.  So they spin the board toward them to make this easy.  This
drives me nuts.  I don't care if I face the board--I only care that the view
does not change during the game.  If possible, I try to negotiate a fixed 
position of the board, even if it's always upside down for me, so that I can
not have the board view shift during play.  That's what suits me.  Others
deal differently.  The world needs to be about choices.  Strangely, "flexible
and dynamic" does not sound like choices to me.  "optionally flexible and
dynamic" sounds fine to me.

> There are
> already a lot of editors with auto-formatting, and dedicated
> "pretty-printers" for static code presentation -- and the kinds of things
> they do should certainly be a part of what I'm suggesting.

Emacs has this but you have to call on it when you want it.  I sometimes
use these facilities but never like the "electric" mode where it does them
without asking.

> However,
> programming tools should move beyond 

"the option of"

> mere indentation, bracket matching,
> coloring and highlighting.
> 
> A great book on the topic of 

"one person's view of"

> improved code presentation is:
> 
>     Human Factors and Typography for More Readable Programs
>     Ronald M. Baecker & Aaron Marcus
>     ACM Press
>     ISBN 0-201-10745-7
> 
> One simple idea from that book is that C braces are almost completely
> unnecessary if the indentation is correct. Eliminating them improves the
> readability of C, at least. And thus dies the age-old question: Where do you
> put the opening brace?

The answer to these questions is always statistically related to what's
"common" and what's "uncommon".  This whole business of indentation as a
substitute for bracketing, etc. is all a statistical argument.  I don't
doubt that there are cases where this is useful.  But I get irritated when
people say unconditional things likes "improves" rather than adding an extra
conditional notating the test conditions under which this is an improvement.
 
The age-old question never dies because the problem can't be gotten rid of.
These things run in cycles.   People get rid of braces because they tire of
them, and then they invent braces because they tire of not having them.  Each
time, they are sure they have solved the world's problems.  The fact is that
there's virtue in both, and the best thing is to acknowledge that no single
syntax suffices for all, and to work on ways to make syntax more of a personal
choice and less of something that is offered as dogma.

There are no more superior ways to arrange code than there are superior ways
to arrange your living room furniture.  Certainly there are "common issues
to consider" and there are "internally clashing styles" but even so there are
lots of variations that are ok, any one of which satisfies only some.

> These ideas for presentation should then be integrated into the editing
> process.

For people that want them.  Text is fine for me, for example.  The OPTION
to integrate them into editing is fine.  Personally, I prefer Emacs exactly
because it gives me 100% control when I want it and allows me to elect to
relax my control on my own choice.

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

There still has to be an unambiguous way to present and store the
code, and that will involve syntax.  It's a myth to say there is no
syntax-related coding.  You may succeed in making this opaque to users,
and that may please some, but it will frustrate others.

It's fine to say some people want to autogenerate code or not deal at
the presentation level, but not everyone does.

> Of course there are editors that do some of these kinds of things, but they
> are still manipulators of raw, plain text.

And sometimes intentionally so.

> They usually aren't capable of
> automating editing tasks that require deeper knowledge about the language or
> the particular program being edited (e.g. they don't know about definitions
> or macros).

They happen not to, but they can be taught.  Symbolics used to have a lot of
tools that did stuff taking into account of such stuff.  People can manipulate
definitions in the face of macros, and I'm confident that programs can be made
to deal like people.
 
> I think the future holds a programming experience where syntax is fluid --

I'm happy for you.  I hope I'm done programming by the time the invasive 
world you describe comes to pass, unless it leaves me the option to control
presentation in my own way.

> perhaps even changing moment by moment to present programs in a way best
> suited for what the programmer is doing at that time -- and programs are
> manipulated in terms of their semantic objects at a far quicker pace and
> with less errors than at present.

You still have to have a way to look at them, unless you're basically going
to say that the visual system offers no leg up in understanding.  As a 
regular reader of audiobooks, I find it hard to believe that the visual system
doesn't contribute a lot of useful stuff that is sadly lost if a system doesn't
use them.  If the system does use visual presentation and doesn't let the
user fix a preferred presentation, it increases the amount of time it will
take to look at the program each time it is presented because it won't be the
form in which the person last saw it and it will take a while to verify that
it hasn't been screwed over by whatever reformatting is done, plus time to
link back up whatever mental pointers you had recorded in spatial form to 
the new locations offered by the "helpful" system.

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

Not me.
 
I'm happy to work on systems that understand and manipulate presentation,
but I'm not happy to work on systems that purport to "take over" presentation
and leave the user out of it.

> P.S. When you have an editor that manipulates code rather than text, then it
> also becomes possible to instantly recompile code as it is changed,

And hopefully to know whether compilation contains anything like a 
load-time-value of a call to delete-file on something I care about.  Or 
perhaps something more subtle than that.  "Synchronization" happens 
implicitly in editing systems I use by virtue of my need to issue commands.
Your aggressive world better introduce a protoocl for synchronizing the
difference between "edited code" and "ready to be deployed code".

> because
> the compiler's workload is dramatically reduced.

This isn't the only reason that code isn't instantly compiled now.

> There are a number of
> wonderful implications, including some that have nothing to do with the
> compiler (e.g. revision control can operate at a higher level of
> abstraction).

Insert discussion of the complexities of "version synchronization" here.

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

Certainly determining which modules need recompilation is easier, and the
work is less.  It's only the "happening automatically" that is bugging me
throughout here.  A lot more goes through my mind before recompiling than
the mere words "why doesn't this happen automatically when I type close paren?"
From: Lieven Marchand
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <m3itt9f3gi.fsf@localhost.localdomain>
Chris Page <····@best.NOSPAM.com> writes:

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

You might look at the past and the present. There has been a project
to make an environment like that for C++ at AT&T. Stan Lippman worked
on it before he went to Pixar and has written a few articles on
it. The project got axed before completion, but I don't know
why. Also, IBM's VisualAge X tools (for X in Java, PL/1, Smalltalk)
work that way. They seem to get mixed reviews with some people
absolutely loving them and some hating them.

-- 
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
From: Tom Breton
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <m3bsz0q01u.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> 
> I think the future holds a programming experience where syntax is fluid --
> perhaps even changing moment by moment to present programs in a way best
> suited for what the programmer is doing at that time -- and programs are
> manipulated in terms of their semantic objects at a far quicker pace and
> with less errors than at present.
> 
> Think I'm blue-skying? Just wait. Or better yet, start working on making it
> a reality.

People have been saying that for decades, and programmers still
relentlessly keep dealing with text source.  Of course, they also
still use C and its children too...


-- 
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.
From: Christopher Browne
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <MQIk5.230498$t91.2188823@news4.giganews.com>
Centuries ago, Nostradamus foresaw a time when Tom Breton would say:
>Chris Page <····@best.NOSPAM.com> writes:
>
>> 
>> I think the future holds a programming experience where syntax is fluid --
>> perhaps even changing moment by moment to present programs in a way best
>> suited for what the programmer is doing at that time -- and programs are
>> manipulated in terms of their semantic objects at a far quicker pace and
>> with less errors than at present.
>> 
>> Think I'm blue-skying? Just wait. Or better yet, start working on making it
>> a reality.
>
>People have been saying that for decades, and programmers still
>relentlessly keep dealing with text source.  Of course, they also
>still use C and its children too...

"Snappy comebacks" would be to look at the programming environment
that commonly don't use files.

Notable examples would be:
a) Smalltalk
b) Some of the Lisp Machines

Vaporware examples people are playing with include:
c) The EROS operating system
d) Some of the attempts at "LispOSes" (see URL below)
-- 
(concatenate 'string "aa454" ·@" "freenet.carleton.ca")
<http://www.hex.net/~cbbrowne/lisposes.html>
"That's  convenience, not cracker-proofing.   Security is  an emergent
property, not a feature." -- void <·····@interport.net>
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through  Python-likesignificant  indentation?
Date: 
Message-ID: <39929BE7.F5655FF6@kurtz-fernhout.com>
Chris-

Wow! What a great post!

This is a much more sophisticated idea than what I propose. 
Thanks for sharing it.
 
-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Chris Page wrote:
> 
> It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
> To a great extent, it is. Most programming languages have a lot in common.
> 
> In any case, it is my primary belief that the whole issue of syntax is a red
> herring. Programming should be a high-level, automated process in which the
> syntax of the language is largely of no concern to the programmer.
> 
> Programmers should edit "programs" not "text files". How programs are
> displayed to programmers should be a flexible and dynamic affair. There are
> already a lot of editors with auto-formatting, and dedicated
> "pretty-printers" for static code presentation -- and the kinds of things
> they do should certainly be a part of what I'm suggesting. However,
> programming tools should move beyond mere indentation, bracket matching,
> coloring and highlighting.
> 
> A great book on the topic of improved code presentation is:
> 
>     Human Factors and Typography for More Readable Programs
>     Ronald M. Baecker & Aaron Marcus
>     ACM Press
>     ISBN 0-201-10745-7
> 
> One simple idea from that book is that C braces are almost completely
> unnecessary if the indentation is correct. Eliminating them improves the
> readability of C, at least. And thus dies the age-old question: Where do you
> put the opening brace?
> 
> These ideas for presentation should then be integrated into the editing
> process. Using the above example, not only are braces unnecessary in the
> presentation, they do not need to be typed by programmers. Instead, a
> programmer could place the insertion point somewhere in the code, and create
> a "for" statement. They would not type all the other text or punctuation;
> the parenthesis, the semicolons, the braces, the white space. The insertion
> point would be placed at the first appropriate spot for adding more code,
> and moving the insertion point would skip across the punctuation to the
> empty statements where code may be entered. Syntax-related coding errors no
> longer exist.
> 
> Of course there are editors that do some of these kinds of things, but they
> are still manipulators of raw, plain text. They usually aren't capable of
> automating editing tasks that require deeper knowledge about the language or
> the particular program being edited (e.g. they don't know about definitions
> or macros).
> 
> I think the future holds a programming experience where syntax is fluid --
> perhaps even changing moment by moment to present programs in a way best
> suited for what the programmer is doing at that time -- and programs are
> manipulated in terms of their semantic objects at a far quicker pace and
> with less errors than at present.
> 
> Think I'm blue-skying? Just wait. Or better yet, start working on making it
> a reality.
> 
> P.S. When you have an editor that manipulates code rather than text, then it
> also becomes possible to instantly recompile code as it is changed, because
> the compiler's workload is dramatically reduced. There are a number of
> wonderful implications, including some that have nothing to do with the
> compiler (e.g. revision control can operate at a higher level of
> abstraction).
> 
> P.P.S. Languages like Dylan, Lisp, and Smalltalk can be edited and compiled
> one definition at a time, so they're ahead of the game. The semantics of
> C/C++ compilation units make it more difficult (and occasionally impossible)
> to minimize the amount of code that must be recompiled when something as
> trivial as a comment is changed.
> 
> --
> Chris Page
> Mac OS Guy
> Palm, Inc.
> 
> let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Christopher Browne
Subject: Re: RFC: Lisp/Scheme with less parentheses through  Python-likesignificant  indentation?
Date: 
Message-ID: <yQIk5.230495$t91.2188823@news4.giganews.com>
Centuries ago, Nostradamus foresaw a time when Paul Fernhout would say:
>Chris-
>
>Wow! What a great post!
>
>This is a much more sophisticated idea than what I propose. 
>Thanks for sharing it.
> 
>-Paul Fernhout
>Kurtz-Fernhout Software 
>=========================================================
>Developers of custom software and educational simulations
>Creators of the Garden with Insight(TM) garden simulator
>http://www.kurtz-fernhout.com
>
>Chris Page wrote:
>> 
>> It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
>> To a great extent, it is. Most programming languages have a lot in common.
>> 
>> In any case, it is my primary belief that the whole issue of syntax is a red
>> herring. Programming should be a high-level, automated process in which the
>> syntax of the language is largely of no concern to the programmer.
>> 
>> Programmers should edit "programs" not "text files". How programs are
>> displayed to programmers should be a flexible and dynamic affair. There are
>> already a lot of editors with auto-formatting, and dedicated
>> "pretty-printers" for static code presentation -- and the kinds of things
>> they do should certainly be a part of what I'm suggesting. However,
>> programming tools should move beyond mere indentation, bracket matching,
>> coloring and highlighting.
>> 
>> A great book on the topic of improved code presentation is:
>> 
>>     Human Factors and Typography for More Readable Programs
>>     Ronald M. Baecker & Aaron Marcus
>>     ACM Press
>>     ISBN 0-201-10745-7
>> 
>> One simple idea from that book is that C braces are almost completely
>> unnecessary if the indentation is correct. Eliminating them improves the
>> readability of C, at least. And thus dies the age-old question: Where do you
>> put the opening brace?
>> 
>> These ideas for presentation should then be integrated into the editing
>> process. Using the above example, not only are braces unnecessary in the
>> presentation, they do not need to be typed by programmers. Instead, a
>> programmer could place the insertion point somewhere in the code, and create
>> a "for" statement. They would not type all the other text or punctuation;
>> the parenthesis, the semicolons, the braces, the white space. The insertion
>> point would be placed at the first appropriate spot for adding more code,
>> and moving the insertion point would skip across the punctuation to the
>> empty statements where code may be entered. Syntax-related coding errors no
>> longer exist.
>> 
>> Of course there are editors that do some of these kinds of things, but they
>> are still manipulators of raw, plain text. They usually aren't capable of
>> automating editing tasks that require deeper knowledge about the language or
>> the particular program being edited (e.g. they don't know about definitions
>> or macros).
>> 
>> I think the future holds a programming experience where syntax is fluid --
>> perhaps even changing moment by moment to present programs in a way best
>> suited for what the programmer is doing at that time -- and programs are
>> manipulated in terms of their semantic objects at a far quicker pace and
>> with less errors than at present.
>> 
>> Think I'm blue-skying? Just wait. Or better yet, start working on making it
>> a reality.
>> 
>> P.S. When you have an editor that manipulates code rather than text, then it
>> also becomes possible to instantly recompile code as it is changed, because
>> the compiler's workload is dramatically reduced. There are a number of
>> wonderful implications, including some that have nothing to do with the
>> compiler (e.g. revision control can operate at a higher level of
>> abstraction).
>> 
>> P.P.S. Languages like Dylan, Lisp, and Smalltalk can be edited and compiled
>> one definition at a time, so they're ahead of the game. The semantics of
>> C/C++ compilation units make it more difficult (and occasionally impossible)
>> to minimize the amount of code that must be recompiled when something as
>> trivial as a comment is changed.

The last book I browsed [and quickly discarded as pointless to buy, as
compared to the _very good_ O'Reilly book I just got on OCAML] was the
Addison Wesley book, 
  _Generative Programming: Methods, Tools, and Applications_
   <http://www.awl.com/product/0,2627,0201309777,00.html>

It's an interesting book, at some levels.  Frightening at others.
Remarkably _NON_concrete throughout.

Basic idea is that it looks at a number of "somewhat-beyond-OO"
techniques for metaprogramming, notably including:
  - Domain Engineering [which seems to be a whole lot of "design
    blathering"] 
  - Feature modeling [also "design blather"]
  - Generic programming
  - Component-based C++ templates [start saying "ick" now...]
  - Aspect Oriented Decomposition
    [This is the Xerox thing where they suggest building language
    tools to support generating "coupling" code so that, for instance,
    synchronization management might be managed by the "coupler"
    rather than you having to manage the bird-droppings of synch code
    throughout the code base...]
  - Code generators
  - Microsoft's Intentional Programming
   <http://www.research.microsoft.com/ip/>

[Aside: It seems to me that On Lisp addresses all but AOP in a
_CONCRETE_ manner, with clear code samples...]

The last item, Intentional Programming, is the either-very-smart-
or-really-scary bit, which certainly parallels what Chris Page is
talking about.

<http://www.research.microsoft.com/ip/NewsMove.htm>

  "IP, one of the first projects started at Microsoft Research, set
   out on an ambitious goal to change program representation from the
   traditional text stream and syntax to a database (the "IP tree"),
   which is not about the program, but which represents the program
   itself."

What MSFT seems to be trying to do [making up product names as needed]
is to build a "kinder, gentler" _Visual C++ 2001_.  Screen shots of
some sort of "intentional" C++ editor _are_ shown in the book.

There are likely to be patents forthcoming, and it might be wise for
those with existing Lisp-related "IP-like" functionality to watch to
see if there be infringements on this.

Now, with C++, the complexity of the language syntax means that
either:

a) They'll be creating a new language that's not _really_ C++ that the
   IP tool works with, or

b) The IP tool will integrate absolutely frightening amounts of
   "parser stuff," 

[or both!]

All this stuff considered [to some extent!], I'm skeptical that the
"code as trees" idea will go _terribly_ far towards eliminating "code
as text" any time soon.

Treating code as text allows deploying all sorts of "perhaps
less-intelligent, but easier to write and make generic" text-based
tools to manage code.

And if the code is _only_ available as a tree, then you're left saying
"What will Microsoft's Code Editor Allow Me To Do Today?"  [Substitute
other things for "Microsoft" as needed.]

Tree-oriented editors haven't taken off elsewhere; people tend to edit
HTML using text editors rather than using Amaya, which is
tree-oriented.

Text is just plain more flexible.

- Give me tools that make it easy to mess with text.

- Give me "syntax-oriented" tools like Emacs "electric" modes or HTML
  manipulators like Dave Raggett's HTML tidy, or sgmlnorm, or C
  indent, that can help clean up whatever gets "messed."

That seems to me to be more likely to cope well with code than having
to have a [perhaps rather fragile] "tree-oriented environment."

[Obvious retorts back include "How about Smalltalk, which has no
files?  How about Lisp Machines that had no files?"  Therein may lie
the interesting answers...]
-- 
(concatenate 'string "aa454" ·@" "freenet.carleton.ca")
<http://www.hex.net/~cbbrowne/lisp.html>
"90% of the ideas people bring to  me are no good.  So if I reject all
of them I've got a pretty good batting average" -- Sam Goldwyn (MGM)
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through  Python-likesignificant  indentation?
Date: 
Message-ID: <UvaTOT=2JnZAeJPbfdR5Nngeb2CI@4ax.com>
On Fri, 11 Aug 2000 01:40:46 GMT, ········@news.hex.net (Christopher
Browne) wrote:

>   - Microsoft's Intentional Programming
[...]
>    out on an ambitious goal to change program representation from the
>    traditional text stream and syntax to a database (the "IP tree"),

Is this what mere mortals unglamorously call "Source Code In Database"
(SCID)?


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Robert Monfera
Subject: Re: RFC: Lisp/Scheme with less parentheses through  Python-likesignificant  indentation?
Date: 
Message-ID: <398BA35A.CAC8BF6@fisec.com>
Chris Page wrote:

> I think the future holds a programming experience where [...] programs are
> manipulated in terms of their semantic objects at a far quicker pace and
> with less errors than at present.
> 
> Think I'm blue-skying? Just wait. Or better yet, start working on making it
> a reality.

You are predicting the past :-) I think it used to be a reality for
various programming environments.  For example, there was a recent
thread about structure editors and the Interlisp environment.  There
were some discussions about the merit of object-based versus text-based
editing.

> P.S. When you have an editor that manipulates code rather than text, then it
> also becomes possible to instantly recompile code as it is changed, 

It can be done both ways.  The question is: do you _always_ want to have
a function recompiled?  Maybe you make a dozen modification steps - do
you want a dozen recompliation?  Do you want instant recompilation when
you would rather want to recompile several functions in one
_transaction_ - for example to preserve metastability?

If anything, I'd like an editor that can manipulate definitions beyond
the boundaries of stone-age file concepts (e.g., seeing all methods of a
GF on the screen, or seeing all business logic code, or seeing all code
related to a class).  I hear Dylan's editor is like this.

An indicator for each declaration would also not hurt.  It could have
one of the following states: 
- currently active
- changed, not yet compiled (i.e., obsolete)
- removed from image (undefined)

Another area to improve is macros.  Currently the only safe thing to do
after macro redefinition is to recompile all files that possibly use the
macro.

What surprised me is that some popular Lisp environments don't even have
an "undefine" function for methods (something like fmakunbound, with an
extended function name containing argument specializations).  A GF
browser would also be helpful.

The bright side is that any of the enhancements above can be implemented
by users with moderate effort in Lisp itself.

Robert
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through  Python-likesignificant  indentation?
Date: 
Message-ID: <B5BAAA40.535A%page@best.NOSPAM.com>
in article ················@fisec.com, Robert Monfera at ·······@fisec.com
wrote on 2000.08.10 22:19:

>> I think the future holds a programming experience where [...] programs are
>> manipulated in terms of their semantic objects at a far quicker pace and
>> with less errors than at present.
>> 
>> Think I'm blue-skying? Just wait. Or better yet, start working on making it
>> a reality.
> 
> You are predicting the past :-) I think it used to be a reality for
> various programming environments.

I appreciate the smiley, but I feel compelled to say that I meant that this
is not yet a reality in mainstream commercial development, in the same way
that Dylan and Lisp are not a reality. That is, apart from my two years
helping develop Harlequin/Fun-O Dylan at Harlequin, I can't readily find a
job writing shrink-wrapped consumer software in either of these languages.

> For example, there was a recent thread about structure editors and the
> Interlisp environment.  There were some discussions about the merit of
> object-based versus text-based editing.

Thanks for the pointer. I'll look for that.

>> P.S. When you have an editor that manipulates code rather than text, then it
>> also becomes possible to instantly recompile code as it is changed,
> 
> It can be done both ways.  The question is: do you _always_ want to have
> a function recompiled?  Maybe you make a dozen modification steps - do
> you want a dozen recompliation?  Do you want instant recompilation when
> you would rather want to recompile several functions in one
> _transaction_ - for example to preserve metastability?

I fully expect any good system would include such "escapes" where at the
extreme one could edit raw text and have it parsed only after some editing
has been performed. Hopefully this would only be necessary when merging in
code from external text sources.

I recognize that this is an area fraught with issues, but I think it should
be possible to allow programmers to enter incomplete code in a structured
manner and simply have the compiler put on hold for that code until it is
complete.

Also, when I say that the code is compiled, I don't necessarily mean that it
is "committed" to the output binary. What I'm getting at is that the parser,
compiler, and linker would be able to appear to take no time, because they
can be done incrementally and/or threaded in the background. So that when
you are ready to run the code, there is no delay.

> If anything, I'd like an editor that can manipulate definitions beyond
> the boundaries of stone-age file concepts (e.g., seeing all methods of a
> GF on the screen, or seeing all business logic code, or seeing all code
> related to a class).  I hear Dylan's editor is like this.

Apple Dylan edits code like this, although technically it is just editing
smaller source files. That is, you edit smaller chunks of text, which
typically contain single definitions, but which can contain more if you
like. One can even round-trip import-edit-export traditional source files,
as it keeps all the definitions from a file grouped together. Too bad it's
no longer a commercial product (dangit).

> An indicator for each declaration would also not hurt.  It could have
> one of the following states:
> - currently active
> - changed, not yet compiled (i.e., obsolete)
> - removed from image (undefined)

You're nearly describing Apple Dylan. Each source record (which typically
holds a single definition) has flags for:

 - Unsaved: has unsaved changes.
 - Uncompiled: has uncompiled changes.
 - Warnings: the compiler generated warnings about it.

And source records can be "Excluded", which means they're ignored by the
compiler. (The equivalent of wrapping a Lisp defining form with #| |#.)

> Another area to improve is macros.  Currently the only safe thing to do
> after macro redefinition is to recompile all files that possibly use the
> macro.

Right. Once you have sub-file source records like Apple Dylan, you can at
least reduce the amount of recompiled source to each definition that
references the macro (directly or indirectly).

Even better, would be to only have to recompile the code within the
definition that is affected by the macro.

> A GF browser would also be helpful.

I'm pretty sure I recall seeing a GF browser in Harlequin Lisp (and Dylan).
I hope they're not that uncommon.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Paul Foley
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like 	significant  indentation?
Date: 
Message-ID: <m2ya25z0mn.fsf@mycroft.actrix.gen.nz>
On Thu, 10 Aug 2000 04:19:38 -0700, Chris Page wrote:

> It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
> To a great extent, it is. Most programming languages have a lot in common.

For most languages syntax isn't very important; it's just a "surface
feature" that you learn to live with.  But for Lisp, what syntax it
has is _vitally_ important.  Lisp _is_ essentially the "semantic
objects" representation you mention later.

> One simple idea from that book is that C braces are almost completely
> unnecessary if the indentation is correct. Eliminating them improves the

Which is why Python doesn't have braces.

But Lisp's parentheses are not at all the same thing as C's braces.
You could certainly replace parentheses with more syntax (at some
cost)...as has been done in the past, with Dylan for instance...but
not just indentation.

> presentation, they do not need to be typed by programmers. Instead, a
> programmer could place the insertion point somewhere in the code, and create
> a "for" statement. They would not type all the other text or punctuation;

Structure editors have been done to death.  Besides which, the "other
text or punctuation" usually consists of single characters, which take
no more (and often rather less) time to type than it takes to move the
cursor around.

> P.S. When you have an editor that manipulates code rather than text, then it

What is Lisp if not "code rather than text"?

-- 
When C++ is your hammer, everything looks like a thumb.
                                                   -- Steven M. Haflich
(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like 	 significant  indentation?
Date: 
Message-ID: <39932B69.181BF2AC@kurtz-fernhout.com>
Paul-

This comment you made greatly interests me, regarding the proposal I
outlined:

You wrote:
> But Lisp's parentheses are not at all the same thing as C's braces.
> You could certainly replace parentheses with more syntax (at some
> cost)...as has been done in the past, with Dylan for instance...but
> not just indentation.

The whole point of my proposal was that indentation (plue "..." to
indicate the start of a list of lists) was adequate to represent any
S-expression when one is just interested in removing redundant "edge"
parentheses. 

I understand people have many reasons why they may not want to use
indentation in Lisp, but I still haven't heard of any technical
objections to why it could not work which have included a specific
example.

There has been some misunderstanding by people thinking that I wanted to
introduce an algol-like syntax or such (not the case!) or that I wanted
to seperate code and data representations (also not the case!). Really,
I'm just trying to define an alternate way of displaying and creating
S-expressions without changing any fundamental properties of the
underlying Lisp language (and thus, to an extent somewhat along the
lines of Chris's post). 

If you could point out an example where indentation (and the occaional
"..." and a few parentheses) would not work to represent a Lisp
S-expression (thus showing the rules I outlined to be technically
incomplete or flawed) I would greatly appreciate it.

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

Paul Foley wrote:
> 
> On Thu, 10 Aug 2000 04:19:38 -0700, Chris Page wrote:
> 
> > It's been said (recently in comp.lang.*, in fact) that syntax is irrelevant.
> > To a great extent, it is. Most programming languages have a lot in common.
> 
> For most languages syntax isn't very important; it's just a "surface
> feature" that you learn to live with.  But for Lisp, what syntax it
> has is _vitally_ important.  Lisp _is_ essentially the "semantic
> objects" representation you mention later.
> 
> > One simple idea from that book is that C braces are almost completely
> > unnecessary if the indentation is correct. Eliminating them improves the
> 
> Which is why Python doesn't have braces.
> 
> But Lisp's parentheses are not at all the same thing as C's braces.
> You could certainly replace parentheses with more syntax (at some
> cost)...as has been done in the past, with Dylan for instance...but
> not just indentation.
> 
> > presentation, they do not need to be typed by programmers. Instead, a
> > programmer could place the insertion point somewhere in the code, and create
> > a "for" statement. They would not type all the other text or punctuation;
> 
> Structure editors have been done to death.  Besides which, the "other
> text or punctuation" usually consists of single characters, which take
> no more (and often rather less) time to type than it takes to move the
> cursor around.
> 
> > P.S. When you have an editor that manipulates code rather than text, then it
> 
> What is Lisp if not "code rather than text"?
> 
> --
> When C++ is your hammer, everything looks like a thumb.
>                                                    -- Steven M. Haflich
> (setq reply-to
>   (concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <3175491579516609@naggum.net>
[ Sorry about the delayed response -- this thread has swamped my news time. ]

* Paul Fernhout <··········@kurtz-fernhout.com>
| I understand people have many reasons why they may not want to use
| indentation in Lisp, but I still haven't heard of any technical
| objections to why it could not work which have included a specific
| example.

  Technical?  You want the paren-less (orphaned? :) form to satisfy
  humans and some vocal humans object that it doesn't satisfy them.
  When does this become technical?  There probably cannot be technical
  reasons why some representation won't work.  This is also paren-free
  and has no ambiguity at all:

#1      defun example #11 #12
#11       foo &optional #111
#111        bar 1
#12       + foo bar

  But would you want to write code like this?  How about being forced
  to unless you can give _technical_ reasons why this won't work?  (I
  submit that there _are_ no technical reasons to reject this, only
  good reasons for humans to reject it.)  If you don't care to write
  code like that, and don't want to struggle to give any technical
  reasons for it, please accept that the people you're proposing your
  paren-less Lisp to do not want to write code in your syntax and
  object strongly to your implicit claim that unless they can defend
  their position on technical grounds, they should.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <399C3FDC.4764C035@kurtz-fernhout.com>
Erik-

Thanks for the reply.

====== on the "straw-man" proposal your outline ======

I actually find the alternative approach you outline very interesting.
It is another alternative worth thinking about as a way to learn what
parentheses are good for. (Note: the indentation in the example is
superfluous to the line numbers and nothing requires the indentation to
be accurate.)

I guess one could implement something like it using macros. The
potential benefit of macros used in the way you outline could be to
improve the readability of some code sometimes. 

For example, in parenthetical notation:

  (some very complex definition of a "foo" macro taking an argument or
two)

  (define (myfunction x y z some-shared-context)
    (foo x 'middle)
    (foo y 'left)
    (foo z 'right))

Obviously one could do some of this with functions, but then the
variable "some-shared-context" would not be available unless it was
passed in. 

Also, from a clarity standpoint, is may make sense to use a macro
reference like this even if they are used only once. For example, one
might write:

  (some very complex definition of a "foo1" macro taking an argument or
two)
  (some very complex definition of a "foo2" macro taking an argument or
two)
  (some very complex definition of a "foo3" macro taking an argument or
two)

  (define (bar x y z)
    (foo1)
    (foo2)
    (foo3))

where this description makes it clear that this function does three main
things sequentially, where each thing can be understood to an extent as
a separate unit. This might be less clear if the function itself were
hundreds of lines. Obviously, one might instead write functions in many
cases, but there may be efficiency reasons or other reasons to use
macros. Either approach when appropriate promotes modularity.

I would think the notation of clearly named objects typically used when
making a macro is usually easier to understand than numerical IDs.
However, that does not invalidate the idea that sometimes when
describing an S-expression it makes sense for readability or
maintainability in part of the S-expression to refer via a
macro-like-way to other subexpressions defined before or after the
higher level part of the S-expression being defined.

====== on my own intent and progress ======

First, let me reiterate that my main intent in asking for comments was
to find out about prior work in this area and to see if the idea was
"technically" workable. By "technical objections" I mean some limits of
the rules that they cannot encode some S-expression. 

Obviously one can make other objections, such as have been raised here,
which depending on their practical importance might prevent the adoption
of the proposed typographical convention on a widespread basis. Some of
the strongest objections are the recently raised ones regarding
community fragmentation, difficulty reading postings or reusing code if
there are two syntaxes, issues with understanding expressions at the end
of a page or screen, and the need to learn both parenthetical
S-expression syntax as well as indentational S-expression syntax in
practice. The last is because indentational expressions for clarity and
conciseness would typically embed short parenthetical S-expressions
where all parens begin and end on one line.

However, since we are almost all talking from inexperience with
indentational syntax in Lisp (since until recently to my knowledge such
a thing did not exist in practice), I take all these objections with (as
is said) "a grain of salt", in the sense that even if valid, potential
objections in practice have to be balanced against advantages in
practice. 

Rhetorically speaking, how likely is it one person can come along and
overnight convince people who have used parentheses every day in their
work for years that some of what they are doing is unnecessary (assuming
it was, which remains to be seen)? Human nature alone argues for the
impossibility for this. It could almost be compared to suggesting in a
glue company that less sticky glue could be of value (thus the inventor
of the Post-It note glue faced a very difficult battle for acceptance).
So, that is not my main task here. 

My main task is instead to see whether the idea can be made to work
technically, given that I personally find aesthetic value in it, have
prior succesful experience with it in two other languages, and feel it
might boost my own productivity (if the benefits outweigh the costs,
which again remains to be seen in practice with Scheme or Lisp). 

Just yesterday, I got to the point where I has a GUI FileViewer utility
that can read a fully parenthesized Scheme code file and optionally
display it when desired in indentational syntax (losing some comments in
the process unfortunately). I also was able to execute an indentational
syntax Scheme program (the very one that creates that viewer
application) from within the DrScheme development environment using some
Scheme loader code at the top of the file (the loader opens the file and
processes the rest of it assuming indentational syntax). Obviously, it
is a long road to get the kind of seamless integration existing tools
like emacs provide for fully parenthesized S-expressions, and that is a
path I myself still wonder about the value (and costs) of pursuing.
Happily, DrScheme is well architected, as part of a larger Programming
Languages Team (PLT) effort, 
  http://www.cs.rice.edu/CS/PLT/
and so it looks like a good choice for language and development
environment experimentation. Obviously, if I was using Common Lisp at
the moment, emacs would be another great choice for experimenting.

====== on the many types of intelligence ======

I can understand how someone good with emacs and good with other related
abilities could for example find little need for a new typographical
notation for S-expressions. If one is comfortable with having
parenthetical expressions that often span lines, I can see how one might
not see the value in a typographical convention where most parenthetical
expressions begin an end on the same line.

It seems to me from your posts that you have made up your mind for the
moment on the lack of value of indentational notation to you, given your
own style of working and thinking, and your own experience. Many if not
almost all other posters to this thread to date seem to share that
sentiment. 

However, there are many types of intelligence, and different notations
might have different value to people stronger or weaker in various types
of intelligence and related perceptive abilities. Likewise people with
different prior experiences or work styles may also value differently
various typographical notations for S-expressions. Since ability,
experience, and knowledge change over time, even the same person might
prefer different approaches at different times in their life.

For more details on the concept of multiple types of intelligence, see
for example Howard Gardner's' books, like "Frames of Mind, The
Unschooled Mind, Creating Minds, and Multiple Intelligences". For some
more background, see for example:
  http://www.strategy-business.com/thoughtleaders/99109/
  http://www.strategy-business.com/thoughtleaders/99109/page1.html
  http://www.newhorizons.org/trm_duriemi.html

The next paragraph is taken from the first link above: 

Professor Gardner's investigation added five distinct intelligences to a
list that
began with verbal/linguistic and mathematical/logical. The additional
intelligences were visual/spatial, bodily/kinesthetic, musical,
interpersonal and intrapersonal. Recently, Professor Gardner's theories
on interpersonal and intrapersonal intelligences have been popularized
as "emotional intelligence," or E.Q. More recently, Professor Gardner
posited an eighth intelligence, which he terms "naturalist" -- the
ability of individuals to relate to nature -- and a ninth, the
existential intelligence. ... For his work, Professor Gardner has
received many awards, including a MacArthur Prize, often called a
"genius grant." 

This modern research goes against the "linear" concept of intelligence
often implied by how some people talk about for example pencil and paper
IQ test results. One should always bear in mind that the IQ test was
invented by Alfred Binet originally to determine specific disabilities
in one relatively homogenous ethnic group of children (French) so the
disadvantaged could be given special help. 
  http://www.nsoe.uconn.edu/siegle/espy360/intecrea.htm
The IQ test was not created or originally intended to be used as a
linear test summarizing all possible forms of intelligence -- even
though people often (incorrectly) try to interpret the score that way,
as if there was only one "intelligence" and it was easily measured
linearly. Obviously, "intelligence" and "testing" are complex topics and
I can't do them complete justice here. See the link for just one example
of an in-depth presentation of the issues.

One reason I bring up the concept of of "multiple inteligences" vs. "a
single intelligence" is that it bears directly on examining the deeper
issue of whether one coudl expect an "intelligent" person can cope with
lots of parentheses -- or find such a mode of presentation desirable.
Note in Gardner's research the separation of "mathematical/logical"
skills for example from "visual/spatial" skills. It may be that Lisp has
in the past drawn people mainly with high "mathematical/logical" skills.
Perhaps indentational notation might appeal more to people with high
"visual/spatial" skill, a skill which might be more or less independent
from other skills. Why should people be excluded from enjoyable
programming with S-expressions because they may have a different current
intelligence profile (or current intelligence portfolio) than that more
common for a current Lisp developer?

And as the research done by Howard Gardener, acknowledged "genius" and
Harvard professor, shows -- there *are* many types of intelligences.
Thus, (my generalization), it takes a community of people with different
skill profiles to make a great society. It has been said "The woods wood
be pretty quiet if no bird sang there but the best" and I might add they
would not be as interesting if all birds looked the same either.

====== summary ======

In any case, I do appreciate the general hospitality Lisp developers
currently hanging out in this newsgroup have show me during this thread,
as really I am just a guest here (I believe this was the first thread I
ever started in comp.lang.lisp). The dialog (even if highly critical of
the idea) has been a good learning experience for me -- much more so
than if the approach had been received with silence and yawns. As many
comments from various people posting to this newsgroup have shown by
example, one highly successful way to attract and encourage a newcomer
to pursue and stick with an idea like fully parenthesized Common Lisp
and the community around it, even in the face of perhaps ignorant
sounding questions or suggestions by that newcomer, is polite
explanations of why things make sense the way they are (even if such
takes great patience and repeated effort). I appreciate the efforts by
many in this newsgroup to patiently and politely answer my
questions/comments and clarify technical and other issues related to
this proposal.

-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

Erik Naggum wrote:
> 
> [ Sorry about the delayed response -- this thread has swamped my news time. ]
> 
> * Paul Fernhout <··········@kurtz-fernhout.com>
> | I understand people have many reasons why they may not want to use
> | indentation in Lisp, but I still haven't heard of any technical
> | objections to why it could not work which have included a specific
> | example.
> 
>   Technical?  You want the paren-less (orphaned? :) form to satisfy
>   humans and some vocal humans object that it doesn't satisfy them.
>   When does this become technical?  There probably cannot be technical
>   reasons why some representation won't work.  This is also paren-free
>   and has no ambiguity at all:
> 
> #1      defun example #11 #12
> #11       foo &optional #111
> #111        bar 1
> #12       + foo bar
> 
>   But would you want to write code like this?  How about being forced
>   to unless you can give _technical_ reasons why this won't work?  (I
>   submit that there _are_ no technical reasons to reject this, only
>   good reasons for humans to reject it.)  If you don't care to write
>   code like that, and don't want to struggle to give any technical
>   reasons for it, please accept that the people you're proposing your
>   paren-less Lisp to do not want to write code in your syntax and
>   object strongly to your implicit claim that unless they can defend
>   their position on technical grounds, they should.
> 
> #:Erik
> --
>   If this is not what you expected, please alter your expectations.
From: Christopher Browne
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <HCHk5.22095$wX5.313217@news5.giganews.com>
Centuries ago, Nostradamus foresaw a time when Paolo Amoroso would say:
>On Wed, 09 Aug 2000 00:37:23 -0400, Paul Fernhout
><··········@kurtz-fernhout.com> wrote:
>
>> I'm interested in using significant indentation (like in Python)
>>   http://www.python.org 
>> to replace many parentheses in Lisp or Scheme programs.
>>  
>> Has this been tried before? If so, what was the outcome?
>
>What was the outcome? Well, note that section 3.5.1 is a subsection of 3.5,
>which is titled "Some Notable Failures".

:-).

>> This example was taken from the LispMe (Lisp for the Palm) sample
>> code.   http://www.lispme.de/lispme/
>[...]
>> One advantage to such an approach it that it might make it easier to
>> compose Lisp on devices without keyboards. An indent-line button and an
>> unindent-line button would be useful in that case.
>
>If you are a LispMe user, I suggest that you check the pedit family of
>shareware text editors:
>
>  http://www.math.ohio-state.edu/~nevai/palm/

An unexpectedly remarkably useful link; thanks!

>> Significant indentation might make it easier for developers who don't
>> know Lisp well to understand a Lisp program's structure. 
>
>Lisp developers already rely on indentation to understand a Lisp program's
>structure. Although indentation is not enforced by Lisp systems, it is
>sufficiently well standardized.

Parentheses _imply_ the appropriate indentation, and while enforcement
is nonexistant particularly when code might be generated by macros,
with the result that there's no text, and thus no notion of
indentation.

>> It might also allow experiences Lisp developers to read programs faster
>> because there is less high frequency "noise" in the text. Every
>
>As someone else pointed out in this thread, parentheses "disappear".
>Parentheses are simply not an issue for experienced programmers, and at
>times even for novices.

A pretty valid parallel is that in Python, the "strangeness" of using
indentation to indicate block structure _also_ disappears with use.

>> Such code will be faster to create. There is less typing, and no worry
>> about unbalanced parentheses. Indentation might be incorrect, but then
>
>LispMe provides some support for saving typing. If you type a form in the
>input field (more or less the equivalent of a listener's prompt), you can
>omit all the final parentheses.

You can?  Cool!
>> Making indentation significant works for Python.
>> Why not make it work for Lisp too?
>
>Hint: parentheses-based syntax works for Lisp; why not make it work
>for Python too?

I think this would be a _tremendously_ interesting option.

Norvig <http://www.norvig.com/python-lisp.html> describes Python thus:

  ``Basically, Python can be seen as a dialect of Lisp with
    "traditional" syntax (what Lisp people call "infix" syntax). One
    message on comp.lang.python said "I never understood why LISP was
    a good idea until I started playing with python." Python supports
    all of Lisp's essential features except macros, and you don't miss
    macros all that much because it does have eval, and operator
    overloading, so you can create custom languages that way.
    (Although it wasn't my intent, Python programers have told me this
    page has helped them learn Lisp.)''

Sticking Python code into "lists," as an alternative notation, would
introduce the possibility of doing macros _well_, as well as providing
a completely unambiguous way of transferring code betwixt places.
-- 
(concatenate 'string "cbbrowne" ·@" "acm.org")
<http://www.ntlug.org/~cbbrowne/linux.html>
"Cars  move  huge  weights  at  high  speeds  by  controlling  violent
explosions many times a  second. ...car analogies are always fatal..."
-- <········@my-dejanews.com>
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <I=CTOXTMUxcOk0pyC2Wj6zcoqbVW@4ax.com>
On Fri, 11 Aug 2000 00:17:43 GMT, ········@news.hex.net (Christopher
Browne) wrote:

> Centuries ago, Nostradamus foresaw a time when Paolo Amoroso would say:
[...]
> >If you are a LispMe user, I suggest that you check the pedit family of
> >shareware text editors:
[...]
> An unexpectedly remarkably useful link; thanks!

pedit is so cool because the author is an Emacs junkie :-)


> A pretty valid parallel is that in Python, the "strangeness" of using
> indentation to indicate block structure _also_ disappears with use.

So, if unusual features of languages (e.g. parentheses for Lisp or
indentation for Python) disappear with use, why bother so much with
simplified syntaxes?


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Peter Norvig
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3991A692.4AABB074@norvig.com>
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?
> 
> ======= 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
>
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3991C3F1.BF13F63@kurtz-fernhout.com>
Peter -

Thanks for the reply. 

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

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

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

By the way, does:

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

seem any clearer? 

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

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

  set-object-array-field! s i val 

or more conventionally:

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

Thanks again for the comments.

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

Peter Norvig wrote:
> 
> I have no objection to the less-parentheses style.  I'd say I wouldn't
> use it when editing in emacs, unless s-expression commands support
> indentation as thoroughly as they do parens.  But when I write code on
> paper, I often use a style like this to save time.  I think using this
> is like using an infix-syntax parser for mathematical expressions: if
> used in moderation it can be helpful, especially in communicating with a
> community that aren't used to the parens.
> 
> Actually, there are other aspects of Lisp syntax that I find more
> annoying than the parens.  Compare
> 
>         s.X[i] = val
> to
>         (setf (aref (csp-state-x s) i) val)
> 
> The later is what I ended up coding in a constraint satisfaction solver
> I was recently working on.  The annoyance is that the former (legal
> Python, Java or C++) is close enough to what is used in the theoretical
> literature that I can understand it in one glance, while the Lisp code
> takes two glances to understand.  Why does Python/Java/C++ have an
> advantage?  Because they typographically distinguish useful operations:
> assignment in Python/Java (and confusingly, copying in C++); indexing;
> and class slots.  And also because classes are namespaces in Python/C++,
> but not in Lisp (so I can use X instead of csp-state-x).  Lisp
> multimethods are the preferred solution for complex applications, but
> Python/Java/C++ classes do make the easy cases easier.
> 
> -Peter Norvig
> 
> Paul Fernhout wrote:
> >
> > I'm interested in using significant indentation (like in Python)
> >   http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> >
> > Has this been tried before? If so, what was the outcome?
> >
> > ======= 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
> >
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <m3ya25vcbe.fsf@cadet.dsl.speakeasy.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

clearer than

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

???

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

dave
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant indentation?
Date: 
Message-ID: <3992A328.56947330@kurtz-fernhout.com>
David-

Thanks for the comments.

I've realized from this example what it is visually about parentheses
that can be confusing, especially to one less experienced with Lisp
syntax.

Naively, to an eye used to looking for objects in space, where
physically proximity in three dimensions helps denote an "object", the
following:

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

could be broken down by the eye/mind into rounded graphical objects as
follows:

1:

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

2:

    (aref 
      val)

if one proceeds on the principle that parentheses which are "spatially"
closest (in 2D) match first. Just imagine these as free floating
molecules of S-expressions that get docked somehow to see the
possibility.  

While the beginning Lisp user may have been told it doesn't work that
way, the eye (perhaps only at first) may be still trying to make sense
of what is on the page using conventional rules of spatial association.

When everything is written on one line like so:

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

this is not an issue. But as soon as things are indented, this becomes a
potential problem. 

Granted, an experienced Lisp developer may see past this issue, and
learn to enforce a strict left-to-right and wrapping interpretation of
conceptual units. Their eye may get trained to see that in a Lisp
context. At that point, what I point out may never occur to them as a
possible reading. If it did despite training, one might think of it as
"Lisp Dyslexia" since it would certainly make it harder to work with
Lisp code. 

However, to someone without that Lisp developing experience, the
expectation of the eye for spatial closeness in 2D or 3D can be violated
in many, many Lisp expressions using parentheses as they are presented
on the 2D page. 
The approach outlined using significant indentation has less of this
perceptual problem (although granted it may bring up others).

To be fair, by this logic, the indentationally significant example:

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

could be read as:

1:

  setf
    aref
    val

2:

        (csp-state-x s) i

but that feels a less natural reading to me, and there are no
parentheses in this case to reinforce this particular visual parsing.
However, granted I may be biased from being used to a similar convention
in other languages, so others might parse it that way visually. 

I would then point out that this specific visual parsing still makes
sense in a way, because in practice (1:) is the structure of the "high
level" view of the code, and (2:) is a detail to one line of (1:). This
will almost always be the case, because the indentation rules I outline
would most usually result in a "backbone" of code running down the left
edge of the expression. Thus, even this unexpected parsing aids in
understanding the code, whereas in the parenthesized case the unexpected
parsing is at odds with the true structure of the code.

I must say, I'm enjoying all these comments because they are making me
think much more deeply about this issue.

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

David Bakhash wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > By the way, does:
> >
> >   setf
> >     aref (csp-state-x s) i
> >     val
> >
> > seem any clearer?
> 
> clearer than
> 
>     (setf
>       (aref (csp-state-x s) i)
>       val)
> 
> ???
> 
> no.  not particularly.  My brain knows that right after I typed "val",
> that the "val" was the new value in a setf, and that I should close
> it.  So I press that closing paren, then press enter, with almost no
> concern about indentation, unless the cursor ends up somewhere that
> looks funny.  In addition to just knowing how many parens to press,
> paren-matching/highlighting helps too.
> 
> dave
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <B5B7DE84.4FF2%page@best.NOSPAM.com>
in article ··············@cadet.dsl.speakeasy.net, David Bakhash at
·····@alum.mit.edu wrote on 2000.08.09 23:51:

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

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

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	significant indentation?
Date: 
Message-ID: <c29d7j7tgxw.fsf@w20-575-44.mit.edu>
Chris Page <····@best.NOSPAM.com> writes:

> in article ··············@cadet.dsl.speakeasy.net, David Bakhash at
> ·····@alum.mit.edu wrote on 2000.08.09 23:51:
> 
> > clearer than
> > 
> > (setf
> > (aref (csp-state-x s) i)
> > val)

Note that your news reader didn't preserve the indentation that I'd
originally written that stuff with.  So it looks like I wrote something
that's barely readable.  The original post said:

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

dave
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	significant indentation?
Date: 
Message-ID: <sfwsns3kzk0.fsf@world.std.com>
David Bakhash <·····@alum.mit.edu> writes:

> Chris Page <····@best.NOSPAM.com> writes:
> 
> > in article ··············@cadet.dsl.speakeasy.net, David Bakhash at
> > ·····@alum.mit.edu wrote on 2000.08.09 23:51:
> > 
> > > clearer than
> > > 
> > > (setf
> > > (aref (csp-state-x s) i)
> > > val)
> 
> Note that your news reader didn't preserve the indentation that I'd
> originally written that stuff with.  So it looks like I wrote something
> that's barely readable.  The original post said:
> 
>     (setf
>       (aref (csp-state-x s) i)
>       val)
> 
> dave

This must be hell on python code... In the back of my head I knew there were
situations where right and left whitespace were "vulnerable" but I was having
trouble coming up with a suitably savage example.  Surely netnews is it.

(I assume this message inclusion/reindentation thing must be tricky on
python discussion by e-mail and newsgroups.)
From: Ian Wild
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	 significant indentation?
Date: 
Message-ID: <399CF975.7848252@cfmu.eurocontrol.be>
Kent M Pitman wrote:
>
> This must be hell on python code... In the back of my head I knew there were
> situations where right and left whitespace were "vulnerable" but I was having
> trouble coming up with a suitably savage example.  Surely netnews is it.


You think that's bad?  I've seen serious suggestions that
Python be used as an end-user scripting language.  Imagine
the poor loser who gets to play telephone support:

  "Well, does it look like it's further in than the
   one half way up the screen?  About the same, eh?
   And the next line?  Is that to the left or right
   of this one?"
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	  significant indentation?
Date: 
Message-ID: <sfwitsysxab.fsf@world.std.com>
Ian Wild <···@cfmu.eurocontrol.be> writes:

> Kent M Pitman wrote:
> >
> > This must be hell on python code... In the back of my head I knew
> > there were situations where right and left whitespace were
> > "vulnerable" but I was having trouble coming up with a suitably
> > savage example.  Surely netnews is it.
> 
> You think that's bad?  I've seen serious suggestions that
> Python be used as an end-user scripting language.  Imagine
> the poor loser who gets to play telephone support:
> 
>   "Well, does it look like it's further in than the
>    one half way up the screen?  About the same, eh?
>    And the next line?  Is that to the left or right
>    of this one?"

Ian, this is the twenty-first century and we solve such problems by
the straightforward application of well-established UI technology: We
just arrange for the editor/debugger to paint lines at different
indentation a different color levels, for example so that lines that
are leftward are redder than lines to the right.  That eliminates the
need for vague references to lines ambiguously far above; instead, 
direct an unambiguous reference can be made, leaving the end-user with
relatively simple and fully tractable tasks:

 "Well, does it look like it's got more or less red in it than the line 
  that's RGB color #ffa07a a little ways above7  Less? How much less red?
  No, that's ok--go ahead and answer in either hex or decimal, whicever
  is easiest.  I can convert."

Or, in rev2 of the support software, correcting some of the less user
friendly aspects:

 "Well, does it look like it's more or less red in it than the line
  that's light salmon a little ways above?  Less?  Great.  Now I just
  need one more bit of information:  Is it salmon or light coral?"
From: Tim Bradshaw
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	  significant indentation?
Date: 
Message-ID: <ey38ztuo73n.fsf@cley.com>
* Kent M Pitman wrote:
> Or, in rev2 of the support software, correcting some of the less user
> friendly aspects:

>  "Well, does it look like it's more or less red in it than the line
>   that's light salmon a little ways above?  Less?  Great.  Now I just
>   need one more bit of information:  Is it salmon or light coral?"

In the third release, the editor will be specially modified to insert
little marks to indicate indentation levels -- a kind of
leftward-facing curve to indicate an increase in level and a
rightward-facing curve to indicate decrease.  This reduces the problem
to one of counting these objects.

--tim
From: Arun Welch
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	  significant indentation?
Date: 
Message-ID: <10fn5.139$vb3.6534@newsread1.prod.itd.earthlink.net>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
>  "Well, does it look like it's more or less red in it than the line
>   that's light salmon a little ways above?  Less?  Great.  Now I just
>   need one more bit of information:  Is it salmon or light coral?"
>

Geez, you guys are spending way too many cycles on this.  Column numbers are
quite clearly delineated on the punch cards :-).

...arun
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	significant indentation?
Date: 
Message-ID: <m31yzmalor.fsf@cadet.dsl.speakeasy.net>
Kent M Pitman <······@world.std.com> writes:

> This must be hell on python code... In the back of my head I knew there were
> situations where right and left whitespace were "vulnerable" but I was having
> trouble coming up with a suitably savage example.  Surely netnews is it.

yeah.  Oddly enough, I didn't make that connection when I followed up
to that post.  It was old, and I like to clear the record.  If someone 
say my post via that followup and thought I was suggesting that the
poorly indented Lisp version was my intention and preference, then I'd 
be disappointed.

But gosh.  This is just another example of the (my boss hates when I
say this word) retarded dependence on indentation.  At least with that 
Lisp code you can Emacs's `cut-rectangle' function to get rid of the
`> ' on every line.  Thanks for picking this up!

dave
From: Per Bothner
Subject: repls and less parentheses
Date: 
Message-ID: <m2wvhez8ik.fsf_-_@bothner.com>
One things I haven't noticed in this discussion (but I may have overlooked
it because of skimming/skipping):

How would a reduced-parentheses syntax work with a command line?  To me,
a reduced-parentheses syntax for Lisp is pointless unless it allows me
to type parentheses-free expressions at the command line.  The tricky
part is that I *don't* want to have to type a semi-colon or other explicit
statement delimitor.

I.e. I want to be able to type (assuming we stick to prefix operators):

prompt> + 2 3 4

and have the repl come back with "9" as soon as I hit Enter.

That implies that end-of-line is by default a statement delimitor,
unless there is some kind of continuation indication.  Such an
indication can be a special character: #\\ is standard in the C/Unix worlds:

prompt> + 2 3 \
prompt>   4
9

Note that I cannot depend on the indentation of lines the user hasn't
typed yet ...  However, I can use the fact that I have an incomplete
statement to cause further reading.  E.g.:

prompt> defvar ten
prompt>   10
ten
prompt> ten
10

More intesting is if:

prompt> if (> a b)
prompt>   setq b a

What now?  Can the system handle a syntax like this, without knowing
the indentation of the following statements?  Yes, actually it can.
Even if the if-statement is incomplete, it can still evaluate what it
has: First evaluate the condition (> a b).  If it is true, evaluate
the next statement (setq b a).  If the condition is true, ignore the
next statement.  If we next see:

prompt>   setq i (+ i 1)

we know this is a continuation of the "thne-clause", since it is
identented the same.  Evaluate it if the condition (> a b) was true,
otherwise ignore it.  If we then see:

prompt> else setq i (- i 1)

the program evaluates the setq iff the original condition (> a b)
was false.

The question of interactivity is not directly related to the question
of using identation.  However, while the idea of using indentation to
show structure is an appealing idea, it is of no interest to me unless
you also have a good answer for read-eval-print loops.
-- 
	--Per Bothner
···@bothner.com   http://www.bothner.com/~per/
From: Paul Fernhout
Subject: Re: repls and less parentheses
Date: 
Message-ID: <399EAE85.7AE296D6@kurtz-fernhout.com>
Per-

Python handles this by requiring an extra blank line to be typed to mark
the end of a group of statements. However, in the python case, Python
also requires a ":" at the end of certain statements that indicates
additional indented lines are expected -- so the case is not exactly
analagous, because Python knows some statements can be evaluated
immediately, and it does so if it can.

These are the four options I know of (besides your later suggestion):
1. Entering an extra blank line
2. Entering a continuation character on all but the last line (as you
mentioned)
3. Entering a completion character or statement (like "!") on a line by
itself.
4. Selecting and eavluating code typed in a workspace, where the end of
the selection marks the end of the phrase. Smalltalk uses this and it
works quite well.  Evaluated results appear after the selection,
depednign on the exact type of evaluation selected ("do it" vs. "print
it" vs. "inspect it".) In the last case, Smalltalk puts the result into
an einspector. However, in the Smalltalk case, a "transcript" to print
results is usually a seperate window from the "workspace" window you are
composing code fragments in.

Of course, the other alternative you propose would be a #5 -- to do
evaluations creating partial expressions and then create large
expressions somehow as indented lines are added. Some "helpful"
evaluators might flag these as improperly completed forms though.  

Obviously, none of these (except maybe your #5) work exactly like the
REPL loop does now. However, in practive I've found the Smalltalk
approach to work quite well, since in practice one composes a document
full of useful expressions and then just picks the one desired for
testing -- with new expressions composed at the end of  this list.

Thanks for the comments and sharing that neat idea.

(Incidentally, I'm now developing almost exclusively with
indentationally significant syntax under DrScheme and enjoying it. There
are still many rough edges though -- like with reporting error messages
tied to file positions. I have not tried modifying the REPL loop
though.)

-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

Per Bothner wrote:
> 
> One things I haven't noticed in this discussion (but I may have overlooked
> it because of skimming/skipping):
> 
> How would a reduced-parentheses syntax work with a command line?  To me,
> a reduced-parentheses syntax for Lisp is pointless unless it allows me
> to type parentheses-free expressions at the command line.  The tricky
> part is that I *don't* want to have to type a semi-colon or other explicit
> statement delimitor.
> 
> I.e. I want to be able to type (assuming we stick to prefix operators):
> 
> prompt> + 2 3 4
> 
> and have the repl come back with "9" as soon as I hit Enter.
> 
> That implies that end-of-line is by default a statement delimitor,
> unless there is some kind of continuation indication.  Such an
> indication can be a special character: #\\ is standard in the C/Unix worlds:
> 
> prompt> + 2 3 \
> prompt>   4
> 9
> 
> Note that I cannot depend on the indentation of lines the user hasn't
> typed yet ...  However, I can use the fact that I have an incomplete
> statement to cause further reading.  E.g.:
> 
> prompt> defvar ten
> prompt>   10
> ten
> prompt> ten
> 10
> 
> More intesting is if:
> 
> prompt> if (> a b)
> prompt>   setq b a
> 
> What now?  Can the system handle a syntax like this, without knowing
> the indentation of the following statements?  Yes, actually it can.
> Even if the if-statement is incomplete, it can still evaluate what it
> has: First evaluate the condition (> a b).  If it is true, evaluate
> the next statement (setq b a).  If the condition is true, ignore the
> next statement.  If we next see:
> 
> prompt>   setq i (+ i 1)
> 
> we know this is a continuation of the "thne-clause", since it is
> identented the same.  Evaluate it if the condition (> a b) was true,
> otherwise ignore it.  If we then see:
> 
> prompt> else setq i (- i 1)
> 
> the program evaluates the setq iff the original condition (> a b)
> was false.
> 
> The question of interactivity is not directly related to the question
> of using identation.  However, while the idea of using indentation to
> show structure is an appealing idea, it is of no interest to me unless
> you also have a good answer for read-eval-print loops.
> --
>         --Per Bothner
> ···@bothner.com   http://www.bothner.com/~per/
From: Johann Hibschman
Subject: Re: repls and less parentheses
Date: 
Message-ID: <mtvgwxvxcp.fsf@astron.berkeley.edu>
Paul Fernhout writes:

> Python handles this by requiring an extra blank line to be typed to mark
> the end of a group of statements. However, in the python case, Python
> also requires a ":" at the end of certain statements that indicates
> additional indented lines are expected -- so the case is not exactly
> analagous, because Python knows some statements can be evaluated
> immediately, and it does so if it can.

Actually, that's not quite true.  The colons in python are entirely
superfluous; Guido introduced them based on usability studies (with
ABC) which claimed that most users preferred the extra syntax.

The python interpreter simply knows which statements expect a block
afterwards (for/if/while/try/catch/class/etc.); the colon is just
sugar.  Expressions are terminated by newlines, except when continuted
by #\\, in which case the indentation of the continuation is
irrelevant.

-- 
Johann Hibschman                           ······@physics.berkeley.edu
From: Will Mengarini
Subject: Re: repls and less parentheses
Date: 
Message-ID: <8nrbkp$l4o$1@eskinews.eskimo.com>
Remember how *different* a REPL is from the problem Paul Fernhout
originally addressed, which was how to make static text's indentation
equivalent to parenthesization.  In the case of a REPL, the user is
*typing*, and this changes everything, because it's possible to use
multiple different keys to mean "end of line", each implying something
different about what would follow on the next line.

One possible scheme:
  <Enter>      = end of top-level form (evaluate and print now)
  <Tab>        = end of line, to be followed by an indented line
  <Shift-Tab>  = end of line, to be followed by an exdented line
  <Ctrl-Enter> = end of line, to be followed by an undented line
Of course, any implementation used by people like us would be
completely remappable, so this is just a starting point.  I find
<Shift-Tab> awkward to type, and would probably additionally
bind all these commands to <Ctrl-[some key on home row]>; all
that matters about the initial binding is that it be easy
for a complete novice to remember, and tolerable for use by
an expert giving assistance on somebody else's computer.

When Per Bothner says he doesn't want to type a semicolon as
a statement delimiter, I think what he really means is best
interpreted at a higher level of abstraction: he doesn't want to
have to do extra typing, whatever its meaning.  He would similarly
object to a continuation character, and for the same reason.
This is the scsh interactive problem (using scsh interactively
requires parenthesizing every command, which is basically a
showstopper), and Paul's syntax is the first good solution I've
seen suggested for it.  But to have a special character *replace*
<Enter> instead of *supplementing* <Enter> eliminates Per's objection.
We could, for that matter, even use <;> as one of the "this is the end
of the line" characters, since it's a convenient QWERTY home-row
key rarely used in a REPL (in which <Meta-;> would suffice
in the rare cases when you do want to comment your interaction).

I'd go farther and say that I not only don't want to have to do
extra typing, I also don't want to have to do extra *thinking*,
which makes approaches based on incomplete statements unacceptable.
That, in fact, is a particular case of the general problem with
software development in these early centuries: instead of telling the
computer what to do using a vocabulary commensurate in expressive
power and abstractional richness with the vocabulary we use to
think about the problem or discuss it with each other, we spend
most of our time diddledydoodling around with things like variables
and datatypes and non-consing-ness, so that an instruction to a
computer to do something interesting takes many orders of magnitude
more lexemes than a description to another human of what is being
done.  Thinking about these trivia takes almost all of our time.
When I'm typing in some Unix command, I want to be thinking about
what the command will do, not about how I'll denote the end of it.
Learning a few keystrokes for such denotations is as easy as
learning things like Emacs key bindings for #'insert-parentheses and
#'forward-sexp; you learn them once and then just use them without
thinking about them.  Needing to think for each typed expression
about whether it's possibly complete (and therefore requires special
notation to communicate that evaluation is not yet desired) is extra
effort that never stops being necessary, and so is unacceptable.

                 Will Mengarini  <······@eskimo.com>
         Free software: the Source will be with you, always.

"It is a profoundly erroneous truism, repeated by all copy-books and
 by eminent people when they are making speeches, that we should
 cultivate the habit of thinking about what we are doing.  The precise
 opposite is the case.  Civilization advances by extending the numbers
 of important operations which we can perform without thinking about
 them.  Operations of thought are like cavalry charges in battle --
 they are strictly limited in number, they require fresh horses, and
 must only be made at decisive moments."
    --Alfred North Whitehead

"Keep away from people who belittle your ambitions.  Small people
 always do that, but the really great make you feel that you, too,
 can become great."
    --Mark Twain.

"Time makes more converts than reason."
    --Thomas Paine
From: Espen Vestre
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <w64s4up24i.fsf@wallace.nextel.no>
Peter Norvig <·····@norvig.com> writes:

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

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

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

-- 
  (espen)
From: Robert Monfera
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <398A3F94.20A41E60@fisec.com>
Espen Vestre wrote:
> 
> Peter Norvig <·····@norvig.com> writes:
> 
> > and class slots.  And also because classes are namespaces in Python/C++,
> > but not in Lisp (so I can use X instead of csp-state-x).
> 
> ...but quite often the defstruct-like idea of using the class name in
> the accessor function is not a very good one

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

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

Robert
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <m3punil7df.fsf@cadet.dsl.speakeasy.net>
Peter Norvig <·····@norvig.com> writes:

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

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

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

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

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

dave
From: Bruce Hoult
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <bruce-FC1D87.10333510082000@news.akl.ihug.co.nz>
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash 
<·····@alum.mit.edu> wrote:

> Peter Norvig <·····@norvig.com> writes:
> 
> > Why does Python/Java/C++ have an
> > advantage?  Because they typographically distinguish useful operations:
> > assignment in Python/Java (and confusingly, copying in C++); indexing;
> > and class slots.  And also because classes are namespaces in Python/C++,
> > but not in Lisp (so I can use X instead of csp-state-x).  Lisp
> > multimethods are the preferred solution for complex applications, but
> > Python/Java/C++ classes do make the easy cases easier.
> 
> This is really interesting.  Back in '96 is when I first started using
> Windows (it was Windows 95, of course).  I was coming from a Unix
> background, and really despised MS Windows, but really couldn't
> elaborate on why.  It was something much deeper than anything overtly
> apparent to me.  Then I heard the guy in the cubicle next to mine
> bitching about his windows box.  He was also a non-hacker EE type, and
> what he said was:
> 
>    "I hate this goddamn OS.  They try to make everything so &%*#ing
>    easy, but as soon as I try to do something that they didn't
>    anticipate, it's a nightmare.  I want my Unix box back."
> 
> His point was exactly that the simple things in Unix seem hard, but
> once you've got them down, the hard things are very similar and follow 
> logically from the simple things.  There's no dichotomy there, whereas 
> for windows he felt that there was, and I finally realized that that's 
> what was plaguing me too.

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

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


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

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

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

   X.foo := X.foo + 1;

... actually means ...

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

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

-- Bruce
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <m34s4uvtfo.fsf@cadet.dsl.speakeasy.net>
Bruce Hoult <·····@hoult.org> writes:

> In article <··············@cadet.dsl.speakeasy.net>, David Bakhash 
> <·····@alum.mit.edu> wrote:
> 
> > It's the same deal here.  You have a universal method for mutation
> > which follows logically from accessing.  You claim that the simple
> > things in Java and C++ are simpler?  Do you find writing dozens of
> > set_* and get_* methods to be simpler than the :accessor slot option
> > of defclass?  I surely don't.  Throw in that lots of [Java] code out
> > there doesn't conform to the set/get naming conventions and I'd argue
> > that it's anything but simple and straightforward.
> 
> You're right again.  Writing hundreds of trivial getters and setters in 
> Java and C++ sucks.  But you've got no choice if you want to maintain 
> the possibility that sometime in the future they might not be trivial 
> any more.
> 
> But that doesn't mean that it's the syntax of being able to put a 
> slot/field/data member reference on the left hand side of "obj.foo = 
> bar" that is at fault.  The fault is in not making this a function call, 
> under the hood.  In Dylan, declaring a slot "X.foo" automatically 
> creates a trivial getter function "foo(X)" and a trivial setter function 
> "foo-setter(newVal, X)" so that writing...
> 
>    X.foo := X.foo + 1;
> 
> ... actually means ...
> 
>    foo-setter(X, foo(X) + 1)
> 
> Of course, 99% of the time this will just turn into a simple inlined 
> load and store, just as in C, but it means that you can later change the 
> getter and/or setter to do something less trivial with no impact on the 
> client code (except recompiling it).

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

dave
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3174904618055769@naggum.net>
* Peter Norvig <·····@norvig.com>
| But when I write code on paper, I often use a style like this to
| save time.

  Interesting (implicit) question.  When I worked with Ada some 15
  years ago, it was the first and so far the last language where my
  notes on paper were practically syntactically valid -- they had to
  be to be meaningful.  Some of the redundancy you find in most other
  languages can be ignored when writing on paper, in some almost all.
  (C has a _lot_ of redundancy, for instance, mostly because of its
  sorry excuse for an explicit static typing system.)

| Actually, there are other aspects of Lisp syntax that I find more
| annoying than the parens.  Compare
| 
| 	s.X[i] = val
| to
| 	(setf (aref (csp-state-x s) i) val)

  Some of this may be handled by a specialized infix reader.  I prefer
  to bind "mathematical" syntax to $, so $ ... $ is a "mathematical"
  form.  (The choice of delimiter should be obvious, and if anything
  is obvious when it comes to special mathematical syntax, it's $.)

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

  Huh?  Of course you can use X.  Accessors are generic functions.

  I don't like the dot notation, as I already pronounce (x s) as "x of
  s", and that's as fitting for slot accessors as for function calls,
  which means that "s.x" gets the order wrong.  (I could pronounce it
  "s's x", mirroring the Norwegian pronounciation "s sin x", but that
  has always rubbed me the wrong way.)

$ (x s)[i] <- val $

  If the dot notation is important, it shouldn't be hard to add.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <m3punhusmu.fsf@cadet.dsl.speakeasy.net>
Erik Naggum <····@naggum.net> writes:

> $ (x s)[i] <- val $

Do you have code that parses this (minus any dot notation, which I
also don't care too much for)?  infix.lisp has some of the stuff I
think one would need to implement this, but I don't think it's
complete, and (sin x) is, as far as I know, expected to be sin(x) with 
infix.lisp.  What you seem to have above is a bit hybrid.  But
infix.lisp also had a way to escape to pure lisp syntax inside the
$'s.

dave
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3174940090055205@naggum.net>
* David Bakhash <·····@alum.mit.edu>
| Do you have code that parses this (minus any dot notation, which I
| also don't care too much for)?

  The implicit "to share" has been noted.  Most of my recent Lisp code
  is under "trade secret" wraps as it's work for hire these days, so
  I'm not as free to share as I once was.

| infix.lisp has some of the stuff I think one would need to implement
| this, but I don't think it's complete, and (sin x) is, as far as I
| know, expected to be sin(x) with  infix.lisp.  What you seem to have
| above is a bit hybrid.

  Well, fully parenthesized prefix syntax is a lot easier to deal with
  than the sort of hybrid prefix notation you find in infix, so
  instead of inventing a language to describe hybrid prefix in infix,
  I decided to use infix where it clearly worked well, and real prefix
  where infix doesn't work at all, such as in function calls.  Parens
  retain their Lispness, while the mathematical parens are expressed
  using brackets.

  E.g., (foo (+ a b) (* c d)) becomes $ (foo [a + b] [c * d]) $.

  Perhaps needless to say, this stuff has grown without prior design
  to guide it and with much backward compatibility to hamper any
  design, so given enough time, it would probably grow into C++.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Russell Wallace
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <39939C6F.68BF@esatclear.ie>
Erik Naggum wrote:
> 
> * Peter Norvig <·····@norvig.com>
> | But when I write code on paper, I often use a style like this to
> | save time.
> 
>   Interesting (implicit) question.  When I worked with Ada some 15
>   years ago, it was the first and so far the last language where my
>   notes on paper were practically syntactically valid -- they had to
>   be to be meaningful.

I'm curious, can you elaborate on this?  I found Ada to have even more
redundancy than the other Pascal family languages.

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3175018120252289@naggum.net>
* Russell Wallace <········@esatclear.ie>
| I'm curious, can you elaborate on this?  I found Ada to have even more
| redundancy than the other Pascal family languages.

  I think the difference is in what is redundant in Ada vs Pascal.  In
  Pascal (which I used with the UCSD p-system some time before 1980),
  I tended to jot down skeletal code that could easily be fleshed out
  when typing it in.  In Ada (ca 1985), I found that much more was too
  important to trust to memory.  My Pascal pseudo-code was nowhere
  near useful as code, but my Ada pseudo-code tended to be fragments
  of real code surrounded by comments that would be implemented.  It
  could just be that Ada needed more concentation on my part, but I
  kind of doubt that as the fundamental cause.  Ada is a very verbose
  language, but somehow, most of it needs to be said.  Pascal never
  had that "if you don't write this down, you'll forget it and waste
  time reconstructing it" feeling.

  Note that I didn't discover this dissimilarity.  It was pointed out
  to me several years later (probably after 1990) how my hand-written
  code was more than mere assistence to memory.  Taking good notes is
  an art, and getting good at it requires some guidance to avoid
  wasting time, and so I think that how you take notes about a design
  or algorithm in various languages says something about how close
  that language is to how you think.

  Sorry for being so unspecific and vague, but it's the best I can
  recall, and I haven't been thinking about this for a decade or so.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Russell Wallace
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3997B003.6518@esatclear.ie>
Erik Naggum wrote:
> 
> * Russell Wallace <········@esatclear.ie>
> | I'm curious, can you elaborate on this?  I found Ada to have even more
> | redundancy than the other Pascal family languages.
> 
>   I think the difference is in what is redundant in Ada vs Pascal.  In
>   Pascal (which I used with the UCSD p-system some time before 1980),
>   I tended to jot down skeletal code that could easily be fleshed out
>   when typing it in.  In Ada (ca 1985), I found that much more was too
>   important to trust to memory.  My Pascal pseudo-code was nowhere
>   near useful as code, but my Ada pseudo-code tended to be fragments
>   of real code surrounded by comments that would be implemented.  It
>   could just be that Ada needed more concentation on my part, but I
>   kind of doubt that as the fundamental cause.  Ada is a very verbose
>   language, but somehow, most of it needs to be said.  Pascal never
>   had that "if you don't write this down, you'll forget it and waste
>   time reconstructing it" feeling.
> 
>   Note that I didn't discover this dissimilarity.  It was pointed out
>   to me several years later (probably after 1990) how my hand-written
>   code was more than mere assistence to memory.  Taking good notes is
>   an art, and getting good at it requires some guidance to avoid
>   wasting time, and so I think that how you take notes about a design
>   or algorithm in various languages says something about how close
>   that language is to how you think.

Yeah, I think that's probably true.

>   Sorry for being so unspecific and vague, but it's the best I can
>   recall, and I haven't been thinking about this for a decade or so.

I know what you mean.  I did Ada in college around 1990 or thereabouts,
and I've forgotten a lot of the details; what I do remember is thinking
"this is like C, except it's more verbose so everything takes more
effort by a constant factor of somewhere between 1.5 and 2".  But then,
I've never found a language that matches how I think better than C, in
its way, does.

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Larry Elmore
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <oXVl5.1112$QT3.115383@paloalto-snr1.gtei.net>
"Russell Wallace" <········@esatclear.ie> wrote in message
··················@esatclear.ie...
> Erik Naggum wrote:
> >
> > * Russell Wallace <········@esatclear.ie>
> > | I'm curious, can you elaborate on this?  I found Ada to have even more
> > | redundancy than the other Pascal family languages.
> >
> >   I think the difference is in what is redundant in Ada vs Pascal.  In
> >   Pascal (which I used with the UCSD p-system some time before 1980),
> >   I tended to jot down skeletal code that could easily be fleshed out
> >   when typing it in.  In Ada (ca 1985), I found that much more was too
> >   important to trust to memory.  My Pascal pseudo-code was nowhere
> >   near useful as code, but my Ada pseudo-code tended to be fragments
> >   of real code surrounded by comments that would be implemented.  It
> >   could just be that Ada needed more concentation on my part, but I
> >   kind of doubt that as the fundamental cause.  Ada is a very verbose
> >   language, but somehow, most of it needs to be said.  Pascal never
> >   had that "if you don't write this down, you'll forget it and waste
> >   time reconstructing it" feeling.
> >
> >   Note that I didn't discover this dissimilarity.  It was pointed out
> >   to me several years later (probably after 1990) how my hand-written
> >   code was more than mere assistence to memory.  Taking good notes is
> >   an art, and getting good at it requires some guidance to avoid
> >   wasting time, and so I think that how you take notes about a design
> >   or algorithm in various languages says something about how close
> >   that language is to how you think.
>
> Yeah, I think that's probably true.
>
> >   Sorry for being so unspecific and vague, but it's the best I can
> >   recall, and I haven't been thinking about this for a decade or so.
>
> I know what you mean.  I did Ada in college around 1990 or thereabouts,
> and I've forgotten a lot of the details; what I do remember is thinking
> "this is like C, except it's more verbose so everything takes more
> effort by a constant factor of somewhere between 1.5 and 2".  But then,
> I've never found a language that matches how I think better than C, in
> its way, does.

C's easier to write than Ada, that's for sure, but I ended up greatly
preferring Ada to C for a number of reasons (note: I'm talking about Ada 95,
which has some serious improvements over Ada 83). First, since my basic
designs were usually sound, once the program compiled in Ada, it almost
always ran as expected. When it didn't, the problem was usually so easy to
find that I almost never had use a debugger. The only times I had to use a
debugger was when I had a misconception of the language standard and a
construct wasn't doing what I thought it was supposed to, so the debugger
showed me what I had to go back and restudy.
Second, it was always much easier to go back later and figure out what a
piece of code was doing in Ada than in C. Ada was deliberately designed with
this aspect in mind since most code is written once, but read and modified
many times, and I think it's verboseness is an advantage in this situation.
I usually didn't have to comment any of my Ada code except for a brief
description of what a procedure or function did if it wasn't obvious from
the name.
Third, Ada's package system (_much_ improved in Ada 95 over Ada 83) is
vastly superior to C's #include. I think large projects would be
considerably easier to manage in Ada than in C, but I have no personal
experience in this. Attributes are something in Ada that make some things a
lot easier than in C, and array handling is also far better. Something like
C's printf() would be nice in Ada, though.

C++ is something of an abortion in my view. And Lisp and CLOS are head and
shoulders above the competition, IMHO.

Larry
From: Bruce Hoult
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <bruce-C3C291.10175310082000@news.akl.ihug.co.nz>
In article <·················@norvig.com>, ·····@norvig.com wrote:

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

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


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

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

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

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

-- Bruce
From: Johan Kullstam
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <m3wvhq1cd2.fsf@sysengr.res.ray.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

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

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

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

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

-- 
J o h a n  K u l l s t a m
[········@ne.mediaone.net]
sysengr
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <3991C049.7283E020@kurtz-fernhout.com>
Johan -

Thanks for the excellent suggestions. Some comments below.

Johan Kullstam wrote:
> 
> Paul Fernhout <··········@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
> [········@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
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <874s4udtz4.fsf@piracy.red-bean.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

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

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

-- 
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <39920F83.6F5D608A@kurtz-fernhout.com>
Craig -

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

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

Craig Brozefsky wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > Good suggestion. However, what I want is the "edge" parentheses to
> > disappear, not the core parentheses. Thus I can't just change the font.
> > I need something smart enough to know what are edge parentheses (when
> > the structure is properly indented), and which are not. Maybe emacs can
> > hide edge parentheses?
> 
> I suggest you put this in your interface, not in the code you intend
> to share with the rest of the lisp community.
> 
> An extension to emacs lisp mode with identified those "edge"
> parentheses and used them to enforce a significant indentation
> convention would allow you to read the existing lisp code as you like
> to see it, but without requiring the rest of the community to convert
> their code to the new syntax.  If emacs would then produce normal lisp
> code from your "indentation significant lisp buffer" you could run it
> in any lisp system, and share it with other lispers, without them
> having to learn the rules for your new indentation system.
> 
> --
> Craig Brozefsky               <·····@red-bean.com>
> Lisp Web Dev List  http://www.red-bean.com/lispweb
> ---  The only good lisper is a coding lisper.  ---
From: Tom Breton
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <m38zu69sgp.fsf@world.std.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

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

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

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

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

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

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

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

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

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

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

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

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

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

If it does clarify structure.

Other problems:

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

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

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

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

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

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

-- 
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <3992235B.5C9B717C@kurtz-fernhout.com>
Tom-

Thanks for the comments. A few elaborations below.

Tom Breton wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> >
> > ======= Some advantages =======
> >
> > One advantage to such an approach it that it might make it easier to
> > compose Lisp on devices without keyboards. An indent-line button and an
> > unindent-line button would be useful in that case.
> 
> It isn't clear how that would make it easier; I suspect it would be
> harder.  It's also not clear why those two buttons would be better
> than "(" ")" keys.  In any case, how many people write code that way?

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

> > Significant indentation might make it easier for developers who don't
> > know Lisp well to understand a Lisp program's structure.
> 
> Again, that's kind of a lost cause.  If they don't know Lisp, they
> won't make sense of it regardless.  If they know Lisp even a little
> bit, they should already be past parentheses problems.

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

I think, for example, this:

  define (foo x)
    * x x 

is less intimidating than this:

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

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

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

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

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

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

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

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

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

> > Also, with significant indentation, indentation can not as often be
> > misleading as it can be with parentheses.
> 
> Indentation in Lisp can be trivially made to match the parentheses in
> a good editor.

True. But it is still one more thing to worry about -- one more function
to have to learn. One more thing to have to do periodically.
 
> > ======= Some disadvantages =======
> >
> > I'm sure people will point out lots. Send 'em on!
> 
> > The major one is that this is non-standard and not available.
> 
> > Also, it may confuse some people (novices?) as much as it clarifies
> > things to others.
> 
> If it does clarify structure.

Well, I think it does. Obviously several people on this newsgroup
disagree.
 
> Other problems:
> 
> It would not survive accidental reformatting.  (A problem Lisp only
> has with strings' newlines)

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

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

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

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

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

Hopefully though, in the case of emacs, using the strategy a couple of
people have suggested in other posts, this "edge parentheses removal
process" could be made transparent to the rest of the system.
 
> Printing data readably would be tricky.  For embedded expressions, you
> must figure out the proper level of indentation to start at.  And it
> would be disastrous when you missed, because there'd be no parentheses
> to indicate how the expression is really scoped.

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

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

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

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

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

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

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

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

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

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

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

OK. It might not be.

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

Well, thanks!

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

I enjoyed your comments.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com
From: Daniel Barlow
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  indentation?
Date: 
Message-ID: <87r97xcldn.fsf@tninkpad.telent.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:
> But I think at a cost -- both in the complexity of learning emacs and in
> the complexity of having to think about some of these functions. For
> example, with indentational syntax, worrying about indentation is
> paradoxically a non-issue, because you would rarely or never want to
> reindent code.

I don't buy that.  Supposing you have a chunk of code

(let ((b (cdr x)))
  (doo b)
  (and (worth-it-p b)
       (pay b))
  (bar b)
  (sting-like-a b))

then later realise that x can be an atom.  So you surround the whole
thing with "(if (listp x)".

To do this using CL, you just type that on the line above the original
code, close the paren at the end of the conditional and run M-x
indent-sexp.  Because there are parens denoting the structure, it's
simple for the editor to reindent using the information that they
contain.  I'm not sure whether you could do this reliably if the _only_
indication of structure were the indentation.


-dan

-- 
  http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <39933347.886446A5@kurtz-fernhout.com>
Daniel-

Thanks for the interesting comment. Let's work through that example,
using syntactically significant indentation and no edge parentheses.

Say you have an indented equivalent to the expression you defined:

  let 
    ...
      b (cdr x)
    doo b
    and
      worth-it-p b 
      pay b
    bar b
    sting-like-a b

then you later realise that x can be an atom.  

So you now want to make this S-expression part of another S-expression. 

First you select the expression. You know where the expression ends by
finding by eye the first line that is indented equal to or less than the
"let" starting the S-expression. (To make this easier, an
indentational-aware editor could select to that line when you press a
"select expression" meta-key combination when on the line with "let".) 

Having selected the expression you wish to embed, you do now indent the
entire expression using an "indent-block" editor command key
combination. 

Then you type in the statement "if (listp x)" above it, at the previous
indentation. This produces:

  if (listp x)
    let 
      ...
        b (cdr x)
      doo b
      and
        worth-it-p b 
        pay b
      bar b
      sting-like-a b

You do not need to add a paren, and you do not need to reindent (beyond
the initial indent-block command). Note also that in a complex
expression, using conventional parenthetical S-expression syntax, it
might have been easy to have inserted that extra paren at the wrong
place. With an indentational system, that particular mistake could not
be made (although I'm sure other mistakes could).

Note that this process could be made even easier by assuming a very
smart indentionally aware Lisp editor. In that case you would just put
the cursor on "let", press a key combination to make a new line indented
to the same level above the expression, type "if (listp x)" on that line
above the expression, and then hit a key combination that says "make the
next S-expression be indented under this one". 

Or, this might even be all set up on one key combination -- "insert line
and nest this one" activated with the cursor on the "let". Then you just
type in "if (listp x)" and you're done.

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

Daniel Barlow wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> > But I think at a cost -- both in the complexity of learning emacs and in
> > the complexity of having to think about some of these functions. For
> > example, with indentational syntax, worrying about indentation is
> > paradoxically a non-issue, because you would rarely or never want to
> > reindent code.
> 
> I don't buy that.  Supposing you have a chunk of code
> 
> (let ((b (cdr x)))
>   (doo b)
>   (and (worth-it-p b)
>        (pay b))
>   (bar b)
>   (sting-like-a b))
> 
> then later realise that x can be an atom.  So you surround the whole
> thing with "(if (listp x)".
> 
> To do this using CL, you just type that on the line above the original
> code, close the paren at the end of the conditional and run M-x
> indent-sexp.  Because there are parens denoting the structure, it's
> simple for the editor to reindent using the information that they
> contain.  I'm not sure whether you could do this reliably if the _only_
> indication of structure were the indentation.
> 
> -dan
> 
> --
>   http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
From: Espen Vestre
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <w6lmy4jmi7.fsf@wallace.nextel.no>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Say you have an indented equivalent to the expression you defined:
> 
>   let 
>     ...
>       b (cdr x)
>     doo b
>     and
>       worth-it-p b 
>       pay b
>     bar b
>     sting-like-a b

Hmm, I actually think this was siginficantly heavier to parse than the
original you quoted.

(But you can tell from my signature that lisp has altered my brain ;-))
-- 
  (espen)
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <39960C6E.F7B327D6@kurtz-fernhout.com>
Espen-
 
If that style seemed heavier to parse, then how about this?

  let [[ b (cdr x)
    doo b
    and (worth-it-p b) (pay b)
    bar b
    sting-like-a b

It uses incomplete bracket notation (list ends at end of line) and
embedded paren expressions (which are parsed using regular conventional
lisp parsing rules).

The original for comparison:

  (let ((b (cdr x)))
    (doo b)
    (and (worth-it-p b)
         (pay b))
    (bar b)
    (sting-like-a b))

Thanks for your post!

-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


Espen Vestre wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > Say you have an indented equivalent to the expression you defined:
> >
> >   let
> >     ...
> >       b (cdr x)
> >     doo b
> >     and
> >       worth-it-p b
> >       pay b
> >     bar b
> >     sting-like-a b
> 
> Hmm, I actually think this was siginficantly heavier to parse than the
> original you quoted.
> 
> (But you can tell from my signature that lisp has altered my brain ;-))
> --
>   (espen)
From: Espen Vestre
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <w6em3scmlt.fsf@wallace.nextel.no>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Espen-
>  
> If that style seemed heavier to parse, then how about this?
> 
>   let [[ b (cdr x)
>     doo b
>     and (worth-it-p b) (pay b)
>     bar b
>     sting-like-a b

immediate core dump.  Sorry...

-- 
  (espen)
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <3175256806247568@naggum.net>
* Paul Fernhout <··········@kurtz-fernhout.com>
| It uses incomplete bracket notation (list ends at end of line) and

  Geez, man!  Have you no concern for your readers at all?

  Maybe you should check out one of those write-only languages.  I
  hear Larry Wall's big on those.  One of his creations, Hurl (or
  something close) is chock full of syntactrickery and magic that is
  _very_ hard to read, but I'm sure it's so efficient to write that
  it's a lot faster to write it again than to try to read it before
  fixing it.�

#:Erik
-------
� Only very slightly unfair.
-- 
  If this is not what you expected, please alter your expectations.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <399C5306.95D8E374@kurtz-fernhout.com>
Erik-

You have a good point on readability issues, and for now I have dropped
this idea (incomplete bracket notation) from the implementation. Also,
from a learnability standpoint, it is one more concept to learn (or
explain) which may not be needed. 

I may revisit it later -- because I am still unsure of whether or not
incomplete bracket notation will be more readable given other aspects of
the system. But, for now, it is easiest to leave it out and see whether
down the road it is desirable after everything else works. 

I'm designing this approach mainly on the premise that something is done
when you can't take anything else away, as opposed to the alternative
(more frequently used) design philosphy that something is done when you
don't want to add anything else (which you can afford). Obviously both
design philosophies have their place depending on the circumstance.
Since partial bracket notation is not needed, and worse as you point out
it may cause confusion on reading, out it goes -- until I have proof it
is essential or at least very worthwhile.

However, I have retained part of the concept in the current
implementation as supporting a "." at the start of an otherwise empty
line to indicate a placeholder for an extra level of parenthetical
nesting. 

Thus:

  let
    .
      x 10
      y 20

is equivalent to:

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

Currently in the implementation, the "." is not allowed anywhere else on
a line. And in theory (but not practice) "." followed by a S-expression
would be a syntax error (right now the rest of the line is ignored.)

I know the "." is used in other ways in Lisp and Scheme (occasionally),
but it is not allowed to start an expression (to my knowledge), and in
practice I think it would be OK to restrict its use otherwise to only be
allowed in fully parenthesized subexpressions to get the existing
meanings. This decision also made the indentational parser easier to
write, as I could rely on the existing Scheme parser for handling things
like this (and the same would be true for someone implementing something
for the Lisp case).

Thanks for your 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

Erik Naggum wrote:
> 
> * Paul Fernhout <··········@kurtz-fernhout.com>
> | It uses incomplete bracket notation (list ends at end of line) and
> 
>   Geez, man!  Have you no concern for your readers at all?
> 
>   Maybe you should check out one of those write-only languages.  I
>   hear Larry Wall's big on those.  One of his creations, Hurl (or
>   something close) is chock full of syntactrickery and magic that is
>   _very_ hard to read, but I'm sure it's so efficient to write that
>   it's a lot faster to write it again than to try to read it before
>   fixing it.�
> 
> #:Erik
> -------
> � Only very slightly unfair.
> --
>   If this is not what you expected, please alter your expectations.
From: Lars Lundback
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <3993FC9C.ADF32880@era.ericsson.se>
Paul, 

Thank you for introducing and keeping this particular thread alive for
so long. You have a nice way of saying things, and it is always a
pleasure to listen to friendly discussions.

I see that you move away from syntax, towards some kind of program
source editor that you outlined in your RFC. Such a programmer's tool
for Lisp-like language constructs, seems more appropriate than dealing
with Lisp syntax itself. The code eventually generated would contain all
the parenthesis needed by Lisp. (?)

Your code examples triggered my memory. I remembered some feeble
attempts of my own, along these lines, some 15 years ago. At that time,
I had to introduce (Common) Lisp to our students in the mechanical
CAD/CAM domain, and tried to do away with parenthesis, at least in
application programming. 

I would like to disregard the tool and the interaction with it. It was
said before: of course it can be done. But compare the two examples,
having would-be Lisper's in mind. 

Paul Fernhout wrote:
> 
>   let
>     ...
>       b (cdr x)
>     doo b
>     and
>       worth-it-p b
>       pay b
>     bar b
>     sting-like-a b
>
> 
> Daniel Barlow wrote:
> >
> > (let ((b (cdr x)))
> >   (doo b)
> >   (and (worth-it-p b)
> >        (pay b))
> >   (bar b)
> >   (sting-like-a b))
> >

Others have already stated how important the parenthesis are, when
dealing with Lisp code. So do I, they are _not_ noise. In fact, when
looking at your version, I find that my eyes "fall off" the line edges. 

The "de-parenthesised" version may look easier to a non-Lisper. There is
a superficial resemblance to ordinary text, and indentation seems to
convey structure (although not to me).

However, the "extra" parenthesis were no burden to some of the students,
once they got past the initial shock. Those that didn't, were unsuited
for programming/problem-solving in the first place, and the
first example had not helped them any. 

I think there is a place in this world for your fewer-parenthesis
scheme. Excuse, I couldn't resist.  :-)

A bounded, application-oriented language (perhaps with a Lisp touch) is
probably best. If the vocabulary and syntax is well matched against the
domain, "superfluous" parenthesis can be avoided. But indentation as a
replacement generally for the lists' parenthesis? I don't think so. 

Lars

PS.  (A slightly similar topic, about where to put trailing parenthesis,
was very hot in this group some time ago. That discussion sort of
resolved itself, once the prerequisites of the programmers' situation
(ICAD in that case) were visible to us.)
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <39961649.AF961F7A@kurtz-fernhout.com>
Lars-

Thanks for the pleasant message. Some comments below.

Lars Lundback wrote:
> 
> Paul,
> 
> Thank you for introducing and keeping this particular thread alive for
> so long. You have a nice way of saying things, and it is always a
> pleasure to listen to friendly discussions.

You're welcome. Thanks for the compliment.

I should say people like Eric Clayberg and James A. Robertson on
comp.lang.smalltalk are my role models. I've learned a lot from seeing
how they respond publicly in their posts. 

I've certainly learned a lot from this thread. Although at some point
I'm hoping things wind down so I can put more time into implementing
something. :-)

> I see that you move away from syntax, towards some kind of program
> source editor that you outlined in your RFC. Such a programmer's tool
> for Lisp-like language constructs, seems more appropriate than dealing
> with Lisp syntax itself. The code eventually generated would contain all
> the parenthesis needed by Lisp. (?)

That's the way I'm leaning towards at this point. My first approach if I
pursue it is to have something that can read the syntax from a file and
generate parsable Scheme code.

> Your code examples triggered my memory. I remembered some feeble
> attempts of my own, along these lines, some 15 years ago. At that time,
> I had to introduce (Common) Lisp to our students in the mechanical
> CAD/CAM domain, and tried to do away with parenthesis, at least in
> application programming.

Interesting. 

Obviously I've seen Python and Occam which both use significant
indentaion. Actually, as I think on it, I vaguely remember someone (at
CMU? NC State?) perhaps mentioning casually to me a dozen years or more
ago that indentation could replace parens (I can't remember specifics,
although I do remember doubting it!). I don't claim this idea to be
uniquely original, although I still haven't heard of an actual Lisp that
uses it. Yours sounds close -- although it seems perhaps you are
describing a "little language"?

> I would like to disregard the tool and the interaction with it. It was
> said before: of course it can be done. 

Well, at least that's a little reasasuring...

> But compare the two examples,
> having would-be Lisper's in mind.
> 
> Paul Fernhout wrote:
> >
> >   let
> >     ...
> >       b (cdr x)
> >     doo b
> >     and
> >       worth-it-p b
> >       pay b
> >     bar b
> >     sting-like-a b
> >
> >
> > Daniel Barlow wrote:
> > >
> > > (let ((b (cdr x)))
> > >   (doo b)
> > >   (and (worth-it-p b)
> > >        (pay b))
> > >   (bar b)
> > >   (sting-like-a b))
> > >
> 
> Others have already stated how important the parenthesis are, when
> dealing with Lisp code. So do I, they are _not_ noise. In fact, when
> looking at your version, I find that my eyes "fall off" the line edges.

OK. And I can understand things more better from the way you put it as
"falling off the line". That is an interesting point. Sort of like
safety rails for the eye. I'll have to consider that.

On what I mean by "noise"... 

Maybe "noise" isn't the best term because it does sound derogatory. I am
trying to use it in an engineering sense on the one hand, and admittedly
in an aesthetic sense on the other hand. 

However, I have always tried to call it "high frequency noise" and not
just "noise".
What I mean by "high frequency noise" is simply that "((((((" looks a
lot like "(((((". They are both "noisy expressions" in the sense of
presenting lots of things that seem to demand attention. Also a row of
parens compared to a mix of other characters sets up a certain visual
effect (almost a Moire pattern?). 
  http://www.sandlotscience.com/Moire/Moire_frm.htm
Although now that I think about it, if serifs and such on characters are
tinier, they are really higher frequency. So perhaps I should say
repeated parens are "low frequency noise"? Of course, low frequency
noise can be that sort of bass rumble from a thunderstorm that sets dogs
to barking...

> The "de-parenthesised" version may look easier to a non-Lisper. There is
> a superficial resemblance to ordinary text, and indentation seems to
> convey structure (although not to me).

OK. However, I am trying to convince myself (perhaps by trying to
convince others) that indentation can convey meaningful structure --
enough to define arbitrary S-expressions.

> However, the "extra" parenthesis were no burden to some of the students,
> once they got past the initial shock. Those that didn't, were unsuited
> for programming/problem-solving in the first place, and the
> first example had not helped them any.

Well, there are many types of people with many different abilities.
And the woods would be very quiet if no bird sang there but the best...
That being said, obviously not everybody is suited for everything.

It seems to me that many people never get over the shock enough to even
give Lisp family languages a chance. Obviously if you are taking a class
on it you may be motivated. But there are so many programmers out there
who could learn Lisp who don't. And I think one reason is the
typography. Even if it is only a one hour hurdle -- maybe that is too
much, given all the other alternatives (mainly C/C++ and VB), and the
fact that Lisp is the underdog (along with Smalltalk and Forth and lots
of other languages people shy away from due to other minor hurdles).

> I think there is a place in this world for your fewer-parenthesis
> scheme. Excuse, I couldn't resist.  :-)

:-)

> A bounded, application-oriented language (perhaps with a Lisp touch) is
> probably best. If the vocabulary and syntax is well matched against the
> domain, "superfluous" parenthesis can be avoided. But indentation as a
> replacement generally for the lists' parenthesis? I don't think so.

Well, I'll have to see how far it gets me before it runs out of gas. I'm
not actually trying to convert anyone at this point. My major reason in
starting this thread (beyond of course fame or notoriety as fate deals
it :-) is to see if syntactically significant indentation had been done
before in Lisp or Scheme, as well as whether there were any obvious
technical holes in the idea of representing S-expressions using
indentation (none so far, although obviously people point to other
practical difficulties). 

I'm mainly thinking about using this syntax myself to build an
application in DrScheme. That would at least give me a little practical
experience with the concept.

If I can just get a first translator going... Then I can bootstrap the
parser in itself.

> Lars
> 
> PS.  (A slightly similar topic, about where to put trailing parenthesis,
> was very hot in this group some time ago. That discussion sort of
> resolved itself, once the prerequisites of the programmers' situation
> (ICAD in that case) were visible to us.)

Thanks for the pointer.

Well, of course, I might say that trailing parentheses are superfluous. 

Actually, I'm looking at extending this approach to include a bracket
notation where the bracketed list ends at the end of the line. Thus:

  define [ foo x
    let [[ y 10
      print [ * y x

as equivalent to:

  (define (foo x)
    (let ((y 10))
      (print (* y x))))

Thanks again for the great comments and kind words. 

-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
From: Aaron Crane
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <djsnsc3dqc.fsf@planet.dcs.ed.ac.uk>
In article <·················@kurtz-fernhout.com>,
Paul Fernhout <··········@kurtz-fernhout.com> writes:
> I think, for example, this:
> 
>   define (foo x)
>     * x x 
> 
> is less intimidating than this:
> 
>   (define (foo x)
>     (* x x))
> 
> for someone not used to dealing with lots of parentheses.

I think someone who isn't used to dealing with lots of parentheses has
insufficient experience to be able to pass judgment on whether Lisp is worth
investigating further.  And someone who _is_ used to dealing with lots of
parentheses is unlikely to notice that they are there -- as many Lisp
programmers report.  It seems misguided at best to optimise for novices,
especially for a programming language: one hopes and expects that people
remain novices for only a vanishingly small fraction of their lives as a
programmer.

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

Precisely.  This is one of the complaints I have with the way Python does
things.  I've heard Python programmers saying that Python syntax is
`parsable pseudo-code' or some such -- but none seem to realise just how bad
an idea that is.  The point about pseudo-code is that it's a helpful,
abstract notation _for_humans_.  Pseudo-code isn't given to compilers to
deal with.  It isn't read and stored as data.  It isn't passed around via
lossy communication channels which have problems with whitespace.  Most
importantly, though, it tends to be written once, and deleted once finished
with.  This means that certain of its properties (that it can be hard to
parse unambiguously, that its textual representation is far from robust, and
so on) aren't a problem.  However, when you use such notations for real
code, these things can make you lose big.

-- 
Aaron Crane   <···········@pobox.com>   <URL:http://pobox.com/~aaronc/>
 ** Please send on-topic followups by Usenet, not email **
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <3174982969133502@naggum.net>
* Aaron Crane <···········@pobox.com>
| It seems misguided at best to optimise for novices, especially for a
| programming language: one hopes and expects that people remain
| novices for only a vanishingly small fraction of their lives as a
| programmer.

  What!?  And run counter to all established marketing practice for
  computers and software and operating systems and and and...?

  The only good novice is one who remains a novice and continues to
  buy "introductory" books for novices/dummies, pays for expensive
  courses but learns nothing, and who ensures that non-novices get
  paid very well to fix his problems.  Novices-who-remain-novices are
  probably responsible for 25% of the fraction of the GNP that is
  related to computers.  And now you're suggesting we not cater to
  them?  What are you?  Some, some, uh, some _professional_?

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant  indentation?
Date: 
Message-ID: <AxCUOTky6Rg031ODw2kNDKNsBaV4@4ax.com>
On 11 Aug 2000 11:42:49 +0000, Erik Naggum <····@naggum.net> wrote:

>   What!?  And run counter to all established marketing practice for
>   computers and software and operating systems and and and...?

This paper, among other things, discusses the problems of optimizing user
interfaces for novices:

  The Anti-Mac Interface
  http://www.acm.org/cacm/AUG96/antimac.htm


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <3996274B.16912BF7@kurtz-fernhout.com>
Aaron-

Interesting points. Some comments below.

Aaron Crane wrote:
> 
> In article <·················@kurtz-fernhout.com>,
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> > I think, for example, this:
> >
> >   define (foo x)
> >     * x x
> >
> > is less intimidating than this:
> >
> >   (define (foo x)
> >     (* x x))
> >
> > for someone not used to dealing with lots of parentheses.
> 
> I think someone who isn't used to dealing with lots of parentheses has
> insufficient experience to be able to pass judgment on whether Lisp is worth
> investigating further.  

While your point is well made, unfortunately for Lisp's rate of
adoption, many programmers are passing judgment on it based on a few
minutes spent looking at it, and others after just one class. This may
not be fair, or even smart, but it is more or less what happens in
practice. (Obviously there are other factors as well.)

"Worse is Better" is a nice essay that makes a Lisp developer feel good, 
  http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html
but sometimes it is the elephant in the living room that no one wants to
talk about.
(For the record, I think there is a lot of truth in the "Worse is
Better" essay.)
 
For example, I last read this entire article a couple years ago:
    http://www.ai.mit.edu/docs/articles/good-news/good-news.html
but I don't recall it mentioning parentheses much. Does it? There is not
a mention of parentheses on the first page. Yet at this point Lisp code
appearance represents a major hurdle to Lisp family language adoption --
even if parentheses work well in practice.

In my case, I am "passing judgment" on Lisp based on about three to four
person months spent with the language in chunks of a few weeks spread
over about twenty years. Is that fair? Maybe not, but that's the
situation. 

And of course, to an extent, I also have to justify my decision to use
Lisp or Scheme to a business partner who has never programmed it at all
and has already expressed some displeasure with its parentheses.
Frankly, I think a lot of Lisp programmer "wannabees" may be in a
similar situation of having to justify the language to management who
may not have gotten over (and may never get over) the parentheses
hurdle. 

Yet, I think Algol-like Lisp hybrids like Dylan, NewtonScript, and
Python don't quite have the charm of the Lisp language family prefix
notation approach (not to say they don't each have interesting features
and things at which they excel). I believe the approach I outlined to be
in a very different class from these attempts because I suggest an
absolute minimum set of changes targeted purely at one issue --
minimizing edge parentheses made redundant by syntactically significant
indentation. Everything else about the language stays the same, so much
that I am hoping a preprocessor of a page of code or so can do the
translation.

Even if the reaction of novices to the parentheses may not in the end be
justified, one can't deny the initial reaction many people have when
confronted with a Lisp program. That is a problem reducing Lisp and
Scheme adoption rates, whether or not dealing with parentheses are a
problem in practice.

And I may point out, I take great pains to separate the concept that I
see Lisp having a disadvantage in this area (perhaps surmountable with
experience) from the issue of whether overall the advantages to using
Lisp outweigh the disadvantages, taken as a whole. To any non-Lisp
developers out there, I am not saying "don't learn Lisp or Scheme
because of parentheses". <- not saying this! I am saying "Lisp or Scheme
are great languages to learn and they are worth learning despite any
initial discomfort with parentheses". But to the Lisp developers out
there, I would still like to say, "let's admit there is an acceptance
issue or entry barrier and try to find a way around it". My way around
the entry barrier is to explore indentational syntax. There may be other
ways having more to do with education or presentation.

> And someone who _is_ used to dealing with lots of
> parentheses is unlikely to notice that they are there -- as many Lisp
> programmers report.  

Obviously, most or all Lisp programmers would agree with you. But this
is true for many situations where one picks up a learning curve and
learns to "chunk" a complex problem domain or complex visual input (like
a chess board). Ask a 747 Pilot whether the cockpit seems complex and
I'm sure they will point out how it is second nature to them where
everything is. But, that does not prevent research on new pilot
interfaces -- especially ones that make certain common errors less
common.

> It seems misguided at best to optimise for novices,
> especially for a programming language: one hopes and expects that people
> remain novices for only a vanishingly small fraction of their lives as a
> programmer.

While I think removing edge parentheses may have benefits for novices, I
admit that I don't know for sure, and it may have no benefit, or even
make it harder for novices to learn Lisp.

The major thing that drives my approach is admittedly my own sense of
aesthetics after having programmed in a wide variety of languages for
20+ years (including a small amount of Lisp in several small projects).
Lisp S-expressions defined in an indentational typography are the
closest I have been able to come so far to defining a "spare" language
with no excess characters -- one that is primarily just naming and
structuring. I think this approach may hold benefits for novices and
experts alike -- but I have no proof.

And, I admit, not everyone may see something like this as clear:

  define (hello-world)
    print "hello world"

  (hello-world)

> > Meaningful hierarchical indentation is often encountered outside of
> > programming. People use it all the time to make outlines. People write
> > pseudo-code using meaningful indentation.
> 
> Precisely.  This is one of the complaints I have with the way Python does
> things.  I've heard Python programmers saying that Python syntax is
> `parsable pseudo-code' or some such -- but none seem to realise just how bad
> an idea that is.  

I think the phrase Python programmers use is "executable pseudo-code"
meaning that it looks like pseudo code but it actually runs and works.

This slight difference weakens the following point you made.

> The point about pseudo-code is that it's a helpful,
> abstract notation _for_humans_.  Pseudo-code isn't given to compilers to
> deal with.  It isn't read and stored as data.  It isn't passed around via
> lossy communication channels which have problems with whitespace.  Most
> importantly, though, it tends to be written once, and deleted once finished
> with.  This means that certain of its properties (that it can be hard to
> parse unambiguously, that its textual representation is far from robust, and
> so on) aren't a problem.  However, when you use such notations for real
> code, these things can make you lose big.

I can see how one can fool oneself with pseudo code. That is quite true.

It is also true tools and channels have problems with whitespace.
However, if the channels don't preserve white space, then one needs to
work around this -- like using Zip files to transmit code and such. Or
one needs to upgrade editors. Obviously this assumes the benefits are
worth the upgrades. I feel they likely are, but I'll admit I have little
direct proof at this point, because I have never written a serious
program in this Lispish indentational syntax (beyond coding the simple
examples). However I have written bigger programs in Python and Occam
and they worked well and were maintainable (IMHO).

I actually find it ironic that probably most Lisp developers responding
to this thread are in all likelihood using a mail reader that shows them
the threaded discussion as a hierarchical tree. Thus, the very tool Lisp
developers are using to say indentation isn't good enough to present
structure (without parens) is itself indentationally based and has no
parens. Obviously this analogy has some limits. One doesn't usually
rearrange mail items in the tree, so this point does not apply well to
arguments related to the potential fragility of such structures. But I
still think there is some truth to this point.

> Aaron Crane   <···········@pobox.com>   <URL:http://pobox.com/~aaronc/>
>  ** Please send on-topic followups by Usenet, not email **

Thanks again for your 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
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <OruWOfJZDBGdMnt5XdXn1sgH9Ua4@4ax.com>
On Sun, 13 Aug 2000 00:42:51 -0400, Paul Fernhout
<··········@kurtz-fernhout.com> wrote:

> (For the record, I think there is a lot of truth in the "Worse is
> Better" essay.)

Do you plan to hang around Minneapolis next October? If so, you may attend
the panel "Back to the Future: Is Worse (Still) Better?" with Gabriel--and
others--at OOPSLA 2000. If so, after the event I would appreciate it if you
could tell us something about the discussion.


> And of course, to an extent, I also have to justify my decision to use
> Lisp or Scheme to a business partner who has never programmed it at all
> and has already expressed some displeasure with its parentheses.

Does your partner trust you? If so, regardless of his displeasure with
parentheses, he should at least try to learn some more about the language.
A good partnership should be based on trust. If a partner does a proposal,
the other one(s) should have at least a moral obligation to evaluate it
without prejudices.


> Frankly, I think a lot of Lisp programmer "wannabees" may be in a
> similar situation of having to justify the language to management who
> may not have gotten over (and may never get over) the parentheses
> hurdle. 

Do you think that parentheses are the only--or most important--barrier to
management acceptance?


> Even if the reaction of novices to the parentheses may not in the end be
> justified, one can't deny the initial reaction many people have when
> confronted with a Lisp program. That is a problem reducing Lisp and
> Scheme adoption rates, whether or not dealing with parentheses are a
> problem in practice.

If those novices are so superficial, maybe they should stay away from
advanced technologies.


> issue or entry barrier and try to find a way around it". My way around
> the entry barrier is to explore indentational syntax. There may be other

Let's suppose your indentational syntax proves terrific, and beginners
finally become comfortable with reading and writing Lisp code. Are
parentheses the only--or main--difficulty of the language? What's next?
What does it happen if you discover they have problems with higher order
functions, macros, packages or other Lisp features? Do you change the
syntax or semantics of the language?


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <3996CA2F.5B6EF107@kurtz-fernhout.com>
Paolo-

Thanks for the reply. SOme comments below.

Paolo Amoroso wrote:
> 
> On Sun, 13 Aug 2000 00:42:51 -0400, Paul Fernhout
> <··········@kurtz-fernhout.com> wrote:
> 
> > (For the record, I think there is a lot of truth in the "Worse is
> > Better" essay.)
> 
> Do you plan to hang around Minneapolis next October? If so, you may attend
> the panel "Back to the Future: Is Worse (Still) Better?" with Gabriel--and
> others--at OOPSLA 2000. If so, after the event I would appreciate it if you
> could tell us something about the discussion.

Minneapolis/St.Paul is one of my favorite metropolises, but at the
moment I have no plans to atttend. Thanks for the pointer -- I certainly
will be watching for a summary of that talk.

> > And of course, to an extent, I also have to justify my decision to use
> > Lisp or Scheme to a business partner who has never programmed it at all
> > and has already expressed some displeasure with its parentheses.
> 
> Does your partner trust you? If so, regardless of his displeasure with
> parentheses, he should at least try to learn some more about the language.
> A good partnership should be based on trust. If a partner does a proposal,
> the other one(s) should have at least a moral obligation to evaluate it
> without prejudices.

Actually it would be "her displeasure" (as I was referring to my wife,
the "Kurtz" in Kurtz-Fernhout Software).

People often talk about trust as if it were absolute. Often trust is
incrementally gained, within certain defined areas (like when you trust
a user to access certain files as themselves under Unix but not all as
root, until perhaps you trust them enough to make them a system
administrator). Trust is often earned slowly and sustained over time.
Trust works both ways, too. There is also in a way a trust not to
present things that require too much trust (i.e. not to ask people to
take too many risks as a proof of "trust").

She is willing to consider learning Lisp and has in the past expressed
interest in it. In this particular case, I would be doing all of the
development, but there is always the issue of maintenance down the road.
While her approval is a factor, there is still an issue for myself with
my own aproval of the language (versus say Python or Smalltalk or C or
Delphi which I have all used for other projects).

I think we all bring our prejudices to the table, although ideally we
rise above them as you point out.

> > Frankly, I think a lot of Lisp programmer "wannabees" may be in a
> > similar situation of having to justify the language to management who
> > may not have gotten over (and may never get over) the parentheses
> > hurdle.
> 
> Do you think that parentheses are the only--or most important--barrier to
> management acceptance?

There are many other factors -- familiarity, prefix notation, functional
style, availability of libraries, availability of support, availability
on specific platforms, availability of programmers (network effect),
whether it fits into the Microsoft vision (ugh!), and so on. (This isn't
meant to slam any particular Lisp implementation, as obviously many of
them are quite complete in terms of libraries and support.)

Still, I feel the parentheses are the single worst adoption hurdle in a
causal review, and are sort of symbolic of the language's acceptance
difficulties. (But I am not speaking from much direct experience with
managers on this point, so I may well be wrong here.) Indentational
syntax (if it was other than the vaporware it is at this point) might
help get over that hurdle, to bring the adoption discussion to the real
issues (where Lisp still would face difficulties due to "network
effects" in the Wintel world favoring Java, VB, and C/C++).

> > Even if the reaction of novices to the parentheses may not in the end be
> > justified, one can't deny the initial reaction many people have when
> > confronted with a Lisp program. That is a problem reducing Lisp and
> > Scheme adoption rates, whether or not dealing with parentheses are a
> > problem in practice.
> 
> If those novices are so superficial, maybe they should stay away from
> advanced technologies.

People are often superficial regarding languages (or anything) at first
(especially if they have never programmed before or only used one other
language). They make the best decisions they can on the limited data
they have (given limited time to acquire and process data) -- because
they often have to make a decision right now. They also satisfice --
looking for a solution they think is "good enough", hence "worse is
better".

The reality is that programming is becoming more and more important to
people's lives. People do learn to program -- the issue is more, if they
don't choose Lisp, why not? And how can that be overcome?  Obviously,
this issue may be much deeper than typography. Typography is just the
only thing I can think to change with reasonable effort, while still
preserving Lisp/Scheme's power and elegance.

> > issue or entry barrier and try to find a way around it". My way around
> > the entry barrier is to explore indentational syntax. There may be other
> 
> Let's suppose your indentational syntax proves terrific, and beginners
> finally become comfortable with reading and writing Lisp code. Are
> parentheses the only--or main--difficulty of the language? What's next?
> What does it happen if you discover they have problems with higher order
> functions, macros, packages or other Lisp features? Do you change the
> syntax or semantics of the language?

Obviously, as you point out, the list of issues goes on. But the value I
see to Lisp is that it can support a variety of programming styles --
procedural, message passing, functional, and so a programmer can grow
with it as he or she matures as a developer.

The major strong point of my proposal (IMHO) is that it makes a minor
typographical change to the Lisp family language syntax, which might
have some major potential benefits. There obviously remain many
challenges to programming well. But why make it any harder than it has
to be? (Assuming of course indentational syntax turns out to really
work, and it may not.)

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

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
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <87d7jcna9m.fsf@piracy.red-bean.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> The reality is that programming is becoming more and more important to
> people's lives. People do learn to program -- the issue is more, if they
> don't choose Lisp, why not? And how can that be overcome?  Obviously,
> this issue may be much deeper than typography. Typography is just the
> only thing I can think to change with reasonable effort, while still
> preserving Lisp/Scheme's power and elegance.

You and a couple dozen other people, whose attempts now lie somewhere,
bitrotted, on the dead hardrives of history.

> The major strong point of my proposal (IMHO) is that it makes a
> minor typographical change to the Lisp family language syntax, which
> might have some major potential benefits.  There obviously remain
> many challenges to programming well. But why make it any harder than
> it has to be? (Assuming of course indentational syntax turns out to
> really work, and it may not.)

So far all of your examples have been quite simple.  Here is a test,
convert this real function from UncommonSQL.

(defmethod update-records-from-instance ((obj standard-db-object) &key
					 (database *default-database*))
  (labels ((slot-storedp (slot)
	     (and (member (view-class-slot-db-kind slot) '(:base :key))
		  (mop::slot-boundp obj (mop::slot-definition-name slot))))
	   (slot-value-list (slot)
	     (let ((value (slot-value obj (mop:slot-definition-name slot))))
	       (check-slot-type slot value)
	       (list (sql-expression :attribute (view-class-slot-column slot))
		     (db-value-from-slot slot value database)))))
    (let* ((view-class (class-of obj))
	   (view-class-table (view-table view-class))
	   (slots (remove-if-not #'slot-storedp (mop::class-slots view-class)))
	   (record-values (mapcar #'slot-value-list slots)))
      (if (not record-values)
	  (error "No settable slots."))
      (if (view-database obj)
	  (update-records :table (sql-expression :table view-class-table)
			  :av-pairs record-values
			  :where (key-qualifier-for-instance
				  obj
				  :database database)
			  :database (view-database obj))
	  (progn
	    (insert-records :into (sql-expression :table view-class-table)
			    :av-pairs record-values
			    :database database)
	    (setf (view-database obj) database)))
      t)))



-- 
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <3999C22B.AECF198C@kurtz-fernhout.com>
Craig-

Thanks for the interesting technical challenge.

Below is the translation of the code fragment you presented.

Rather than do this by hand, I translated it using a pretty printer 
I just wrote which converts S-expressions to indentationally 
significant notation. (It's definitely not as pretty as it could be.)
 
The code to do the pretty printing is presented, then the output.

To check that it works, also included is a reader I just wrote 
which reads one or more S-expressions in indentationally 
significant notation, prints them out (in parenthetical notation) 
and evaluates them.

Thus, between the two, one has the beginnings of a round trip process.

This code was written in DrScheme. So, it supports Scheme symbols, 
and thus two symbols in the complex test were converted by me to 
Scheme symbols. I don't think this would be an issue in a 
Common Lisp implementation. Naturally, the code example you provided
does not evaluate in DrScheme (since it is in Common Lisp)
after the reader reads it back in from indentational syntax.

I do not claim this code is complete. For example, it does not preserve 
comments. Also, the complexity management of the pretty printer is weak 
-- it really should allow part of the tail of an expression to fit 
on the same line as the head if the complexity of that part is low 
(even if the rest of the tail needs to be indented).

I do not claim that the code is correct either.
However it does handle the small test expressions I give it.
Consider it pre-alpha proof of concept quality (hot off the press).

I do not claim this code is that well written either. 
I most likely shows my inexperience with Scheme, Lisp, etc. 
For example, ideally, the parser should be a Scheme class. 
I left it as a few disconnected methods in part to make it easier 
to port to other dialects of Lisp. Also, the two stacks (subexpressions 
and promotion) could probably could be made one.

Aside from two of the examples, all the code is original.
I am releasing the code I wrote under an X/MIT style license (see below).

Note that I am including the code you contributed as a test example,
(presumably under "fair use" copyright guidelines) but if you want
it removed (for copyright or other reasons) in any future
distributions let me know.

Somebody with an open mind (and not afraid of the wrath of the other 
Lisp developers in this group :-), feel free to port this code to emacs. 
I'd love to hear the results, especially if the code is posted to this 
newsgroup (or elsewhere appropriate) under a similar open source license.
:-)

Please let me know if anyone finds obvious bugs (CC to private email 
is probably best as I may not be tracking this newsgroup).

Thanks again for taking the idea seriously enough 
to present an interesting technical challenge.

-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

========= open source license for the code I wrote below ================
Indentational S-expression parsing and printing routines
Copyright (c) 2000 Paul D. Fernhout

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

(Note, the two most complex examples were not written by me and may 
need to be covered by other licensing terms if not "fair use".)

=========== the example indentational pretty printer =================

; IndentWriter.scm
; Copyright 2000 Paul D. Fernhout
; X-MIT style license

;this particular test code was not written by me
; it was posted to comp.lang.lisp as a technical challenge by
; Craig Brozefsky <·····@red-bean.com> 13 Aug 2000 14:04:05 -0700

(define test1 
'(defmethod update-records-from-instance ((obj standard-db-object) &key
                                         (database *default-database*))
  (labels ((slot-storedp (slot)
             (and (member (view-class-slot-db-kind slot) '(:base :key))
                  (mop::slot-boundp obj (mop::slot-definition-name slot))))
           (slot-value-list (slot)
             (let ((value (slot-value obj (mop:slot-definition-name slot))))
               (check-slot-type slot value)
               (list (sql-expression :attribute (view-class-slot-column slot))
                     (db-value-from-slot slot value database)))))
    (let* ((view-class (class-of obj))
           (view-class-table (view-table view-class))
           ; sorry -- #'slot-storedp doesn't parse in DrScheme
           (slots (remove-if-not 'slot-storedp (mop::class-slots view-class))) 
           ; sorry -- #'slot-value-list doesn't parse in DrScheme
           (record-values (mapcar 'slot-value-list slots)))
      (if (not record-values)
          (error "No settable slots."))
      (if (view-database obj)
          (update-records :table (sql-expression :table view-class-table)
                          :av-pairs record-values
                          :where (key-qualifier-for-instance
                                  obj
                                  :database database)
                          :database (view-database obj))
          (progn
            (insert-records :into (sql-expression :table view-class-table)
                            :av-pairs record-values
                            :database database)
            (setf (view-database obj) database)))
      t)))
  )
  
; this code is from the DrScheme HelpDesk (example of a class definition)
; "Object Example" in "PLT MzScheme: Language Manual"
(define test2 
'(define stack% 
   (class* object% (stack<%>) ()
     (private 
       [stack null]) ; A private instance variable
     (public 
       [name 'stack] ; A public instance variable 
       [push! (lambda (v) 
                (set! stack (cons v stack)))] 
       [pop! (lambda () 
              (let ([v (car stack)]) 
                 (set! stack (cdr stack)) 
                  v))]
       [empty? (lambda () (null? stack))] 
       [print-name (lambda () 
                     (display name) (newline))])
    (sequence (super-init))))
)

(define test3 
  '(define 
     (square x) 
     (* x x)))

(define test4 
  '(define 
     (wierd x) 
     ((wierd-func 'hello) * x x)))

(define test5
  '(define 
     (foo x) 
     (let ((y 10) (z 20))
       (print (* x y z)))))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(define (print-indentation count)
  (cond 
    ((= count 0))
    (else 
     (write-char #\space) 
     ;(write-char #\space)
     (print-indentation (- count 1)))))

(define (simple-expression expression)
  (cond
    ((null? expression) #t)
    ((list? expression) #f)
    (else #t)))

(define (expression-complexity expression)
  (cond
    ((null? expression) 1)
    ((list? expression) 
     (+ 2
      (expression-complexity (car expression)) 
      (expression-complexity (cdr expression))))
    (else 1)))

;(expression-complexity '())
;(expression-complexity 'hello)
;(expression-complexity '(a b c))
;(expression-complexity '(a b (c d e f g)))
;(expression-complexity test-list)

(define (only-one-element expression)
  (if (list? expression) 
   (= 1 (length expression))
   #t))
      
;(only-one-element 'hello)
;(only-one-element "hello")
;(only-one-element '())
;(only-one-element '(x))
;(only-one-element '(a b))
;(only-one-element '(a b c))
;(only-one-element '((a b c)))

(define (print-simple-expression expression)
  ;(print "print simple expression")
  ;(print expression)
  (cond 
    ((null? expression) #f)
    ((list? expression)
     (begin
       (print (car expression))
       (write-char #\space)
       (print-simple-expression (cdr expression))))
     (else (print expression))))

(define (indent-print-tail tail level)
  (if (null? tail)
   #f
   (begin
     (indent-print (car tail) level)
     (indent-print-tail (cdr tail) level))))
   
(define allowable-head-complexity 23)
(define allowable-tail-complexity 23)

(define (indent-print expression level)
  ;(newline)
  ;(print "indent-print") 
  ;(newline)
  ;(print expression)
  ;(newline)
  ;(print (expression-complexity expression))
  ;(newline)
  (if (simple-expression expression)
    (begin
      (print-indentation level)
      (print expression)
      ;(print "<1>")
      (newline))
    (let* (
          (head (car expression)) 
          (tail (cdr expression))
          (simpleHead (>= allowable-head-complexity (expression-complexity head)) )
          (simpleTail (>= allowable-tail-complexity (expression-complexity tail)) )
          ) 
      ;(print head) 
      ;(newline)
      ;(print (expression-complexity head))
      ;(newline)
      ;(print tail)
      ;(newline)
      ;(print (expression-complexity tail))
      ;(newline)
      (if simpleHead
        (begin
          (print-indentation level)
          ;(print (list? head))
          (if 
;           (and (null? tail) (or (not (list? head)) (> 2 (length head)))) 
           (null? tail)
           (write-char #\())
          (print head)
          (if 
           (null? tail)
           (write-char #\)))
          ;(print "<0>")
          )
        (begin
          (print-indentation level)
          (write-char #\.)
          ;(print "<2>")
          (newline)
          (indent-print head (+ level 1))))
      (if (and simpleHead simpleTail)
        (begin
          (write-char #\space)
          ;(print "[3]")
          (print-simple-expression tail)
          ;(print "<3>")
          (newline))
        (begin
          ;(print "<4>")
          (if simpleHead (newline))
          (indent-print-tail tail (+ level 1)))))))
      
(indent-print test3 0)
(newline)
(indent-print test4 0)
(newline)
(indent-print test5 0)
(newline)
(indent-print test2 0)
(newline)
(indent-print test1 0)
(newline)

; note -- algorithm coudl be inproved by letting things be printed 
; on a line from tail and calculating increading complexity. 
; Only when complexity exceeds threshold would tail start wrapping.

============== the output of the algorithm =====================
[Note: #f is printed out by the Scheme system, not the pretty printer.]

Welcome to DrScheme, version 102.
Language: Graphical Full Scheme (MrEd).
define (square x) (* x x) 

define
 wierd x 
 (wierd-func 'hello) * x x 
#f

define
 foo x 
 let
  (y 10) (z 20) 
  print (* x y z) 
#f

define
 stack%
 class*
  object%
  (stack<%>) 
  ()
  private (stack null) 
  public
   name 'stack 
   push!
    lambda
     (v) 
     set! stack (cons v stack) 
   pop!
    lambda
     ()
     let
      ((v (car stack))) 
      set! stack (cdr stack) 
      v
   empty? (lambda () (null? stack)) 
   print-name
    lambda () (display name) (newline) 
  sequence (super-init) 
#f

defmethod
 update-records-from-instance
 (obj standard-db-object) &key (database *default-database*) 
 labels
  .
   slot-storedp
    (slot) 
    and
     member
      view-class-slot-db-kind slot 
      quote (:base :key) 
     mop::slot-boundp obj (mop::slot-definition-name slot) 
   slot-value-list
    (slot) 
    let
     ((value (slot-value obj (mop:slot-definition-name slot)))) 
     check-slot-type slot value 
     list
      sql-expression :attribute (view-class-slot-column slot) 
      db-value-from-slot slot value database 
  let*
   (view-class (class-of obj))
    view-class-table (view-table view-class) 
    slots
     remove-if-not 'slot-storedp (mop::class-slots view-class) 
    record-values (mapcar 'slot-value-list slots) 
   if (not record-values) (error "No settable slots.") 
   if
    view-database obj 
    update-records
     :table
     sql-expression :table view-class-table 
     :av-pairs
     record-values
     :where
     key-qualifier-for-instance obj :database database 
     :database
     view-database obj 
    progn
     insert-records
      :into
      sql-expression :table view-class-table 
      :av-pairs
      record-values
      :database
      database
     setf (view-database obj) database 
   t
#f

> 

========== the reader code ======================

;IndentReader.scm
; Copyright 2000 Paul D. Fernhout
; X-MIT style license

(require-library "functio.ss")
(require-library "string.ss")

(define (port-skip-leading-spaces-count port count)
  (cond 
    ((eof-object? (peek-char port)) count)
    ((eq? (peek-char port) #\space) (read-char port) (port-skip-leading-spaces-count port (+ 1 count)))
    (else count)))

(define (port-skip-leading-spaces port)
  (port-skip-leading-spaces-count port 0))

; return true if readable data on line
(define (port-skip-until-data-or-eol port)
  (let ((next-char (peek-char port)))
    ;(print next-char)
    (if (eof-object? next-char)
      #f
      (case next-char
        ((#\space) 
         (read-char port)
         (port-skip-until-data-or-eol port))
        ((#\tab) 
         (print "error -- tab in data! -- skipping")
         (read-char port) 
         (port-skip-until-data-or-eol port))
        ((#\return)
         ;(print "-- return --")
         ;(print (read-line port))
         (read-char port)
         #f)
        ((#\newline)
         ;(print "-- newline --")
         ;(print (read-line port))
         (read-char port)
         #f)
        ((#\;) 
         (read-line port)
         #f)
        (else #t)))))

(define indent-placeholder #\.)

(define (process-line-from-first-expression port indentation)
  (if (eq? (peek-char port) indent-placeholder)
    (begin
      ;for now, toss the rest of the line
      (read-line port)
      indent-placeholder)
    (let ((expression null))
      (do ((continue #t (port-skip-until-data-or-eol port)) (subexpression null))
        ((not continue) (read-line port))
        (set! subexpression (read port))
        ;(print subexpression) 
        ;(newline)
        (if (null? expression)
          (set! expression (cons subexpression null))
          (set! expression (append! expression (cons subexpression null)))))
      expression)))
  
(define (read-indented-expression port)
  (do 
    ((next-char (peek-char port) (peek-char port)) 
     (line-expression null) 
     (last-indentation -1)
     (subexpression null)
     (do-replace #f)
     (subexpression-stack (cons (cons 'start null) null))
     (promotion-stack (cons #f null))
     (would-need-promoting #f)
     (finished #f))
    ((or finished (eof-object? next-char)) (if (> (length subexpression-stack) 1)(cadar (last-pair subexpression-stack)) null))
    (let ((indentation (port-skip-leading-spaces port)))
      ;(begin (print next-char) (print indentation)(print " - ")(print last-indentation)(newline))
      (if (and (= 0 indentation) (> last-indentation -1))
        (set! finished #t)
        ;only do if the line is not otherwise just blank or comment
        (if (port-skip-until-data-or-eol port)
          (begin 
            (set! line-expression (process-line-from-first-expression port indentation))
            ;(begin (newline)(print "from line ->") (print line-expression) (newline))
            (begin
             ;(begin (print "subexpression stack way before -> ") (print subexpression-stack) (newline))
             ;(begin (print "promotion stack way before -> ") (print promotion-stack) (newline))
             (set! do-replace #f)
             (cond
               ((eq? line-expression indent-placeholder)
                 (set! subexpression null)
                 (set! would-need-promoting 'replace))
               ((= 1 (length line-expression)) 
                 (set! subexpression (car line-expression)) 
                 (set! would-need-promoting 'promote))
               (else 
                 (set! subexpression line-expression) 
                 (set! would-need-promoting #f)))
              ;(begin (print "subexpression ->") (print subexpression) (newline))
              ;manage the stacks as needed based on changing indentation
              (cond
               ((= indentation (+ 1 last-indentation))
                 ;(begin (write "+1") (newline))
                 ;handle case where because of new child, promote first object to list
                 (when (car promotion-stack)
                   ;(begin (print "subexpression stack before promotion -> ") (print subexpression-stack) (newline))
                   ;(begin (print "promotion stack before promotion -> ") (print promotion-stack) (newline))
                   ;(begin (print "promoting") (newline))
                   (set-car! subexpression-stack (list (car subexpression-stack)))
                   (if (eq? (car promotion-stack) 'replace)
                      (set! do-replace #t))
                   (set-car! promotion-stack #f)
                   (set-car! (last-pair (cadr subexpression-stack)) (car subexpression-stack))
                   ;(begin (print "subexpression stack after promotion -> ") (print subexpression-stack) (newline))
                   ;(begin (print "promotion stack after promotion -> ") (print promotion-stack) (newline))
                   ))
               ((= indentation last-indentation)
                 ;(begin (write "=") (newline))
                 ; pop one off stack
                 (set! subexpression-stack (cdr subexpression-stack))
                 (set! promotion-stack (cdr promotion-stack)))
               ((< indentation last-indentation)
                 ;(begin (write "<") (newline))
                 ; pop as many as needed off stack
                 (set! subexpression-stack (list-tail subexpression-stack (+ 1 (- last-indentation indentation))))
                 (set! promotion-stack (list-tail promotion-stack (+ 1 (- last-indentation indentation)))))
               ; should be terminal exception otherwise
               (else (print "error in indentation")))
             ; place the subexpression into the expression, inserted into the end of the current list
             ;(if (list? subexpression)
             ;(begin (print "subexpression stack just before append -> ") (print subexpression-stack) (newline))
             ;(begin (print "promotion stack just before append -> ") (print promotion-stack) (newline))
             ;handle special case for special character requiring replace
             (if do-replace
               (set-car! (last-pair (car subexpression-stack)) subexpression)
               (append! (car subexpression-stack) (cons subexpression null)))
             ; (append! (car subexpression-stack) subexpression))
             ; push new subexpression on stack
             ;(begin (print "subexpression stack just before set -> ") (print subexpression-stack) (newline))
             ;(begin (print "promotion stack just before set -> ") (print promotion-stack) (newline))
             (set! subexpression-stack (cons subexpression subexpression-stack))
             (set! promotion-stack (cons would-need-promoting promotion-stack)))
             ;(begin (print "subexpression stack after -> ") (print subexpression-stack) (newline))
             ;(begin (print "promotion stack after -> ") (print promotion-stack) (newline))
             (set! last-indentation indentation)))))))

(define (eval-indented-expressions port)
  (do 
    ((next-char (peek-char port) (peek-char port))) 
    ((eof-object? next-char))
    (let ((expression (read-indented-expression port)))
      (unless (null? expression)
        (newline)
        (print "expression -> ")
        (print expression)
        (newline)
        (print "eval -> ")
        (print (eval expression))
        (newline)))))

(define indented-port (open-input-file "C:/pdfscheme/indented.txt"))
(eval-indented-expressions indented-port)
(close-input-port indented-port)

; determine indentation for line
; read tokens, collecting until return or comment
; if token is special, recurse as if on new indented line
; recurse to handle children
; finish S-expression and return it

============ the sample output of reader =======================

[Note: I cut and paste the last output expression into 
the file "C:/PdfScheme/indent.txt", then ran the above code.
Note: I wrapped the expression by hand as it was one long line.
Note: if you wanted to evaluate the stack example, you need to include
the code "(define stack<%> (interface () push! pop! empty?))" at the 
top of your "C:/PdfScheme/indent.txt" file (or equivalent).]

Welcome to DrScheme, version 102.
Language: Graphical Full Scheme (MrEd).

"expression -> "(defmethod update-records-from-instance ((obj standard-db-object) 
&key (database *default-database*)) (labels ((slot-storedp (slot) 
(and (member (view-class-slot-db-kind slot) '(:base :key)) 
(mop::slot-boundp obj (mop::slot-definition-name slot)))) 
(slot-value-list (slot) (let ((value (slot-value obj 
(mop:slot-definition-name slot)))) (check-slot-type slot value) 
(list (sql-expression :attribute (view-class-slot-column slot)) 
(db-value-from-slot slot value database))))) 
(let* ((view-class (class-of obj)) (view-class-table (view-table view-class)) 
(slots (remove-if-not 'slot-storedp (mop::class-slots view-class))) 
(record-values (mapcar 'slot-value-list slots))) (if (not record-values) 
(error "No settable slots.")) (if (view-database obj) (update-records :table 
(sql-expression :table view-class-table) :av-pairs record-values :where 
(key-qualifier-for-instance obj :database database) :database (view-database obj)) 
(progn (insert-records :into (sql-expression :table view-class-table) 
:av-pairs record-values :database database) (setf (view-database obj) database))) 
t)))
"eval -> "
. reference to undefined identifier: defmethod
> 
[Note this last error comes from trying to eval Common Lisp code in DrScheme.]

==== the output expression after indenting by hand to match the original =====

(defmethod update-records-from-instance ((obj standard-db-object) &key 
                                         (database *default-database*)) 
   (labels ((slot-storedp (slot) 
              (and (member (view-class-slot-db-kind slot) '(:base :key)) 
                   (mop::slot-boundp obj (mop::slot-definition-name slot)))) 
            (slot-value-list (slot) 
              (let ((value (slot-value obj (mop:slot-definition-name slot)))) 
                (check-slot-type slot value) 
                (list (sql-expression :attribute (view-class-slot-column slot)) 
                      (db-value-from-slot slot value database))))) 
     (let* ((view-class (class-of obj)) 
            (view-class-table (view-table view-class)) 
            (slots (remove-if-not 'slot-storedp (mop::class-slots view-class))) 
            (record-values (mapcar 'slot-value-list slots))) 
       (if (not record-values) 
           (error "No settable slots.")) 
       (if (view-database obj) 
           (update-records :table (sql-expression :table view-class-table) 
                           :av-pairs record-values 
                           :where (key-qualifier-for-instance 
                                   obj :database database) 
                           :database (view-database obj)) 
           (progn 
            (insert-records :into (sql-expression :table view-class-table) 
                            :av-pairs record-values 
                            :database database) 
            (setf (view-database obj) database))) 
       t)))

==================== the challenge ===========================

Craig Brozefsky wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > The reality is that programming is becoming more and more important to
> > people's lives. People do learn to program -- the issue is more, if they
> > don't choose Lisp, why not? And how can that be overcome?  Obviously,
> > this issue may be much deeper than typography. Typography is just the
> > only thing I can think to change with reasonable effort, while still
> > preserving Lisp/Scheme's power and elegance.
> 
> You and a couple dozen other people, whose attempts now lie somewhere,
> bitrotted, on the dead hardrives of history.
> 
> > The major strong point of my proposal (IMHO) is that it makes a
> > minor typographical change to the Lisp family language syntax, which
> > might have some major potential benefits.  There obviously remain
> > many challenges to programming well. But why make it any harder than
> > it has to be? (Assuming of course indentational syntax turns out to
> > really work, and it may not.)
> 
> So far all of your examples have been quite simple.  Here is a test,
> convert this real function from UncommonSQL.
> 
> (defmethod update-records-from-instance ((obj standard-db-object) &key
>                                          (database *default-database*))
>   (labels ((slot-storedp (slot)
>              (and (member (view-class-slot-db-kind slot) '(:base :key))
>                   (mop::slot-boundp obj (mop::slot-definition-name slot))))
>            (slot-value-list (slot)
>              (let ((value (slot-value obj (mop:slot-definition-name slot))))
>                (check-slot-type slot value)
>                (list (sql-expression :attribute (view-class-slot-column slot))
>                      (db-value-from-slot slot value database)))))
>     (let* ((view-class (class-of obj))
>            (view-class-table (view-table view-class))
>            (slots (remove-if-not #'slot-storedp (mop::class-slots view-class)))
>            (record-values (mapcar #'slot-value-list slots)))
>       (if (not record-values)
>           (error "No settable slots."))
>       (if (view-database obj)
>           (update-records :table (sql-expression :table view-class-table)
>                           :av-pairs record-values
>                           :where (key-qualifier-for-instance
>                                   obj
>                                   :database database)
>                           :database (view-database obj))
>           (progn
>             (insert-records :into (sql-expression :table view-class-table)
>                             :av-pairs record-values
>                             :database database)
>             (setf (view-database obj) database)))
>       t)))
> 
> --
> Craig Brozefsky               <·····@red-bean.com>
> Lisp Web Dev List  http://www.red-bean.com/lispweb
> ---  The only good lisper is a coding lisper.  ---
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <877l9i5dml.fsf@piracy.red-bean.com>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Craig-
> 
> Thanks for the interesting technical challenge.

You should definetly have more than just one space for each indent
level, with a non fixed-with font the following is almost unreadable.
It also considerably increased the vertical size of the function,
which means it no longer fits on one page.  Telling when a symbol is
to be evalled for it's value or it's function is also a bitch.  Rather
than just looking to see if it has a ( in front of it.  In some cases
it's ambiguous.  To take an example from below:

if
  view-database

Is view-database being evaluated for it's function or its value here?
In other words is it: (if (view-database) ... or (if view-database.

In scheme it can be even more complex, because I can have something
like ((foo)), which calls the function that is the result of calling
the function foo.  How would I represent that? (foo) or ((foo)).  It's
quite ambiguous.  By making the parens optional, you are taking away
one of the most important cues for determine what a symbol is being
used for.

Perhaps a schmoe with an irrational hatred for parens would find this
easier, people do like perl afterall.  I however don't see it doing
anyting but making life MORE difficult for those trying to learn lisp
or scheme.

> defmethod
>  update-records-from-instance
>  (obj standard-db-object) &key (database *default-database*) 
>  labels
>   .
>    slot-storedp
>     (slot) 
>     and
>      member
>       view-class-slot-db-kind slot 
>       quote (:base :key) 
>      mop::slot-boundp obj (mop::slot-definition-name slot) 
>    slot-value-list
>     (slot) 
>     let
>      ((value (slot-value obj (mop:slot-definition-name slot)))) 
>      check-slot-type slot value 
>      list
>       sql-expression :attribute (view-class-slot-column slot) 
>       db-value-from-slot slot value database 
>   let*
>    (view-class (class-of obj))
>     view-class-table (view-table view-class) 
>     slots
>      remove-if-not 'slot-storedp (mop::class-slots view-class) 
>     record-values (mapcar 'slot-value-list slots) 
>    if (not record-values) (error "No settable slots.") 
>    if
>     view-database obj 
>     update-records
>      :table
>      sql-expression :table view-class-table 
>      :av-pairs
>      record-values
>      :where
>      key-qualifier-for-instance obj :database database 
>      :database
>      view-database obj 
>     progn
>      insert-records
>       :into
>       sql-expression :table view-class-table 
>       :av-pairs
>       record-values
>       :database
>       database
>      setf (view-database obj) database 
>    t
> #f

--
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <399A95A5.369952A0@kurtz-fernhout.com>
Craig-

Thanks for the reply.

I agree with you that compared to parentheses there can appear to be be
ambiguity when looking at a line by itself, because the rules require
one to look at an expression in its 2D context to understand it's
meaning. This reliance on spatial context is both a weakness and a
strength of the approach.

To address the ambiguity point you raised, the rules actually do (I
believe) specify with rigor the meaning of various expressions in
various 2D spatial contexts. 

The approach specifies that lines consisting of a single item by
themselves are taken as themselves. "Any single item" includes any
S-expression, including a parenthesized one with arbitrary levels of
nesting. Lines with more than one item are taken as lists. Lines with
any children beneath are also taken as a lists. 

So, I believe these rules handle all the situations you describe. One of
my reasons in posting this approach to comp.lang.lisp was to see if
anyone could point out a case where the rules did not cover it -- I
still have not seen an example I could not encode or read (with a
program) unambiguously.

=== examples =====

Note: None of these examples produces a well-formed "if" expression
(because they all lack an action to perform). They are illustrative
only. Also, I used two spaces in these examples, whereas I am currently
leaning towards one space.

************************

Example:

  if
    view-database

in this vase, "view-database" refers directly to the value of the
symbol.

This fragment is equivalent to

  (if view-database)

************************

Example:
 
  if
    (view-database)

An S-expression by itself on a line is taken as itself -- whether it is
a symbol, a string, another single item, or a parenthesized list. It
does not matter how many items are in an S-expression list or how deeply
it nests. This fragment is then equivalent to:

  (if (view-database))

************************

Example:

  if
    view-database my-database

in this case, more than one S-expresion is on the second line, and so
they are built into a list. Thus this "view-database" refers to the
first element of a list.

This fragment is equivalent to:

  (if (view-database my-database))

************************

Example:

  if
    (view-database my-database)

in this case, only one S-expression is on a line, and so none are not
built into lists. Thus this "view-database" still refers to the first
element of a list (and so probably is a function). Note this produces
the same thing as if the parens were ommitted in this case.

This fragment is thus also equivalent to:

  (if (view-database my-database))

************************

Example:
 
  if
    view-database
      my-database

Since "view-database" has a child, it is taken as the start of a list.
Thus, this fragment is also equivalent to:

  (if (view-database my-database))

************************

Example:
 
  if
    .
      view-database

A period on a line by itself indicates the start of a list. This
fragment is then equivalent to:

  (if (view-database))

************************

Example:

  if
    ((foo))

The second line is a single S-expression (even though it is nested) and
so this fragment is equivalent to:

  (if ((foo)))

************************

Example:

  if
    .
      (foo)

Based on the rules above for the period on a line by itself startign a
list, this fragment is also equivalent to:

  (if ((foo)))

************************

Example:

  if
    .
      .
        foo

Based on the rules for the period above applied recursively, this
fragment is also equivalent to:

  (if ((foo)))

************************

=== end examples =====

I chose "one space" for indentation for the moment based on deciding
that the burden of proof should be to show more than only one space is
needed after further experience with the minimal amount of space. Who
knows, "one space" might work in practice -- if it doesn't at least I
tried to push the edge of what was possible and will learn why it
doesn't work in practice. My current thinking is that if indentation is
of major importance to syntax, then one may not need a more extravagant
use of space perhaps required in other languages where people are not
being as careful in creating indentation or in perceiving it.

I understand your point that when using a proportional font with tiny
spaces the indentation might not display well. While I agree that
remains an issue in practice, to work around that, one can use a
different (fixed width) font, a proportional font with wide spaces,  or
use in theory a smart editor that shows spaces to the left of an
expression as being wider. Obvious other choices would be either two
spaces or an arbitrary amount of space per indentation (like Python
allows). Still, these approaches might suffer under a proportional font
in a standard editor. 

As Chris Page points out in other posts on this thread, in a deeper
sense, ultimately the ASCII (or whatever) textual representation of
S-expressions is in a way a transfer medium and ideally (although
difficult in practice) one should be working on representations of the
program structure (perhaps with overrideable formatting hints supplied
by the author for various representations). So in this sense, what I am
getting at by a choice of indentation characters (one space) is a way to
start using 2D to represent S-expression tree structure (and provide a
concise storage method). The ultimate appearance of such indented code
in the editor, as well as how one manipulates it, could involve the
developers's choice of presentation and editing systems. I understand
there are many formatting and style issues to deal with in practice as
one switches back and forth between visual presentations and practical
issues of how one interacts with these (whether using free form text
entry or a structured editor or a mix of both).

While it looks like there are a lot of rules when you think about each
one, in practice I think this convention is learnable and
understandable. Obviously, I am biased, so it remains to be seen what
others think when trying the system in practice (whether experienced
Lisp developers or not). Whether allowing indentational syntax makes it
easier for someone to learn to use Lisp or Scheme remains to be proven
or disproven in practice. However, even if it made it harder for someone
to learn Lisp or Scheme, but then easier for experienced people to
maintain code, the approach might still have some value. I am not saying
that is definitely the case -- I am just saying that there are many
factors on which one can evaluate a different approach than the status
quo. 

One of the elegant features of Lisp is the consistent and syntactically
minimalistic typographical convention using parens. Lisp and Scheme are
well worth learning despite and because of the consistent use of
parentheses. Complaining about parentheses is a typical Lisp/Scheme
"newbie" thing to do. And, it is the case that Lisp "newbies" rarely do
anything about it before the parentheses "disappear", I would guess in
part because to do so usually requires a command of Lisp that is near
the "disappearance level". (Plus a thick skin. :-) 

I am sorry to have written something that prompted so much negative
comments (near flameage in some cases) cluttering up this newsgroup
bandwidth. I should have worded things better to avoid discussion on the
approach's pros and cons outside of technical issues of implementation
or related work. I guess that was the cost to get a few well made
technical criticisms and challenges (like yours) and find out about
other related attempts. I did do dejanews and google searches before I
posted, but I didn't find anything exactly on this topic. Hopefully the
other comments people have made on related topics sparked from this also
were of some value.

Obviously, I've hit a nerve with this thread that prompted a lot of
initial negative reactions to the indentational approach for
representing S-expressions. However, that does not mean that on further
reflection over months and years and some experience trying a working
system, some people posting negative comments early on might not come to
see some practical value in this approach down the road. (I know, right
now everyone wants to say "never!") On the other hand, after I try it
for a while, maybe I myself will come to see it is of not much practical
value after all.

Note -- I'm not disagreeing with all the negative points people made
(many of which were excellent). I'm just pointing out that all the
potential drawbacks mentioned might not prove so big in practice
compared to the potential advantages. 
Your Mileage May Vary...

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

Craig Brozefsky wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > Craig-
> >
> > Thanks for the interesting technical challenge.
> 
> You should definetly have more than just one space for each indent
> level, with a non fixed-with font the following is almost unreadable.
> It also considerably increased the vertical size of the function,
> which means it no longer fits on one page.  Telling when a symbol is
> to be evalled for it's value or it's function is also a bitch.  Rather
> than just looking to see if it has a ( in front of it.  In some cases
> it's ambiguous.  To take an example from below:
> 
> if
>   view-database
> 
> Is view-database being evaluated for it's function or its value here?
> In other words is it: (if (view-database) ... or (if view-database.
> 
> In scheme it can be even more complex, because I can have something
> like ((foo)), which calls the function that is the result of calling
> the function foo.  How would I represent that? (foo) or ((foo)).  It's
> quite ambiguous.  By making the parens optional, you are taking away
> one of the most important cues for determine what a symbol is being
> used for.
> 
> Perhaps a schmoe with an irrational hatred for parens would find this
> easier, people do like perl afterall.  I however don't see it doing
> anyting but making life MORE difficult for those trying to learn lisp
> or scheme.
> 
> > defmethod
> >  update-records-from-instance
> >  (obj standard-db-object) &key (database *default-database*)
> >  labels
> >   .
> >    slot-storedp
> >     (slot)
> >     and
> >      member
> >       view-class-slot-db-kind slot
> >       quote (:base :key)
> >      mop::slot-boundp obj (mop::slot-definition-name slot)
> >    slot-value-list
> >     (slot)
> >     let
> >      ((value (slot-value obj (mop:slot-definition-name slot))))
> >      check-slot-type slot value
> >      list
> >       sql-expression :attribute (view-class-slot-column slot)
> >       db-value-from-slot slot value database
> >   let*
> >    (view-class (class-of obj))
> >     view-class-table (view-table view-class)
> >     slots
> >      remove-if-not 'slot-storedp (mop::class-slots view-class)
> >     record-values (mapcar 'slot-value-list slots)
> >    if (not record-values) (error "No settable slots.")
> >    if
> >     view-database obj
> >     update-records
> >      :table
> >      sql-expression :table view-class-table
> >      :av-pairs
> >      record-values
> >      :where
> >      key-qualifier-for-instance obj :database database
> >      :database
> >      view-database obj
> >     progn
> >      insert-records
> >       :into
> >       sql-expression :table view-class-table
> >       :av-pairs
> >       record-values
> >       :database
> >       database
> >      setf (view-database obj) database
> >    t
> > #f
> 
> --
> Craig Brozefsky               <·····@red-bean.com>
> Lisp Web Dev List  http://www.red-bean.com/lispweb
> ---  The only good lisper is a coding lisper.  ---
From: see.signature
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <slrn8plabh.138.anyone@Flex111.dNWL.WAU.NL>
Hi,


after reading a part of the discussion, the proposed form of the
parentheses less lisp reminds me of rebol. Have a look at www.rebol.com
and in DDJ jul 2000.  Rebol is a lot lisp like without parentheses. 

yours 
Marc

-- 
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <399AAD1B.B7C2E55D@kurtz-fernhout.com>
Marc-

Thanks for the pointer. 

I looked at a few Rebol scripts at:
  http://www.rebol.com/library/library.html

However, it looks at first glance like Rebol uses brackets to delimit
blocks. Although otherwise, the syntax does look Lisp-like (it appears
to use prefix notation for some commands). However, I haven't read the
language specification, so perhaps the brackets are optional in some
cases? I think I might have that DDJ issue lying around somewhere...

By the way, I've come across a language called "Ivy" that uses
indentational syntax (along with infix). It is a little cleaner than
Python's approach in some ways (for example "if" statements don't have a
required ":" as in Python).
  http://www.idiom.com/free-compilers/TOOL/IVY-1.html

Any more pointers to languages that use both "prefix notation" (similar
to Lisp) and "identational notation" would be appreciated.

-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

"see.signature" wrote:
> 
> Hi,
> 
> after reading a part of the discussion, the proposed form of the
> parentheses less lisp reminds me of rebol. Have a look at www.rebol.com
> and in DDJ jul 2000.  Rebol is a lot lisp like without parentheses.
> 
> yours
> Marc
> 
> --
> ------------------------------------------------------------------------------
> email: marc dot hoffmann at users dot whh dot wau dot nl
> ------------------------------------------------------------------------------
From: FM
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <slrn8pnkgs.u3.dankang@hinman-bp-117.dartmouth.edu>
Paul Fernhout <··········@kurtz-fernhout.com> wrote:

>So, I believe these rules handle all the situations you describe. One of
>my reasons in posting this approach to comp.lang.lisp was to see if
>anyone could point out a case where the rules did not cover it -- I
>still have not seen an example I could not encode or read (with a
>program) unambiguously.

How about

#1
a b
  c d
  e f

#2
(a b)
   (c d)
      e f
      g
      
#3
(a b)


A
((a b) ((c d) (e f)) (g))


I'm thinking

#1
(a b
   (c d)
   (e f))
   
#2
(a b) ((c d) (e f) g))

#3
((a b)) or (a b)

A
(a b)
   (c d)
      (e f)
   (g)


That's way way too irregular for me. Not only are some parentheses
required anyways, the fact that there are two ways to form a list
expression makes it much harder to read. If you're teaching this to
someone who has no grasp of the Lisp syntax, you have to teach how
to form S-expressions with parentheses, and then how to form
S-expressions with indentation.

Basically when there's a line,
add parentheses around the line unless:

the line has indented sub-expressions, in which case you add
an opening parenthesis where you'd normally have and add a
closing parenthesis at the end of the last indented sub-expression.

the line's an atom (or an already parenthesized list expression
in itself), in which case you do nothing.

I'd say that at least get rid of the rule where you assume a
line is a list expression unless it's an atom. That way, #1
becomes

a b
  (c d)
  (e f)

Without this change,

a b
  (c d)

and 

a b
  c d
  
are equivalent, whereas


a b
  (c d)
     e
     
and

a b
  c d
    e
    
aren't.

That is if my interpretation of your rules are correct. Let
me know if not.


Dan.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <399C4B3A.9164ACEB@kurtz-fernhout.com>
Dan-

Thanks for the concise statement of the rules! I think it is correct,
and describes how to convert from indentational to fully parenthesized
notation. 

The only other issue is that a "." starting a line by itself gets
replaced by an open paren which is closed later. This "." is a
placeholder used for starting a list of lists like in a "let". [A "." is
used in the current implementation for a subset of what I had proposed
for "..." originally -- it might change to another character.] 

For an example of using "." in indentational Scheme:

  define (times-ten x)
    let
      .
        y 10
      * x y
  

I was a little unclear on whether your examples (specifically based on
"#3" and "A") were intended to be in indentational syntax or regular
Lisp syntax. In the indentational approach as I now see it (and the
current implementation), everything inside of parens is read as if it
were conventional Lisp syntax (including ignoring whitespace).

So, #3 and A would be taken the same as in Lisp as they are fully
parenthesized. #1 would be as you outlined. #2 would be as you outlined
(with an additional leading paren for balance - a typo?).

Assuming #3 and A were encoding challenges, they would be:

  #3:  a b

and

  A: as you presented.

Your point about needing to know both forms of syntax (indentational and
fully parenthesized) is well made. I think this is quite true in
practice, because it is clear and more concise in many cases to have
short expressions like 
  "(lambda (x y) (< x y))" 
in line (even when everything is otherwise indentational). 

For example:

  define (foo unsorted-list)
    let
      .
      sorted-list (mysort unsorted-list (lambda (x y) (< x y)))
    for-in x sorted-list
      for-in y sorted-list
        print (* x y)
        display " "
      newline

Note: "for-in" is presently an unimplemented concept that would work
like the Python "for x in array:".

However, I would point out that in practice using this approach parens
that start on one line and end on another go away, and those are the
hardest parens to match by eye. So, I hope that if almost all parens
begin and end on the same line, the understanding and writing task might
be easier (even though I grant that a tool like emacs may make this a
non-issue for many).

In terms of teaching indentational Lisp or Scheme, one might start with
the fully indented version (and using "."), and then introduce parens as
a convenience. However, I don't know whether this would be better than
teaching the parenthesized version and then teaching indentational
rules.

Your last example is correct, and as you point out, that situation can
be confusing as the meaning of a line can change if children are added
-- if the item on that line is a single S-expression. So, the confusion
is even worse -- sometimes it happens, and sometimes it does not. I can
see how this might be a common cause of confusion. How common this
misunderstanding will be remains to be seen. Note however that it is
also easy to misread parenthetical nesting of complex expressions (like
a Scheme "do"), so the existing system isn't perfect in this regard
either.

While I too would like an interpretation based not on the number of
items on the list, I think (alternatives please?) it would in practice
require an operator to prevent something by itself being taken as a
list. That would impose additional complexity on the language and might
make it harder for current Lisp developers to read it (since it is no
longer just a matter of adding parens as appropriate -- one would have
to discard a certain other frequently occurring "deparen" operator).

[As a minor other issue, I am now trying out indentational syntax with
only one space, not two as in the original proposal, on the theory that
if indentation is significant, people will pay more attention to it and
one space may be good enough and may also prevent some misindentation
(by odd amounts). For the sake of continuity, I am primarily keeping
with two spaces in examples for this thread.]

Thanks again for the interesting comments and questions.

-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


FM wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> wrote:
> 
> >So, I believe these rules handle all the situations you describe. One of
> >my reasons in posting this approach to comp.lang.lisp was to see if
> >anyone could point out a case where the rules did not cover it -- I
> >still have not seen an example I could not encode or read (with a
> >program) unambiguously.
> 
> How about
> 
> #1
> a b
>   c d
>   e f
> 
> #2
> (a b)
>    (c d)
>       e f
>       g
> 
> #3
> (a b)
> 
> A
> ((a b) ((c d) (e f)) (g))
> 
> I'm thinking
> 
> #1
> (a b
>    (c d)
>    (e f))
> 
> #2
> (a b) ((c d) (e f) g))
> 
> #3
> ((a b)) or (a b)
> 
> A
> (a b)
>    (c d)
>       (e f)
>    (g)
> 
> That's way way too irregular for me. Not only are some parentheses
> required anyways, the fact that there are two ways to form a list
> expression makes it much harder to read. If you're teaching this to
> someone who has no grasp of the Lisp syntax, you have to teach how
> to form S-expressions with parentheses, and then how to form
> S-expressions with indentation.
> 
> Basically when there's a line,
> add parentheses around the line unless:
> 
> the line has indented sub-expressions, in which case you add
> an opening parenthesis where you'd normally have and add a
> closing parenthesis at the end of the last indented sub-expression.
> 
> the line's an atom (or an already parenthesized list expression
> in itself), in which case you do nothing.
> 
> I'd say that at least get rid of the rule where you assume a
> line is a list expression unless it's an atom. That way, #1
> becomes
> 
> a b
>   (c d)
>   (e f)
> 
> Without this change,
> 
> a b
>   (c d)
> 
> and
> 
> a b
>   c d
> 
> are equivalent, whereas
> 
> a b
>   (c d)
>      e
> 
> and
> 
> a b
>   c d
>     e
> 
> aren't.
> 
> That is if my interpretation of your rules are correct. Let
> me know if not.
> 
> Dan.
From: Arun Welch
Subject: Re: RFC: Lisp/Scheme with less parentheses (code!)
Date: 
Message-ID: <fTTm5.10505$Cc2.387817@newsread1.prod.itd.earthlink.net>
"Paul Fernhout" <··········@kurtz-fernhout.com> wrote in message
······················@kurtz-fernhout.com...
> The code to do the pretty printing is presented, then the output.
>  [...]
> To check that it works, also included is a reader I just wrote
> which reads one or more S-expressions in indentationally
> significant notation, prints them out (in parenthetical notation)
> and evaluates them.
> [...]
> I do not claim this code is complete. For example, it does not preserve
> comments. .  ---

I'm reminded of the challenges involved in moving code between Interlisp and
Common Lisp. Interlisp used * as a function (and yes, the returned value
could have implications) to denote comments, and a code-resident programming
environment. In other words,
 (* this is a comment)
as opposed to
;; this is a comment

The Interlisp reader didn't throw away comments on reading them. So, if you
read in a Common Lisp file via the standard reader, then all the comments
were thrown away in the editor. On the other hand, if you wrote a file using
the Interlisp writer, then all the comments were converted to
(* ;; this is a comment)
which made the files unusable in a CL world.

Bringing this back to the discussion at hand, you'll have to come up with
true translation devices that convert between your parenless and normal
Lisp. Which proves again that those who ignore history are doomed to repeat
it.

While you're at it, you might also see if you can dig up anything on the
Conversational Lisp  (clisp) stuff in Interlisp-D, which allowed one to
write code like
(for i from 1 to 10 print i by 2 unless i is 6)
which got appropriately expanded into the right thing.

...arun
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <3175267619940824@naggum.net>
* Paul Fernhout <··········@kurtz-fernhout.com>
| She is willing to consider learning Lisp and has in the past
| expressed interest in it.  In this particular case, I would be doing
| all of the development, but there is always the issue of maintenance
| down the road.  While her approval is a factor, there is still an
| issue for myself with my own aproval of the language (versus say
| Python or Smalltalk or C or Delphi which I have all used for other
| projects).

  Instead of thinking of your partner like "someone else", I would
  suggest you think of her as a part of yourself, in that when you
  explain something to her, you realize that the common ground between
  you is a foundation for understanding your _own_ thinking so much
  better.  This will (in my experience) mean that even if that other
  person never maintains or even understands the actual _code_, it has
  been developed within a framework of understanding that will benefit
  it over its entire lifetime.

  This has nothing to do with the syntax of the language, of course.

| I think we all bring our prejudices to the table, although ideally
| we rise above them as you point out.

  I think the best we can with our prejudices is to be aware of them.
  If you think you can rise above them, it will be impossible for you
  to understand which prejudices you haven't risen above.

| There are many other factors -- familiarity, prefix notation,
| functional style, availability of libraries, availability of
| support, availability on specific platforms, availability of
| programmers (network effect), whether it fits into the Microsoft
| vision (ugh!), and so on. (This isn't meant to slam any particular
| Lisp implementation, as obviously many of them are quite complete in
| terms of libraries and support.)

  The factor that throws programmers from other languages most is none
  of those things.  The lack of familiarity between languages that are
  accepted is quite stunning.  However, human beings are, despite
  every effort of the user interface crowd to reduce us to clicking
  idiots, a species marked by its use of _language_, which means that
  we are naturally predisposed to feel a sense of similarity not in
  how words are strung together, but how they have a common root,
  heritage, etymology.  Look at how Indo-European words crop up
  everywhere, and how the recent discussion of the "rete" evolved!

  Lisp has a _lot_ of words that are foreign to the C/Algol crowd, and
  the words we have in common don't generally mean the same due to a
  wide disparity of conceptual heritage.  Suppose a language with a
  lot of useful features, but based in, say, Norwegian, were to be
  marketed in the predominantly English-speaking programming world.
  It could use as many braces and semicolons it could stand, but it
  still would feel foreign.

| Still, I feel the parentheses are the single worst adoption hurdle
| in a causal review, and are sort of symbolic of the language's
| acceptance difficulties.

  (Causal?  Casual?)  The parentheses are a sort of lithmus test of
  people's intelligence.  (This will insult about 5.5 billion people.)
  How well do you tolerate that some of your basic presumptions are
  violated?  Suppose you were ridiculed for writing from left to
  right.  Suppose you were ridiculed for using letters describing each
  language's pronunciation instead of universal symbols for concepts,
  however they were pronounced.  Suppose you were ridiculed for eating
  with knives and forks?  Suppose you were ridiculed for books with
  the text of their spine upside down when you lay it face up on your
  desk?  If you are the kind of person who is able to put yourself in
  a position where you _understand_ that what you take for granted is
  somebody else's belly laugh, my guess is you possess sufficient
  intelligence to become a good programmer, or scientist, or do any
  other highly intellectual work for that matter.  If you _can't_, and
  you obsess about certain trivia (which nobody are going to _change_
  regardless of how trivial it appears), don't program computers.

  Some would say that syntax is irrelevant.  It obviously isn't.  It's
  as stupid as saying it's irrelevant which way you write, and then go
  from there to write books with neat spirals of text on every page.
  The _arbitrary_ is very far from _irrelevant_.  I would venture that
  the arbitrary is among the most important aspects of human existence.

  Being able to accept whatever is arbitrarily chosen in whatever
  culture you deal with does seem to be an ability in short supply,
  but that doesn't mean those who can do it are _inferior_.  It's the
  other way around: Those who can't should shut the fuck up.

| They also satisfice -- looking for a solution they think is "good
| enough", hence "worse is better".

  Worse is better is really not about selecting good enough, but about
  making lazy choices -- whatever seems least expensive at each point,
  often confused with "most convenient".  What "wins" might not even
  be good enough, but may be marketed so as to have a bright future.
  People can't think long-term by themselves (people still smoke, for
  instance), but if they are presented with something that will look
  good years from now, they'll buy it, hook, line, and sinker.

| The reality is that programming is becoming more and more important
| to people's lives.

  This is a many-faceted truth with so much ambiguity that it is best
  not to state it.  Try with one of the individual facets.  Do people
  have problems that cannot be solved by existing software?  If so,
  why not?  Are they helped by languages like Visual Basic and C++?

| People do learn to program -- the issue is more, if they don't
| choose Lisp, why not?

  Because Lisp would actually solve their problems, and then they
  would've wasted all that time learning to program in it, and they
  would have to figure out the answer to "now, what?".  I'm serious.
  Don't give people what they want -- they'll simply hate you for it.

| And how can that be overcome?  Obviously, this issue may be much
| deeper than typography. Typography is just the only thing I can
| think to change with reasonable effort, while still preserving
| Lisp/Scheme's power and elegance.

  Perhaps it's time to have a belly laugh over the notion that users
  should program at the very detailed level that real programming
  requires?  Suppose you want to convert a bunch of pictures into
  icons.  Suppose you know how to do that with one picture: You click
  on the file, "drag" it over to the icon-generating program, then
  "drop" it there.  Repeat until thoroughly disgusted with the idiocy
  of the paradigm of direct manipulation.  (It doesn't matter whether
  you can select several files before dropping, obviously.)  Suppose
  instead you were able to communicate your actual _desire_ to the
  computer, in (gasp!) a _language_!  Not a programming language, but
  a language suitable to express goals and such.

| The major strong point of my proposal (IMHO) is that it makes a minor
| typographical change to the Lisp family language syntax, which might
| have some major potential benefits.

  It amazes me that you still think it's a minor typographical change.

| There obviously remain many challenges to programming well.

  You know, I don't think catering to the parenthophobic will make any
  difference at all.  C++ is popular.  It has the worst syntax of any
  real programming language so far.  It is only eclipsed by Perl.
  Reading the manual of VCRs is hopelessly beyond their users' grasp,
  yet they sell in great numbers and are considered useful.

| But why make it any harder than it has to be?

  I actually think programming both as a carreer and as a science
  suffer so much because it has been made easier than it has to be.
  Fiddling with superficial syntax indicates that the problems of
  acceptance are not where they should be.

  I think we need to figure out what the real problems are.  As long
  as we find that people come to Lisp of their own accord, and as long
  as we have reasonable success with that approach, there is very
  little to argue that we're doing something wrong.  I also don't
  think we're doing anything wrong because whatever _is_ being done
  wrong is not related to _which_ language people use, but rather what
  they expect to do, and have to do, in whichever language they choose.

  I appreciate the many glimmers of light this discussion has
  uncovered, but I'm still quite annoyed by what I consider a huge
  waste of time in fixing what isn't broken to begin with, but we have
  a long history on this newsgroup to have valuable discussions come
  up only when someone proposes something that everybody thinks is a
  dead end at the outset and get all upset about.  Nothing happens
  with the dead-end stuff, but the discussions are usually fruitful.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Boris Schaefer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <87hf8oep2l.fsf@qiwi.uncommon-sense.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

| The major strong point of my proposal (IMHO) is that it makes a minor
| typographical change to the Lisp family language syntax, which might
| have some major potential benefits.

What major benefits would that be?

The only benefit I could imagine is that some more people who would
normally be scared off by something unusual (like a paren-heavy
syntax) might not get scared off.

I don't believe this.  I don't think that the parens are the reason
that Lisp isn't mainstream.  Instead I think the parens are simply the
easiest target to place the blame for Lisp not being mainstream,
because they are visually displeasing AND very noticeable to the
non-Lisper.

ALGOL-like syntax, for example, isn't really visually pleasing either,
but it's much harder to place blame for the ugliness on a single part,
and so most people just leave the syntax alone, because there is no
single feature that, if changed, would make the language more visually
pleasant.  If you change only one thing in an ALGOL-like syntax it
would usually merely be a VERY small change visually, so, people just
don't bother and get used to it.

In Lisp on the other hand, the syntax is so simple, it's prefix and
paren-delimited, and so people have two easy targets to place the
blame for whatever problem Lisp is supposed to have.  But as I said
before, I don't believe that perceived problems of Lisp are due to its
syntax.  The syntax is just blamed so frequently for perceived
problems, because it makes an easy target and because mainstream
languages all look like C and therefore different from Lisp.

-- 
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>

Unix will self-destruct in five seconds... 4... 3... 2... 1...
From: Paolo Amoroso
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant  indentation?
Date: 
Message-ID: <dbaXOUZ2ixyVfX9az9tlaz456cu6@4ax.com>
On Sun, 13 Aug 2000 00:42:51 -0400, Paul Fernhout
<··········@kurtz-fernhout.com> wrote:

> I actually find it ironic that probably most Lisp developers responding
> to this thread are in all likelihood using a mail reader that shows them
> the threaded discussion as a hierarchical tree. Thus, the very tool Lisp

Concerning the potential drawbacks of this kind of view see figures 1 and 2
in section 2 "Group Discussion" of the report:

  Internet Groupware for Scientific Collaboration
  http://software-carpentry.codesourcery.com/Groupware/report.html


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: thi
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <y16og2qmgy9.fsf@glug.org>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> I actually find it ironic that probably most Lisp developers responding
> to this thread are in all likelihood using a mail reader that shows them
> the threaded discussion as a hierarchical tree. Thus, the very tool Lisp
> developers are using to say indentation isn't good enough to present
> structure (without parens) is itself indentationally based and has no
> parens. Obviously this analogy has some limits. One doesn't usually
> rearrange mail items in the tree, so this point does not apply well to
> arguments related to the potential fragility of such structures. But I
> still think there is some truth to this point.

you really are grasping, aren't you?

why don't you get out of justification mode and into hacking mode?

more germaine: why don't you followup properly so that the threaded
newsreaders can do the right thing?  are you clueless or just in love
w/ your own spew?

thi
From: Coby Beck
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <CZnn5.26910$47.494617@news.bc.tac.net>
"thi" <···@glug.org> wrote in message ····················@glug.org...
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
>
> > I actually find it ironic that probably most Lisp developers responding
> > to this thread are in all likelihood using a mail reader that shows them
> > the threaded discussion as a hierarchical tree. Thus, the very tool Lisp
> > developers are using to say indentation isn't good enough to present
> > structure (without parens) is itself indentationally based and has no
> > parens. Obviously this analogy has some limits. One doesn't usually
> > rearrange mail items in the tree, so this point does not apply well to
> > arguments related to the potential fragility of such structures. But I
> > still think there is some truth to this point.
>
> you really are grasping, aren't you?
>
> why don't you get out of justification mode and into hacking mode?
>
> more germaine: why don't you followup properly so that the threaded
> newsreaders can do the right thing?  are you clueless or just in love
> w/ your own spew?
>
> thi

Thanks for being the first one in a very long thread about a potentially
volatile subject to respond with completely pointless hostility.

Coby
From: thi
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant  indentation?
Date: 
Message-ID: <y16pun5vz2s.fsf@glug.org>
"Coby Beck" <·····@mercury.bc.ca> writes:

> Thanks for being the first one in a very long thread about a potentially
> volatile subject to respond with completely pointless hostility.

i can only recognize (and love/hate) what i have in seen in myself.

thi
From: The Glauber
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <8mu73q$fe8$1@nnrp1.deja.com>
The use of indentation to convey syntax is interesting and may lead to
more readable code. The reason i don't use Python anymore and i hope
never to have to use this kind of language again is simple: even though
my indentation is always correct and perfect :-), my colleagues are not
as good as i am in choosing a system and sticking to it.

This is complicated by the existence of editors that use tabs for
indenting (like our old friend, vi), and people who will then change
the meaning of the tab to whatever is their favorite prime number that
day (3 spaces, 5 spaces, 7...).

If i have to work with some horribly indented piece of code written in
C or Java, i can usually fix it either by hand or using a tool. It
would be pretty exciting (in the bad way) if, by fixing the
indentation, i would be introducing subtle syntax changes too.

As for Lisp, the joy of Lisp is in the parens!

Anyway, just my .02

g

--
Glauber Ribeiro
··········@my-deja.com    http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"


Sent via Deja.com http://www.deja.com/
Before you buy.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <39936543.21DC2856@kurtz-fernhout.com>
Thanks for the interesting post. Some comments below.

The Glauber wrote:
> 
> The use of indentation to convey syntax is interesting and may lead to
> more readable code. 

Hooray! :-)

> The reason i don't use Python anymore and i hope
> never to have to use this kind of language again is simple: even though
> my indentation is always correct and perfect :-), my colleagues are not
> as good as i am in choosing a system and sticking to it.

Interesting point.

Actually, I remember one student in a C programming class I taught who
had a BASIC background. He strongly believed at first he didn't need to
indent anything, and I remember watching him struggle in a lab to get a
couple pages of unindented C to work...

You can lead a horse to water, but you can't make 'em drink.

That's actually one thing I like about a language like Occam that
enforces consistent indentation. It's also a reason many other people
despise a language like Occam -- saying it takes away their freedom,
whereas I think it creates freedom on another level.

> This is complicated by the existence of editors that use tabs for
> indenting (like our old friend, vi), and people who will then change
> the meaning of the tab to whatever is their favorite prime number that
> day (3 spaces, 5 spaces, 7...).

Yes, tabs can really mess up an indentational system.
 
Python does struggle with this somewhat.

In practice I think this can be worked out, but it is annoying.

> If i have to work with some horribly indented piece of code written in
> C or Java, i can usually fix it either by hand or using a tool. It
> would be pretty exciting (in the bad way) if, by fixing the
> indentation, i would be introducing subtle syntax changes too.

It's been my experience that horribly indented code usually has other
horrible problems associated with it. That's not much comfort when you
have to work with a specific piece of code in a specific setting, but it
can be a rule of thumb for avoiding some problems if you get to choose
the code you work with.

It is true one can introduce bugs by messing up indentation, but I think
they are not likely to be "subtle" because one can see the program
structure by inspection. Obviously if we are talking about changing the
nesting of some delicate "if" statements, then that is a greater point
of failure, and the errors are more likely to be subtle. Still, there
are lots of subtle errors unusual indentation can hide in a language
with block delimiters -- be they parens, begin/end, braces, or whatever
else.
In practice, in a language with syntactically significant indentation,
it might be less likely one would ever need to fix up someone else's
indentation.

Ultimately, in any programming endeavor, there are areas where people
have to exercise caution. Obviously, for most programmers today,
whitespace has rarely been one of them.

> As for Lisp, the joy of Lisp is in the parens!

They certainly are elegant and consistent.
 
> Anyway, just my .02
> 
> g
> 
> --
> Glauber Ribeiro
> ··········@my-deja.com    http://www.myvehiclehistoryreport.com
> "Opinions stated are my own and not representative of Experian"
> 

Thanks 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
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <m31yzwvb9z.fsf@cadet.dsl.speakeasy.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> > As for Lisp, the joy of Lisp is in the parens!
> 
> They certainly are elegant and consistent.

I think Paul is being too genial here.  I think that the Joy of Lisp
comment was kinda silly.  Sometimes you have to be cruel to be kind.
For example:

> > The reason i don't use Python anymore and i hope
> > never to have to use this kind of language again is simple: even though
> > my indentation is always correct and perfect :-), my colleagues are not
> > as good as i am in choosing a system and sticking to it.
> 
> Interesting point.

C'mon now.  This "point" makes no sense at all.  So you had to abandon
Python not because it wasn't good enough for the task, or because you
didn't like it, but because your colleagues couldn't keep up with you?
Please don't tell me you switched [back] to Common Lisp.  I would
hardly believe it.  I also don't see what "this kind of language" is
referring to (i.e. what language feature?).  If it is the indentation
thing, then what are you talking about when you say "choosing a
system"?  Are you colleagues unable to figure out when to press the
<ENTER> key in Emacs?  I'm trying to understand this, being that most
software development problems are so much harder than what your
colleagues were supposedly having difficulty with.  Were you guys
writing "hello world" in different tongues?
From: The Glauber
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <8n10aj$id7$1@nnrp1.deja.com>
In article <··············@cadet.dsl.speakeasy.net>,
  David Bakhash <·····@alum.mit.edu> wrote:
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
>
> > > As for Lisp, the joy of Lisp is in the parens!
> >
> > They certainly are elegant and consistent.
>
> I think Paul is being too genial here.  I think that the Joy of Lisp
> comment was kinda silly.  Sometimes you have to be cruel to be kind.
> For example:

Yes, that was a silly joke (5 points for you for figuring that out).
Good, you can still read English and understand more than one level of
meaning. Try not to lose this ability, as it may turn out to be useful
someday.

[...]

> C'mon now.  This "point" makes no sense at all.  So you had to abandon
> Python not because it wasn't good enough for the task, or because you
> didn't like it, but because your colleagues couldn't keep up with you?
> Please don't tell me you switched [back] to Common Lisp.  I would
> hardly believe it.  I also don't see what "this kind of language" is
> referring to (i.e. what language feature?).  If it is the indentation
> thing, then what are you talking about when you say "choosing a
> system"?  Are you colleagues unable to figure out when to press the
> <ENTER> key in Emacs?  I'm trying to understand this, being that most
> software development problems are so much harder than what your
> colleagues were supposedly having difficulty with.  Were you guys
> writing "hello world" in different tongues?


You have a great gig if you work at MIT. In most of the world outside,
people work alongside programmers who got most of their usable
knowledge out of a "learn Java in 3 days" book. I'm not going to go
into a flame war with you on this.

I think about this issue sometimes. A lot of people are quick to bash
Cobol because it's too structured, but structure does help when you
have to work in a team with people of diverse backgrounds and skill
levels. Thinking of it, the problem with indentation in Python is that
it's too free. If they had defined indentation to be always 4 spaces
(and no tabs allowed), it would work much better.

I suspect the parens in Lisp are there mostly to make life easier for
the compiler, but they implement a structure that's simple enough that
anyone can write their own parser and/or pretty-printer. To do that in
most modern languages requires some sort of BNF processor. To do it in
Python requires a small dose of wishful thinking.

I.M.H.O.

glauber

--
Glauber Ribeiro
··········@my-deja.com    http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"


Sent via Deja.com http://www.deja.com/
Before you buy.
From: The Glauber
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <8n95rh$3vf$1@nnrp1.deja.com>
I'm just going to restate what i tried to state before, when
some communication was lost due to my use of irony
which was interpreted as arrogance.

IMHO, the main problem with Python's use of indentation to convey
syntax is that it doesn't at the same time enforce what kind
of indentation to use (even allowing for multiple incompatible
indentation methods in the same program). This problem is
compounded by the use of TABs to replace a certain (often
variable) number of spaces by certain text editors (including vi),
which sometimes leads to files having a confusing mix
of spaces and TABs.

Lisp is blessed with a deterministic syntax mechanism (parens),
and IMHO, replacing it with a non-deterministic mechanism
such as Python's, would be a disservice.

Having said this, i should add that it may be possible
to make indentation syntax deterministic by defining precisely
how to indent.

That's it. No humour and no irony above. I'm sorry that i allowed
myself to be offended and even posted a lame attempt
at self-defense. I'll try not to do it again.

glauber


Sent via Deja.com http://www.deja.com/
Before you buy.
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant indentation?
Date: 
Message-ID: <39962F95.6D67A6CB@kurtz-fernhout.com>
David-

Thanks for the reply. Some comments below.

David Bakhash wrote:
> 
> Paul Fernhout <··········@kurtz-fernhout.com> writes:
> 
> > > As for Lisp, the joy of Lisp is in the parens!
> >
> > They certainly are elegant and consistent.
> 
> I think Paul is being too genial here.  I think that the Joy of Lisp
> comment was kinda silly.

Actually, I did like it.  My thinking was: Lisp is elegant and powerful
because of S-expressions. S-expressions are defined typographically
using parens. Thus parens are the joy of Lisp. Guess I missed Glauber's
5 point joke!

> Sometimes you have to be cruel to be kind.

True. But one can be polite at the same time too.

Actually, I'm really mostly just a guest here...
(Maybe I've just contracted too much, too!)

> For example:
> 
> > > The reason i don't use Python anymore and i hope
> > > never to have to use this kind of language again is simple: even though
> > > my indentation is always correct and perfect :-), my colleagues are not
> > > as good as i am in choosing a system and sticking to it.
> >
> > Interesting point.
> 
> C'mon now.  This "point" makes no sense at all.  So you had to abandon
> Python not because it wasn't good enough for the task, or because you
> didn't like it, but because your colleagues couldn't keep up with you?
> Please don't tell me you switched [back] to Common Lisp.  I would
> hardly believe it.  I also don't see what "this kind of language" is
> referring to (i.e. what language feature?).  If it is the indentation
> thing, then what are you talking about when you say "choosing a
> system"?  Are you colleagues unable to figure out when to press the
> <ENTER> key in Emacs?  I'm trying to understand this, being that most
> software development problems are so much harder than what your
> colleagues were supposedly having difficulty with.  Were you guys
> writing "hello world" in different tongues?

As Glauber points out in his reply to your post, this actually is a big
problem in practice preventing the adoption of advanced technologies. It
is sort of a "network effect". In a big company, a manager has to judge
if the value of a few productive people if more than than the value of a
large network of less productive people. This decision is only made
harder by the fact that programmer productivity can vary by almost two
orders of magnitude (or more when a good programmer just points out not
to do something silly and to do something sensible instead -- at the
application design level or requirements level) and also that some
programmers even have a net negative contribution to an effort.
(Frederick Brooks book "The Mythical Man Month" goes into this in some
detail.)
  http://slashdot.org/books/980805/1148235.shtml

Luckily, we're a two programmer shop, so if we can find a tool that
gives us an "edge", we have some hope of going with it.

It was in working with the language Forth that I first encountered the
saying (by Chuck Moore I believe?) that most computer languages are
levelers (all programmers produce about the same medium level), but
Forth was an "amplifier" (a bad Forth programmer was a disaster, a great
Forth programmer a god.) 

Realistically, management wants predictable languages that are
"levelers" (like Visual Basic) because generally the cost of
person-years for software development (in a typical large company doing
mostly in-house work) is a small part of the total costs of the
operation and marketing for the related services. Thus management often
thinks they can afford to be "wasteful" to ensure predictable linear
programming success. 

Good programmers on the other hand, often want amplifiers... They also
know what management often doesn't want to know -- that complexity grows
and grows and grows, even if you add to it in only "leveled" pieces. The
leveler tools often can't handle more than a modicum of complexity,
because their underlying data and programming models are sophisticated
enough. As application size grows, it goes through chaotic phase changes
to new levels of complexity, where new approaches must be rapidly put in
place.  (There is a book on this topic but I can't remember the title.) 

Obviously the value to Lisp family languages is that they are good at
handling complex tasks, which in the end is what many business and other
tasks become given enough time.

Nonetheless, maybe within the Lisp family languages, syntactically
significant indentation could be an amplifier, and parentheses could be
a leveler?  <Ducks...> (But sometimes you have to be cruel to be kind.)
:-)

-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
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like     significant indentation?
Date: 
Message-ID: <m3bsyxvhm7.fsf@cadet.dsl.speakeasy.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Nonetheless, maybe within the Lisp family languages, syntactically
> significant indentation could be an amplifier, and parentheses could
> be a leveler?  <Ducks...> (But sometimes you have to be cruel to be
> kind.)

I don't buy this amplifier/leveler idea.  To me, amplifiers are kinda
like using well-defined, stable libraries, like what Perl and Java
give you, and taking advantage of code reuse.  I'd say C++, except
that its heinosity counterbalances its productivity.  CL doesn't have
a lot of the things that would make people flock to it.  Also, its
relatively large learning curve and general differences from almost
all mainstream langauges would certainly not make it a good language
to just grab off the shelf and start writing stuff in (e.g. scripting;
Perl, on the other hand, is often just grabbed, used, and with
relative ease).  Perl is an amplifier as a language.  But you are
talking more about language "features", not whole languages.  So in
that case, there's a third thing: an obstacle (or call it an
attenuator, counter-productivity tool, whatever).
Indentation-dependence would fall under this category, at least for
Common Lisp.  As you implied above, it's hard to decouple the feature
from the language when you're assessing the effect.  In this case,
(i.e. CL and indentation-dependence plus removal of parens) has been
rejected with good reason.  If done, it will just be another little
modification to the syntax not unlike the many that have been made,
and it will be discussed one day, in a decade or so, when someone
refers back to this incident, and the proposal, or even someone's
implementation of it, elisp code, etc.

I must admit that this whole thread really injected some kind of fear
in me.  I don't know what it is, or why, but a strong division in the
CL community about the structure of Lisp code, and then the possible
transgression into this aweful indentation-dependence, would just hurt
the Lisp community.  It has nothing to do with amplifiers, levelers,
or any other analogies.  It's just wrong.  But in my offense at the
idea, I did not indent to even imply any disdain toward anyone.  Just
wanted to defend the status quo and see meaningful posts coming from
both sides of the argument.  I did intend to express some contempt for
what seemed to be a pompous statement, but I did reconsider it, based
on the reply, and from your post as well, and appreciate your
feedback.

dave
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like      significant indentation?
Date: 
Message-ID: <3996C160.9DD533A4@kurtz-fernhout.com>
David-

I have very much appreciated your comments. You have obviously given the
idea additional reflection (mentioning for example in another post a
conversation about it and that printing in such a way might potentially
be worth trying) and I appreciate your open mindedness and willingness
to participate in a discussion on it.

I also appreciate all the newsgroup conversation on it, whatever the
Lisp community consensus in the end (currently overwhelmingly negative,
as you point out). I did try to look up related discussions, but there
is so much out there on indentation and structure in Lisp unrelated
directly to syntactically significant indentation that in the end I
thought it easiest to have a conversation on it. Thanks to everyone for
participating in that. 

At this point, I'm hoping things wind down on this thread so I can try
implementing something (just to see what it would be like, objections
noted). Maybe indentational Lisp will just end up as my company's
"secret weapon". :-) On the other hand, maybe it will just be a waste of
time. :-(

Regarding levelers, good point on counterbalancing forces within the
same language. I also realize from your comments that the same language
might even be either a leveler or amplifier depending on the context of
it's used -- especially considering library support (one of Scheme's
weaknesses, for example).

Your point about "fear" is well put. That was what occurred to me in
terms of the tone of several people's responses (beyond the technical
side of the discussion). I think it reflects (IMHO) that Lisp
programmers are to an extent the underdog, often having to justify their
choice to managers or prospective employers against things like the
steamroller of C/C++ (and now Java), and face endless comments from
clueless people about the apparent ugliness of parens (when an
experienced Lisp developer sees only beauty and elegance in the parens).
Anything that threatens the unity and mutual support Lisp programmers
currently have is going to be seen as a bad thing, and with good reason.
Since indentational syntax might be perceived to threaten to fracture
the community, splitting it perhaps someday into two camps, that is one
more drawback to the approach. 

Further, since Lisp obviously works so well now, statistically speaking,
it its most likely any "mutation" will just make things worse -- and
obviously no Lisp developer wants to be stuck with a dysfunctional but
more "popualr" version of Lisp approved by management that just looks
pretty (but is a mess conceptually behind the scenes, like numerous
popular languages I could name). "Worse is better" is a painful
statement about the reality of so much in the computer world.

Still, I think all this is a tradeoff. In the best possible case, if
something like an indentational syntax could increase the number of
people (especially managers) willing to try Lisp family languages, and
the total number of interesting Lisp-related job opportunities say went
up by a factor of ten, and it wasn't that bad to program in (and maybe
had a few advantages), then even if there were two camps (half fully
parenthesized, half indentational), each might be a lot larger and
better off. And as I joked on another mailing list, maybe the smoke from
the indentational vs. parenthetical flame wars would attract even more
curious new recruits from other newsgroups. :-) 

Can I guarantee that any of this would happen, instead of just
fracturing the community that already exists without growing it at all?
No, I can't. This indentational approach is still vaporware, and has yet
to be proven in the heat of development, unlike the current fully
parenthesized Lisp notation and its accompanying suite of
high-performance tools (like emacs).

-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 <··········@kurtz-fernhout.com> writes:
> 
> > Nonetheless, maybe within the Lisp family languages, syntactically
> > significant indentation could be an amplifier, and parentheses could
> > be a leveler?  <Ducks...> (But sometimes you have to be cruel to be
> > kind.)
> 
> I don't buy this amplifier/leveler idea.  To me, amplifiers are kinda
> like using well-defined, stable libraries, like what Perl and Java
> give you, and taking advantage of code reuse.  I'd say C++, except
> that its heinosity counterbalances its productivity.  CL doesn't have
> a lot of the things that would make people flock to it.  Also, its
> relatively large learning curve and general differences from almost
> all mainstream langauges would certainly not make it a good language
> to just grab off the shelf and start writing stuff in (e.g. scripting;
> Perl, on the other hand, is often just grabbed, used, and with
> relative ease).  Perl is an amplifier as a language.  But you are
> talking more about language "features", not whole languages.  So in
> that case, there's a third thing: an obstacle (or call it an
> attenuator, counter-productivity tool, whatever).
> Indentation-dependence would fall under this category, at least for
> Common Lisp.  As you implied above, it's hard to decouple the feature
> from the language when you're assessing the effect.  In this case,
> (i.e. CL and indentation-dependence plus removal of parens) has been
> rejected with good reason.  If done, it will just be another little
> modification to the syntax not unlike the many that have been made,
> and it will be discussed one day, in a decade or so, when someone
> refers back to this incident, and the proposal, or even someone's
> implementation of it, elisp code, etc.
> 
> I must admit that this whole thread really injected some kind of fear
> in me.  I don't know what it is, or why, but a strong division in the
> CL community about the structure of Lisp code, and then the possible
> transgression into this aweful indentation-dependence, would just hurt
> the Lisp community.  It has nothing to do with amplifiers, levelers,
> or any other analogies.  It's just wrong.  But in my offense at the
> idea, I did not indent to even imply any disdain toward anyone.  Just
> wanted to defend the status quo and see meaningful posts coming from
> both sides of the argument.  I did intend to express some contempt for
> what seemed to be a pompous statement, but I did reconsider it, based
> on the reply, and from your post as well, and appreciate your
> feedback.
> 
> dave
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like       significant indentation?
Date: 
Message-ID: <m38zu1uu5u.fsf@cadet.dsl.speakeasy.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Still, I think all this is a tradeoff. In the best possible case, if
> something like an indentational syntax could increase the number of
> people (especially managers) willing to try Lisp family languages,
> and the total number of interesting Lisp-related job opportunities
> say went up by a factor of ten, and it wasn't that bad to program in
> (and maybe had a few advantages), then even if there were two camps
> (half fully parenthesized, half indentational), each might be a lot
> larger and better off.

yes, but you must remember that to non-CL programmers, the "Lisp
family" is one big happy family of _very_ similar languages.  To many
dedicated Lisp programmers, their preferred dialect is _everything_.
I am not a Lisp advocate; I am a Common Lisp advocate.  I'll take Perl
over Scheme any day.  That's how I know that it's more than the parens
that make me like CL.  In fact, there are so many things about CL that
are the reason I enjoy programming in it that are completely missing
from some of its cousins.  If there's a job out there that's _not_ in
Common Lisp, then I'd much rather it be in Java, so at least I have a
shot at doing it.  I don't think I'd enjoy using Scheme for any real
task.

> And as I joked on another mailing list, maybe the smoke from the
> indentational vs. parenthetical flame wars would attract even more
> curious new recruits from other newsgroups. :-)

I hardly think this is a way to attract people to Common Lisp.
Anyway, in case you care, it simply _won't_ work.  And if it does
"kinda" work, it won't be in the best interest of Common Lisp.
Because it will attract people for all the wrong reasons.  What I want 
to see is an increase in the acceptance of Common Lisp among project
managers.  That means more jobs, more options, more code, more
discussion, and eventually this new demand in the RIA [1] world will
concentrate new attention to Common Lisp among people who care more
about solving problems than the latest "worse is better" fad.

Everyone out there who programs pretty much knows that to do anything
really useful and interesting is a massive undertaking.  They want
anything that will simplify the means to this end.  The way people
are, they'll explore every possibility over time, and in the end
they'll converge to something that actually works.  Common Lisp is by
no means perfect, but it is the closest thing out there that I'm aware 
of, and so I'm sticking with it, and I'm personally going to resist
anything other than what I believe is going to make it better.  A good 
language for experimentation, that's also probably more suitable for
your experiment, is Scheme, and that's probably where you should
implement it.  I'd be interested to see the results.  Please note that 
in the process of doing it, try to modify the reader so that
experimenting with different whitespace/indentation rules is easy.

dave

-----------

[1] RIA stands for Really Important Application, and if you don't
    recall the reference, it's from a post earlier this year from this
    newsgroup that's worthwhile reading, and will shed light on why
    RUA-driven developers might care about the indentation features.
From: Hartmann Schaffer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3994af61@news.sentex.net>
In article <·················@kurtz-fernhout.com>,
	Paul Fernhout <··········@kurtz-fernhout.com> writes:
> ...
> It is true one can introduce bugs by messing up indentation, but I think
> they are not likely to be "subtle" because one can see the program
> structure by inspection. Obviously if we are talking about changing the

i am pretty sure you are wrong here:  just try to put the wrong
indentation on the last statement of an else.  it is completely
unobvious by the display of the program structure that that statemen
is in the wrong place.  if tha language syntax insistes on full use of 
delimiters (which shouldn't prevent you from using proper
indentation), you have some redundency that lets you compare the
displayed program structure with the code yo have written.

> ...

-- 

Hartmann Schaffer
From: Hartmann Schaffer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3994b06b@news.sentex.net>
In article <·················@kurtz-fernhout.com>,
	Paul Fernhout <··········@kurtz-fernhout.com> writes:
> ...
> structure by inspection. Obviously if we are talking about changing the
> nesting of some delicate "if" statements, then that is a greater point
> of failure, and the errors are more likely to be subtle. Still, there
> are lots of subtle errors unusual indentation can hide in a language
> with block delimiters -- be they parens, begin/end, braces, or whatever
> else.

sorry, i should have read a little bit further before replying to the
one point ...  

> In practice, in a language with syntactically significant indentation,
> it might be less likely one would ever need to fix up someone else's
> indentation.

well, most languages have pretty printers or source code formatters,
so you get this effect without human effort.

>...

-- 

Hartmann Schaffer
From: Russell Wallace
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  indentation?
Date: 
Message-ID: <3992BDA2.7176@esatclear.ie>
Paul Fernhout wrote:
> I'm interested in using significant indentation (like in Python)
>   http://www.python.org
> to replace many parentheses in Lisp or Scheme programs.

Interesting idea!  I'm afraid my response is going to be negative, but
thanks for posting the idea anyway, it's certainly sparked some
discussion and helped me clarify some thoughts.

I don't see any big practical problems with the proposal, but I must
admit I'm still not fond of it.

> While some people can't get past significant indentation in Python
> (citing for example occasional difficulty cutting and pasting code from
> newsgroup posting or mail sent with old mail clients) and stick with
> Perl, etc., the ones who do get past the unfamiliarity with
> indentational syntax almost uniformly like it and say it is a feature
> that aids program readability.

Maybe.  If that's a rule, then I'm an exception to it.

I've found no practical problems whatsoever with Python's
indentation-based syntax.  (I indent C the same way, after all, even
though the language doesn't require it.)  Nonetheless, it still makes me
feel a bit queasy.  The best analogy I can think of is drinking milk
that hasn't _quite_ gone off yet.  You have to admit there isn't any
practical problem with drinking the stuff, but nothing will ever
convince you it wouldn't be better if it was perfectly fresh.

For me, the issue isn't one of practice, but of aesthetics, and no
practical argument will ever convince me to like indentation-based
syntax.  (If typing brackets was a lot of work it might be different,
but it's not.)  Now I use Python happily enough anyway (it helps that I
use it for scripting/prototyping stuff where the emphasis is more on
"get the job done quickly" than on "build to last"), but I'd be even
happier if that aspect of it were different.

And I suspect that for most people who dislike indentation-based syntax,
their real reason is aesthetic also.

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

People do say that, and they talk about prefix versus infix.  But I
don't think those are the real issues.  I've switched from Scheme to
Python for AI/prototyping work for reasons of syntax, but it's not a
question of the number of brackets required, or of putting the + sign
before the operands rather than between them, and I think that's true
for most Lisp-avoiders.  So I don't think your proposal would actually
help.

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  	 indentation?
Date: 
Message-ID: <m3n1ilusae.fsf@cadet.dsl.speakeasy.net>
Russell Wallace <········@esatclear.ie> writes:

> I've switched from Scheme to Python for AI/prototyping work for
> reasons of syntax, but it's not a question of the number of brackets
> required, or of putting the + sign before the operands rather than
> between them, and I think that's true for most Lisp-avoiders.  So I
> don't think your proposal would actually help.

You are not the first AI person I've heard of moving from some Lisp to
Python.  I'd be first inclined to wonder why you didn't convert to CL
instead.  But, guessing that you considered, and probably tried CL,
can you elaborate on why Python over Scheme, or (better) of CL?  It's
about time I asked.  I looked over Python, though didn't dive into
it.  I hated it right away, at least for AI-related applications.

thanks,
dave
From: Russell Wallace
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  	 indentation?
Date: 
Message-ID: <39938F37.7CFF@esatclear.ie>
David Bakhash wrote:
> 
> Russell Wallace <········@esatclear.ie> writes:
> 
> > I've switched from Scheme to Python for AI/prototyping work for
> > reasons of syntax, but it's not a question of the number of brackets
> > required, or of putting the + sign before the operands rather than
> > between them, and I think that's true for most Lisp-avoiders.  So I
> > don't think your proposal would actually help.
> 
> You are not the first AI person I've heard of moving from some Lisp to
> Python.  I'd be first inclined to wonder why you didn't convert to CL
> instead.  But, guessing that you considered, and probably tried CL,
> can you elaborate on why Python over Scheme, or (better) of CL?  It's
> about time I asked.  I looked over Python, though didn't dive into
> it.  I hated it right away, at least for AI-related applications.

For Scheme vs. CL - well, I liked Scheme's simplicity and elegance, for
prototyping work, though if I were writing commercial, production code
in any Lisp family language I'd use CL for its industrial-strength
features.

My reason for switching to Python over either for AI stuff, though, is
pretty much entirely a matter of syntax.  Specifically:

1) Algol-phylum languages use different syntactic forms for the various
common operations, whereas Lisp relies almost entirely on parentheses
and indentation.  I find the result is I can see the structure of code
written in an Algol language at a glance, whereas with Lisp I have to
nearly read it line by line.

2) Algol languages have concise syntax for common operations, with the
result that I find it much easier to write and (more importantly) read
and modify code.  Compare

	foo.bar += a[i][j] * abc.xyz;

with the Lisp equivalent.

Lisp's main practical strength as I see it is higher-order programming
(including macros), code that writes code etc (for which of course its
syntax is helpful).  Looking back over what I was doing, though, I found
I wasn't really using that stuff except for just passing function
references around, which can be done in any reasonably powerful
language, so I didn't have any reason to switch.

I would conjecture, admittedly without proof, that the above factors are
important for most of those who've seen Lisp but avoid it, even if they
don't articulate them.

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Christopher Browne
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  	 indentation?
Date: 
Message-ID: <slrn8p7500.40u.cbbrowne@knuth.brownes.org>
Centuries ago, Nostradamus foresaw a time when Russell Wallace would say:
>2) Algol languages have concise syntax for common operations, with the
>result that I find it much easier to write and (more importantly) read
>and modify code.  Compare
>
>	foo.bar += a[i][j] * abc.xyz;
>
>with the Lisp equivalent.

Hmm.  
      (incf foo-bar (* (aref a i j) abc-xyz))
does not look _so_ awful.
-- 
········@ntlug.org - <http://www.hex.net/~cbbrowne/linux.html>
Rules of the Evil Overlord #138. "The passageways to and within my
domain will be well-lit with fluorescent lighting. Regrettably, the
spooky atmosphere will be lost, but my security patrols will be more
effective." <http://www.eviloverlord.com/>
From: Russell Wallace
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  	 indentation?
Date: 
Message-ID: <3993A8C6.2B57@esatclear.ie>
Christopher Browne wrote:
> 
> Centuries ago, Nostradamus foresaw a time when Russell Wallace would say:
> >2) Algol languages have concise syntax for common operations, with the
> >result that I find it much easier to write and (more importantly) read
> >and modify code.  Compare
> >
> >       foo.bar += a[i][j] * abc.xyz;
> >
> >with the Lisp equivalent.
> 
> Hmm.
>       (incf foo-bar (* (aref a i j) abc-xyz))
> does not look _so_ awful.

foo.bar is an attribute access though, so instead of foo-bar in Lisp,
you'd need to call an accessor method for bar on foo; I forget the
syntax for this.

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Robert Monfera
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant  	 indentation?
Date: 
Message-ID: <398BB02A.56D6476C@fisec.com>
Russell Wallace wrote:

> Compare
>
>         foo.bar += a[i][j] * abc.xyz;
>
> with the Lisp equivalent.

(incf (foo bar) (* (aref a i j)
                   (abc xyz)))


Compare 

(incf (foo bar baz) (* (aref a i j)
                       (abc xyz qwe)))

with the Python equivalent .

...oops, no multimethods...

Robert
From: Bruce Hoult
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  	 indentation?
Date: 
Message-ID: <bruce-306542.19165611082000@news.akl.ihug.co.nz>
In article <·················@fisec.com>, Robert Monfera 
<·······@fisec.com> wrote:

> Russell Wallace wrote:
> 
> > Compare
> >
> >         foo.bar += a[i][j] * abc.xyz;
> >
> > with the Lisp equivalent.
> 
> (incf (foo bar) (* (aref a i j)
>                    (abc xyz)))

Dylan [1] can be similar to Python, or similar to Lisp...

  foo.bar += a[i, j] * abc.xyz;
  bar(foo) += aref(a, i, j) * xyz(abc);
  bar-setter(bar(foo) + aref(a, i, j) * xyz(abc), foo);

Are you sure you got the Lisp correct?


> Compare 
> 
> (incf (foo bar baz) (* (aref a i j)
>                        (abc xyz qwe)))
> 
> with the Python equivalent .
> 
> ...oops, no multimethods...

Dylan has multimethods but loses the obj.slot shortcut syntax shortcut:

  foo(bar, baz) += a[i, j] * abc(xyz, qwe);
  foo-setter(foo(bar, baz) + a[i, j] * abc(xyz, qwe), bar, baz);

-- Bruce

[1] Dylan doens't have += built in, but it can be implemented as a very 
trivial macro if you don't mind relying on CSE in the compiler to avoid 
unnecessary evaluations, or with a slightly more complex macro if you 
want to guarantee no multiple-evaluation of foo in the first example or 
bar & baz in the second example.
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant    indentation?
Date: 
Message-ID: <B5BA9D6F.5354%page@best.NOSPAM.com>
in article ···························@news.akl.ihug.co.nz, Bruce Hoult at
·····@hoult.org wrote on 2000.08.11 00:16:

> Dylan [1] can be similar to Python, or similar to Lisp...
> 
> foo.bar += a[i, j] * abc.xyz;
> bar(foo) += aref(a, i, j) * xyz(abc);
> bar-setter(bar(foo) + aref(a, i, j) * xyz(abc), foo);
> 
> Are you sure you got the Lisp correct?

I think it's important to note that this can be taken even further in Dylan:

    bar-setter(\+(bar(foo), \*(aref(a, i, j), xyz(abc))), foo);

I think it's also important to note that in the absence of a
parenthesis-balancing editor, I had to spend quite a bit of time making sure
I had this right, whereas the infix version is obviously correct. Maybe it's
just me.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  	 indentation?
Date: 
Message-ID: <m3ya24tcz6.fsf@cadet.dsl.speakeasy.net>
Russell Wallace <········@esatclear.ie> writes:

> 2) Algol languages have concise syntax for common operations, with the
> result that I find it much easier to write and (more importantly) read
> and modify code.  Compare
> 
> 	foo.bar += a[i][j] * abc.xyz;

better than

	(incf (bar foo) (* (aref a i j)
			   (xyz abc)))

???

I guess it's a matter of opinion, but whatever.  Even if I preferred
the non-lisp one, I don't see how this relates to AI programs,
especially as they benefit so much from higher-order programming.

> Lisp's main practical strength as I see it is higher-order
> programming (including macros), code that writes code etc (for which
> of course its syntax is helpful).

Yeah.  That was specifically why I asked about AI programs.  If you'd
said something like GUIs or something I'd understand the Python
preference more easily.

dave
From: Russell Wallace
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant  	 indentation?
Date: 
Message-ID: <39947573.37A3@esatclear.ie>
David Bakhash wrote:
> 
> Russell Wallace <········@esatclear.ie> writes:
> 
> > 2) Algol languages have concise syntax for common operations, with the
> > result that I find it much easier to write and (more importantly) read
> > and modify code.  Compare
> >
> >       foo.bar += a[i][j] * abc.xyz;
> 
> better than
> 
>         (incf (bar foo) (* (aref a i j)
>                            (xyz abc)))
> 
> ???

I find there's a big difference in readability, yes.  I'm able to see
what the first does without even looking directly at it, just by
glancing at the screen, whereas the second, I have to read the line
interpreting individual symbols.

> I guess it's a matter of opinion, but whatever.

I guess it is :)

> Even if I preferred
> the non-lisp one, I don't see how this relates to AI programs,
> especially as they benefit so much from higher-order programming.

Of course, it depends on exactly what you're doing; AI is a big field. 
I found myself making little or no use of higher-order programming
features beyond function references, and instead creating specialized
representations to implement which I mostly used ordinary language
features.  On the other hand if you look at, say, AM and EURISKO, if
Lenat hadn't had Lisp available he'd probably have had to invent it
first.

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <3993601B.42D69948@kurtz-fernhout.com>
Russell-

Thanks for the comments.

I appreciate your opinions as someone who has tried both approaches.

You also raise a very good point about prefix vs. infix notation being
another stumbling block for people coming to Lisp from many Algol-like
languages. I personally feel prefix is OK if it gets you other things
(such as Lisp has). However, I should note that a language like
Smalltalk that merges postfix, infix, and keyword syntax (e.g.
"dictionary at: key put: value + 2 sin") does get by on less
parentheses, at a cost of course of not easily representing code and
data in the same format (plus other costs). And of course, Forth gets by
on no parentheses -- again at other costs.

Yes, I too think aesthetics plays a big role. We may have somewhat
different senses of aesthetics, but the world would be pretty boring if
we didn't.

Thanks for the comment on not seeing any big practical problems to
making it work. Thats a major interest o mine in posting. So far, while
I have a lot of good reasons why current experienced Lisp users wouldn't
want to use an identational syntax, I still haven't seen a concrete
example of where one can't represent a valid S-expresison with the sort
of indentational approach outlined.
 
Thanks again for the comments. I'll be curious as well to see your reply
if any to the question someone else asked regarding your switch to
Python for AI.

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

Russell Wallace wrote:
> 
> Paul Fernhout wrote:
> > I'm interested in using significant indentation (like in Python)
> >   http://www.python.org
> > to replace many parentheses in Lisp or Scheme programs.
> 
> Interesting idea!  I'm afraid my response is going to be negative, but
> thanks for posting the idea anyway, it's certainly sparked some
> discussion and helped me clarify some thoughts.
> 
> I don't see any big practical problems with the proposal, but I must
> admit I'm still not fond of it.
> 
> > While some people can't get past significant indentation in Python
> > (citing for example occasional difficulty cutting and pasting code from
> > newsgroup posting or mail sent with old mail clients) and stick with
> > Perl, etc., the ones who do get past the unfamiliarity with
> > indentational syntax almost uniformly like it and say it is a feature
> > that aids program readability.
> 
> Maybe.  If that's a rule, then I'm an exception to it.
> 
> I've found no practical problems whatsoever with Python's
> indentation-based syntax.  (I indent C the same way, after all, even
> though the language doesn't require it.)  Nonetheless, it still makes me
> feel a bit queasy.  The best analogy I can think of is drinking milk
> that hasn't _quite_ gone off yet.  You have to admit there isn't any
> practical problem with drinking the stuff, but nothing will ever
> convince you it wouldn't be better if it was perfectly fresh.
> 
> For me, the issue isn't one of practice, but of aesthetics, and no
> practical argument will ever convince me to like indentation-based
> syntax.  (If typing brackets was a lot of work it might be different,
> but it's not.)  Now I use Python happily enough anyway (it helps that I
> use it for scripting/prototyping stuff where the emphasis is more on
> "get the job done quickly" than on "build to last"), but I'd be even
> happier if that aspect of it were different.
> 
> And I suspect that for most people who dislike indentation-based syntax,
> their real reason is aesthetic also.
> 
> > Yes, people put down Lisp saying it stands for "Lots of Infernal Stupid
> > Parentheses". Rather than be defensive, here is an approach that might
> > do something about what much of the world perceives as a difficulty in
> > reading and writing Lisp code.
> 
> People do say that, and they talk about prefix versus infix.  But I
> don't think those are the real issues.  I've switched from Scheme to
> Python for AI/prototyping work for reasons of syntax, but it's not a
> question of the number of brackets required, or of putting the + sign
> before the operands rather than between them, and I think that's true
> for most Lisp-avoiders.  So I don't think your proposal would actually
> help.
> 
> --
> "To summarize the summary of the summary: people are a problem."
> Russell Wallace
> ···············@esatclear.ie
> http://www.esatclear.ie/~rwallace
From: Russell Wallace
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <399391DE.779B@esatclear.ie>
Paul Fernhout wrote:
> 
> Russell-
> 
> Thanks for the comments.
> 
> I appreciate your opinions as someone who has tried both approaches.
> 
> You also raise a very good point about prefix vs. infix notation being
> another stumbling block for people coming to Lisp from many Algol-like
> languages. I personally feel prefix is OK if it gets you other things
> (such as Lisp has). However, I should note that a language like
> Smalltalk that merges postfix, infix, and keyword syntax (e.g.
> "dictionary at: key put: value + 2 sin") does get by on less
> parentheses, at a cost of course of not easily representing code and
> data in the same format (plus other costs). And of course, Forth gets by
> on no parentheses -- again at other costs.

Yep!  I've played around with both of them a little bit - they're each
wonderfully elegant in their own way, though I must admit at the end of
the day I prefer the Algol phylum syntax for actually getting code
written.

> Yes, I too think aesthetics plays a big role. We may have somewhat
> different senses of aesthetics, but the world would be pretty boring if
> we didn't.

This is true :)

> Thanks for the comment on not seeing any big practical problems to
> making it work. Thats a major interest o mine in posting. So far, while
> I have a lot of good reasons why current experienced Lisp users wouldn't
> want to use an identational syntax, I still haven't seen a concrete
> example of where one can't represent a valid S-expresison with the sort
> of indentational approach outlined.

I'm pretty sure it would work.  I think it's important to make it easy
to flip back and forth between the two views of a particular source
file, so fans of one don't break out the voodoo dolls when faced with
the other :)  Either an add-on for Emacs or a pair of filter programs
I'd say would do the job nicely.

> Thanks again for the comments.

Welcome!

-- 
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
From: Kent M Pitman
Subject: META: Newsgroup conversation fragmentation
Date: 
Message-ID: <sfwbsywtnrg.fsf_-_@world.std.com>
Am I the only person who's experiencing massive fragmentation of the
  Re: RFC: Lisp/Scheme with less parentheses through Python-like ...
conversation in newsreaders?  Rather than a simply structured tree like
I get for all other conversations, somehow I keep finding 50 little 
subconverstaions as if someone's newsreader is not attaching the requisite
"references" lines, or is mucking around with the subject line in some way,
such that this conversation is continually fragmented.

For as much as it's happening, it's probably someone who is a principle
conversationalist in this conversation.  Please double-check that you are 
not "helpfully" removing references that you should not be and that your
newsreader is not wrapping, filling, or otherwise modifying the subject line
to be different going out than it was going in.

Thanks.
From: Coby Beck
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <MqOl5.24380$47.428173@news.bc.tac.net>
"Kent M Pitman" <······@world.std.com> wrote in message
·······················@world.std.com...
> Am I the only person who's experiencing massive fragmentation of the
>   Re: RFC: Lisp/Scheme with less parentheses through Python-like ...
> conversation in newsreaders?  Rather than a simply structured tree like
> I get for all other conversations, somehow I keep finding 50 little
> subconverstaions as if someone's newsreader is not attaching the requisite
> "references" lines, or is mucking around with the subject line in some
way,
> such that this conversation is continually fragmented.
>

You're not the only one!  I count nine threads from the original in my
newsreader...

Coby
From: Duane Rettig
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <4u2cnykav.fsf@beta.franz.com>
"Coby Beck" <·····@mercury.bc.ca> writes:

> "Kent M Pitman" <······@world.std.com> wrote in message
> ·······················@world.std.com...
> > Am I the only person who's experiencing massive fragmentation of the
> >   Re: RFC: Lisp/Scheme with less parentheses through Python-like ...
> > conversation in newsreaders?  Rather than a simply structured tree like
> > I get for all other conversations, somehow I keep finding 50 little
> > subconverstaions as if someone's newsreader is not attaching the requisite
> > "references" lines, or is mucking around with the subject line in some
> way,
> > such that this conversation is continually fragmented.
> >
> 
> You're not the only one!  I count nine threads from the original in my
> newsreader...

My newsreader (gnus) sees almost every article as a separate thread.

I think the problem is that the title is so long that there are
different newline/space/tab configurations between the last three
words of the title ("Python-like", "significant", and "indentation").
I tried to fix this when I gave a response, by changing the title
to a shorter one, but apparently it wasn't short enough; when Paul
Fernhout answered me there was another newline/tab in the middle,
and the thread was disjoint again!  I think that Paul Fernhout is
using a newsreader with a _very_ short line-wrap in the title.

Normally I wouldn't be describing the obvious as above, but I
couldn't escape the meta-irony - In one article Paul Fernhout
noted ironically that we Lisp users tend to display our titles in
a format with significant indentation; the meta-irony is that for
the particular thread in question, the indentations do not work!

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Kent M Pitman
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <sfwog2vlsop.fsf@world.std.com>
Duane Rettig <·····@franz.com> writes:

> Normally I wouldn't be describing the obvious as above, but I
> couldn't escape the meta-irony - In one article Paul Fernhout
> noted ironically that we Lisp users tend to display our titles in
> a format with significant indentation; the meta-irony is that for
> the particular thread in question, the indentations do not work!

Amen.  I noticed this same effect!

- - - - - 

Btw, the consensus of various e-mails I've received privately, though,
is that only some newsreaders are botching this, and even those if you
go back many hundreds (perhaps as many as 1500) messages to find the
root, you win.

Apparently, the problem is that some readers are coalescing based only
on messages in the retrieved set having a common link to one anohter, rather
than on whether they contain a reference in common.  This might be a bug.
Or the problem might be something else.  But I'm losing with gnus and
I've heard others are not for sufficiently large sets of grabbed messages.

(Since my original hypothesis for the effect is refuted, I'm now
guessing it's because this conversation is so bushy, with people
perhaps just grabbing messages at random to reply to rather than
reading it in its whole and contributing "at the end", that we're
seeing this effect.  But certainly this conversation is creating 
problems I've not seen with other conversations in a very long time.)
From: Martin Thornquist
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <xung0o7sq6k.fsf@levding.ifi.uio.no>
[ Kent M Pitman ]

> Apparently, the problem is that some readers are coalescing based only
> on messages in the retrieved set having a common link to one anohter, rather
> than on whether they contain a reference in common.  This might be a bug.
> Or the problem might be something else.  But I'm losing with gnus and
> I've heard others are not for sufficiently large sets of grabbed messages.

You're using Gnus 5.3, which is *very* old. The current version is
5.8.7, and Gnus has become *much* better at many things in the last
years. You can also tweak the way Gnus displays threads, by telling it
to e.g. ignore subjects and just thread on references. I'm no expert
in these matters, though, but you can find it in the documentation.


Martin
-- 
Unfortunately, the computer science departments in many universities
apparently believe that fluency in C++ is more important than a sound
education in elementary mathematics.
              -Leslie Lamport, Specifying Concurrent Systems with TLA+
From: Tom Breton
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <m37l9jqu1k.fsf@world.std.com>
Martin Thornquist <·······@ifi.uio.no> writes:

> [ Kent M Pitman ]
> 
> > Apparently, the problem is that some readers are coalescing based only
> > on messages in the retrieved set having a common link to one anohter, rather
> > than on whether they contain a reference in common.  This might be a bug.
> > Or the problem might be something else.  But I'm losing with gnus and
> > I've heard others are not for sufficiently large sets of grabbed messages.
> 
> You're using Gnus 5.3, which is *very* old. The current version is
> 5.8.7, and Gnus has become *much* better at many things in the last
> years. 

I'm using Gnus v5.8.2 and I see the same thing as Kent.  There's
something going on here that doesn't usually happen in bushy threads.

I just checked, and whoever said that subject lines's whitespace is
being mangled is correct.  Not one separate-thread subject line
matches another exactly.

-- 
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.
From: Boris Schaefer
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <87sns764fj.fsf@qiwi.uncommon-sense.net>
Kent M Pitman <······@world.std.com> writes:

| Apparently, the problem is that some readers are coalescing based only
| on messages in the retrieved set having a common link to one anohter, rather
| than on whether they contain a reference in common.  This might be a bug.
| Or the problem might be something else.  But I'm losing with gnus and
| I've heard others are not for sufficiently large sets of grabbed messages.

Well, you shouldn't lose with Gnus.

Try:

(setq gnus-fetch-old-headers t)

or

(setq gnus-summary-thread-gathering-function
     'gnus-gather-threads-by-references)

The default for the latter is gnus-gather-threads-by-subject.  Anyway,
I have seen from your headers that you're using Gnus v5.3 and I'm not
sure whether this is configurable in that version.

-- 
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>

"Hello," he lied.
		-- Don Carpenter, quoting a Hollywood agent
From: Duane Rettig
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <4sns7yd24.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Duane Rettig <·····@franz.com> writes:
> 
> > Normally I wouldn't be describing the obvious as above, but I
> > couldn't escape the meta-irony - In one article Paul Fernhout
> > noted ironically that we Lisp users tend to display our titles in
> > a format with significant indentation; the meta-irony is that for
> > the particular thread in question, the indentations do not work!
> 
> Amen.  I noticed this same effect!
> 
> - - - - - 
> 
> Btw, the consensus of various e-mails I've received privately, though,
> is that only some newsreaders are botching this, and even those if you
> go back many hundreds (perhaps as many as 1500) messages to find the
> root, you win.

This bolsters my own theory, which I will state below.

> Apparently, the problem is that some readers are coalescing based only
> on messages in the retrieved set having a common link to one anohter, rather
> than on whether they contain a reference in common.  This might be a bug.
> Or the problem might be something else.  But I'm losing with gnus and
> I've heard others are not for sufficiently large sets of grabbed messages.

I don't know the intentions of the gnus authors, but my own empirical
experience with gnus tells me that it is the title that is more important
than the references, and that this is a desirable thing due to the fact
that a person may want to respond to a particular item in an article on
a different thread.  The easiest way to do this is to change the title
of the article; references need not be removed.  So I think that the
spawning of new threads is sort of a DWIM approach, which breaks
down when the titles get munged in some way.

> (Since my original hypothesis for the effect is refuted, I'm now
> guessing it's because this conversation is so bushy, with people
> perhaps just grabbing messages at random to reply to rather than
> reading it in its whole and contributing "at the end", that we're
> seeing this effect.  But certainly this conversation is creating 
> problems I've not seen with other conversations in a very long time.)

Unfortunately, I did not see your original article, and that is why
I didn't respond directly to it.  So I don't know what your theory
is (though I can get it from deja.com, later).  I have seen many
threads that are disjoint like this (though many are in other newsgroups,
like comp.arch) but the one thing these threads have in common are the
long titles they carry, and that the disjointedness seems to occur when
the newline/space/tab separations between words are changed in any way,
causing gnus to think that the thread has changed.  (To remain on-topic
to the newsgroup and the original discussion, this line-break
inconsistency has been pointed out in another article as a major weakness
in the concept of "significant indentation").

Two other possible reasons why this thread may appear to be broken up
are:

 1. I tend to read this newsgroup often, to keep from getting backlogged.
Thus, I see articles that have no current parent, though if I use
the ^ key (gnus-summary-refer-parent-article) the summaries are rearranged
with the new information available.  Thus a person who reads comp.lang.lisp
less often may see better structure for those articles that do have 
precisely the same title.

 2. The general flavor I get of the thread in question is less one of a
normal conversation between many c.l.l contributors, but more of many
conversations between many c.l.l. contributor and Paul Fernhout.  Thus,
every other article (mostly) in any branch on the thread is an article
by Paul.  This is not a fact, just a gut feel I get as I generalize
the conversations within my memory.  Again, a look at deja.com would
verify or deny this (but I'm too lazy/have other things to do).

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Martin Thornquist
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <xunitt2ltaz.fsf@jarn.ifi.uio.no>
[ Duane Rettig ]

> I don't know the intentions of the gnus authors, but my own empirical
> experience with gnus tells me that it is the title that is more important
> than the references, and that this is a desirable thing due to the fact
> that a person may want to respond to a particular item in an article on
> a different thread.  The easiest way to do this is to change the title
> of the article; references need not be removed.  So I think that the
> spawning of new threads is sort of a DWIM approach, which breaks
> down when the titles get munged in some way.

Two things: you're using Gnus 5.5, which is not as old as Kent's 5.3,
but still very far from current (which is 5.8.7, available from
<URL:http://www.gnus.org/>). And how Gnus threads can be controlled by
the variable gnus-summary-thread-gathering-function, although I'm not
sure how far back that goes.



Martin
-- 
Unfortunately, the computer science departments in many universities
apparently believe that fluency in C++ is more important than a sound
education in elementary mathematics.
              -Leslie Lamport, Specifying Concurrent Systems with TLA+
From: Espen Vestre
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <w6sns6oiid.fsf@wallace.nextel.no>
Duane Rettig <·····@franz.com> writes:

> My newsreader (gnus) sees almost every article as a separate thread.

My gnus actually sees the whole thing as one single thread, but I
noticed that it consists of several subthreads that branch near the
top node, which also made me think that something funny was going on
(since, if you only see the last x articles, but not the branch points,
it will appear as several threads).

(I must mention that I use 'pterodactyl gnus' which is significantly
 enhanced compared to your version (I've been as little lazy upgrading
 since pgnus 0.97 works so well for me, but pterodactyl gnus has now
 been released as version 5.8)).

-- 
  (espen)
From: Xenophon Fenderson the Carbon(d)ated
Subject: Re: Newsgroup conversation fragmentation
Date: 
Message-ID: <w4ok8dhrjl1.fsf@lovecraft.irtnog.org>
Duane, et all,

I've had no problems what so ever with reading the less-paren thread.
That said, here are the relevant lines from my .gnus (at least I think
they're relevant; it's been a while since I last hacked on this
thing).  This section has remained unchanged for the last several
years (since about Gnus 5.3).  I'm currently running 5.7 (comes with
GNU Emacs 20.7).  If you want to see my entire .gnus file, feel free
to grab a copy from http://web.irtnog.org/~xenophon/.gnus.

(setq gnus-show-threads t)
(setq gnus-fetch-old-headers 'some)
(setq gnus-build-sparse-threads nil)						;(gnus)Customizing Threading
(setq gnus-summary-gather-subject-limit 'fuzzy)
(setq gnus-simplify-subject-fuzzy-regexp "\\([Rr][Ee]:*\\)")			;defaults to 'nil
(setq gnus-simplify-ignored-prefixes
      (concat
       "\\`\\[?\\("
       (mapconcat 'identity
		  '("looking" "wanted" "followup" "summary\\( of\\)?"
		    "help" "query" "problem" "question"
		    "answer" "reference" "announce"
		    "How can I" "How to" "Comparison of"
		    ;; ...add your own here...
		    )
		  "\\|")
       "\\)\\s *\\("
       (mapconcat 'identity
		  '("for" "for reference" "with" "about")
		  "\\|")
       "\\)?\\]?:?[ \t]*"))
(setq gnus-summary-gather-exclude-subject "^ *$\\|^(none)$\\|^[Tt]est$")
(setq gnus-summary-thread-gathering-function 'gnus-gather-threads-by-references)
(setq gnus-summary-make-false-root 'dummy)
(setq gnus-thread-hide-subtree t)
(setq gnus-thread-hide-killed t)
(setq gnus-thread-operation-ignore-subject 'fuzzy)
(setq gnus-thread-sort-function '(gnus-thread-sort-by-number
				  gnus-thread-sort-by-subject
				  gnus-thread-sort-by-score))

Hope this helps,
#\Xenophon

-- 
> So Americans are either 'bible thumpers' or 'sheep'? 
I, personally, am a 'sheep thumper.'
 --Anonymous Coward in http://slashdot.org/article.pl?sid=00/07/21/1516215
From: Johan Kullstam
Subject: Re: META: Newsgroup conversation fragmentation
Date: 
Message-ID: <m24s4o8418.fsf@euler.axel.nom>
Kent M Pitman <······@world.std.com> writes:

> Am I the only person who's experiencing massive fragmentation of the
>   Re: RFC: Lisp/Scheme with less parentheses through Python-like ...
> conversation in newsreaders?  Rather than a simply structured tree like
> I get for all other conversations, somehow I keep finding 50 little 
> subconverstaions as if someone's newsreader is not attaching the requisite
> "references" lines, or is mucking around with the subject line in some way,
> such that this conversation is continually fragmented.

you are not the only one.   i have it too.

-- 
J o h a n  K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: Boris Schaefer
Subject: Re: META: Newsgroup conversation fragmentation
Date: 
Message-ID: <87wvhj64ou.fsf@qiwi.uncommon-sense.net>
Johan Kullstam <········@ne.mediaone.net> writes:

| Kent M Pitman <······@world.std.com> writes:
| 
| > Am I the only person who's experiencing massive fragmentation of the
| >   Re: RFC: Lisp/Scheme with less parentheses through Python-like ...
| > conversation in newsreaders?  Rather than a simply structured tree like
| > I get for all other conversations, somehow I keep finding 50 little 
| > subconverstaions as if someone's newsreader is not attaching the requisite
| > "references" lines, or is mucking around with the subject line in some way,
| > such that this conversation is continually fragmented.
| 
| you are not the only one.   i have it too.

well, you at least should be able to solve this problem, since you are
using a current version of Gnus.

Threading in Gnus by default works by looking at the subject lines.
since the subject is continuously changing in this thread, it's pretty
hard to do this.  you could do:

  (setq gnus-fetch-old-headers t)

in your .gnus file, but you will get some already read articles in
your summary buffer.  I use this setting and I have no problems with
this thread.

You could also do:

  (setq gnus-summary-thread-gathering-function
       'gnus-gather-threads-by-references)

Gnus won't look at the subject lines anymore.  You can leave
gnus-fetch-old-headers at nil and it'll still work.  (I just tried
it.)  Beware that the latter may break your threading in newsgroups
with lots of people using stupid newsreaders that break the
"References:" header (I think TIN is a notorious References: breaker,
but I'm not sure.)

-- 
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>

He's just a politician trying to save both his faces...
From: Johan Kullstam
Subject: Re: META: Newsgroup conversation fragmentation
Date: 
Message-ID: <m3zomfd6tu.fsf@sysengr.res.ray.com>
Boris Schaefer <·····@uncommon-sense.net> writes:

> Johan Kullstam <········@ne.mediaone.net> writes:
> 
> | Kent M Pitman <······@world.std.com> writes:
> | 
> | > Am I the only person who's experiencing massive fragmentation of the
> | >   Re: RFC: Lisp/Scheme with less parentheses through Python-like ...
> | > conversation in newsreaders?  Rather than a simply structured tree like
> | > I get for all other conversations, somehow I keep finding 50 little 
> | > subconverstaions as if someone's newsreader is not attaching the requisite
> | > "references" lines, or is mucking around with the subject line in some way,
> | > such that this conversation is continually fragmented.
> | 
> | you are not the only one.   i have it too.
> 
> well, you at least should be able to solve this problem, since you are
> using a current version of Gnus.
> 
> Threading in Gnus by default works by looking at the subject lines.
> since the subject is continuously changing in this thread, it's pretty
> hard to do this.  you could do:
> 
>   (setq gnus-fetch-old-headers t)
> 
> in your .gnus file, but you will get some already read articles in
> your summary buffer.  I use this setting and I have no problems with
> this thread.
> 
> You could also do:
> 
>   (setq gnus-summary-thread-gathering-function
>        'gnus-gather-threads-by-references)
> 
> Gnus won't look at the subject lines anymore.  You can leave
> gnus-fetch-old-headers at nil and it'll still work.  (I just tried
> it.)  Beware that the latter may break your threading in newsgroups
> with lots of people using stupid newsreaders that break the
> "References:" header (I think TIN is a notorious References: breaker,
> but I'm not sure.)

thank you.  i am trying your second suggestion.  it works fine on this
thread.

-- 
J o h a n  K u l l s t a m
[········@ne.mediaone.net]
sysengr
From: Dan Schmidt
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <wk7l9nken5.fsf@harmonixmusic.com>
I agree with a lot of the posters in this thread that
indentation-signficance is not a good idea for Lisp (though I think
it's great in Python).

That said, you may want to take a look at the functional language
Haskell, which allows the programmer to specify structure explictly
with parentheses or implicitly with indentation.  You look at the
rules and think that it would be a huge mess, but in practice it does
an excellent job of doing the Right Thing.

-- 
                 Dan Schmidt | http://www.dfan.org
Honest Bob CD now available! | http://www.dfan.org/honestbob/cd.html
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <sfwem3vr8h2.fsf@world.std.com>
Dan Schmidt <····@harmonixmusic.com> writes:

> You look at the
> rules and think that it would be a huge mess, but in practice it does
> an excellent job of doing the Right Thing.

This is a situation in which "The Right Thing" cannot possibly apply.
There is no "Right Thing" when it comes to representing all possible
expressions, which is what programming languages are about.  You have
to narrow your remarks to presuppositions about the kinds of programs
you typically expect and/or want to encourage in order to know what's
even statistically right for the given constraints.

As a rule, languages which are about writing an expected set of things
(such as COBOL, where you can probably write some very typical expressions
that are typical of all programming in COBOL because the typical 
application domain is constrained), are going to lend themselves to 
notations that are "statistically good" for some set of things.  But Lisp
is often about writing programs to handle "the unexpected" and when you
make your notation biased toward what you expect people to write, you
risk making certain programs hard.  

As a linguistics professor of mine, the late Bill Martin, used to say,
"languages aren't about saying what is expected, but about what is
not".  He would go on to say that if "cheese mouse eat" was enough as
just a sequence of words to mean "the obvious thing" then there would be
no need for syntax.  Just the words and their obvious meaning would be
enough.  But languages are about being able to express complex
situations like "the cheese ate the mouse", and that's why we have complex
syntax.  

In Lisp, grouping is a huge part of what it is.  And so to carry
grouping in an "invisible" notation (indentation), rather than to
emphasize it, gives short shrift to its importance and risks that when
subtle differences in grouping really matter, they will likewise be
invisible and/or hard to achieve.  One wants to be able to easily see
not only the expected things, but the unexpected, and that's what Lisp
syntax allows in a relatively domain-neutral way.

Grouping is SO IMPORTANT in Lisp, in fact, that we not only mark it
with (...), but we ALSO make whitespace unimportant so that in
practice it can be used to UNDERSCORE the paren level, providing a
level of redundancy to emphasize paren grouping, making it possible to
catch paren errors.  Carrying the information on only one channel
would make the language too fragile.  It's only by using parens AND
indentation AND auto-paren-flashing that we get the level of checking
that is commensurate with the importance of the information being
conveyed.

In fact, while I'm on the topic of grouping, Martin sometimes conjectured
when we were working with his XLMS system for representing linguistic
relationships that it was only "shape" of information that mattered and
that the actual meaning of the terms didn't matter once you really got 
everything connected in the right way.  (That is, if an alien race made the
web of connections from our dictionary and came up with a consistent meaning
to all the terms as described merely by their connectivity, it sort of wouldn't
matter if their understanding was "correct" as long as it was "predictive"
and "ever consistent".  In fact, there'd be no way to find out if any one of
us had a similar "error" in understanding as long as all of our reasoning
processes worked self-consistently.)  If you believe any of this, then a
consequence is, again, that it's "grouping" and "connectivity" that are the
foundations of knowledge, and consequently you can at least understand why
some among us (myself included) would think they were poor choices for
using the fragility of mere indentation to carry such important semantics.
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <B5BA9BB1.5353%page@best.NOSPAM.com>
in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.11 10:52:

> As a linguistics professor of mine, the late Bill Martin, used to say,
> "languages aren't about saying what is expected, but about what is
> not".  He would go on to say that if "cheese mouse eat" was enough as
> just a sequence of words to mean "the obvious thing" then there would be
> no need for syntax.  Just the words and their obvious meaning would be
> enough.  But languages are about being able to express complex
> situations like "the cheese ate the mouse", and that's why we have complex
> syntax.  

Of course, in Esperanto each word has a prefix and/or suffix to indicate its
role, so that sentences can be arranged in almost any order without
destroying the meaning. Unconventional orderings can be harder to read, but
it provides a freedom that can be used to add meaning and stress (as, of
course, does English, but not to as great an extent).

A lesson to be learned here is that some complexity in a computer language
can be a good thing. If anything, one (not me of course) might argue that
Lisp syntax isn't complex enough. That it's too smooth. And of course we all
know that smooth things are often uninteresting things. (Clearly Lisp isn't
that smooth.)

So I see a lot of merit in "infix" syntaxes. And I think Dylan provides a
good example of how a language can provide for a range between "smooth" and
"interesting" (speaking loosely). So that programmers have a tool for
communicating information to human readers with emphasis and stress in their
programs. An extremely brief example:

    dog.color := #'black';

        vs.

    color-setter( #'black', dog );

These always mean the same thing to the computer, but not always the same
thing to the human.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like 	significant indentation?
Date: 
Message-ID: <sfwk8dkqv82.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> An extremely brief example:
> 
>     dog.color := #'black';
> 
>         vs.
> 
>     color-setter( #'black', dog );

This is really off-topic, but I have to find a place to say it "on the record"
at some time in my life, and let me just say that I find this Dylanesque 
example to be double-edged.

(The point that "dog.color" is an idiomatic use that perhaps deserves
special syntax because of its frequency of use is surely a good one, 
but my point is off-topic to that.)

I absolutely think dylan did a DREADFUL thing in making the syntax for symbols
be #'symbol' rather than just symbol.  This means that a list of symbols
must look like (#'my', #'name', #'is', #'fred') rather than just
('my, 'name, 'is, 'fred) or even '(my, name, is, fred).  

When I think back to the way I was taught about AI concepts like Eliza 
initially and being told "just ignore the parentheses and concentrate on
the sequence of words between them" it was easy to do, but somehow 
"ignore the myriad special little syntactic markers around every word 
and concentrate on..." doesn't carry the same punch.  dylan should have 
taken a cue from macsyma (also an infix language, based on lisp) and just
had symbols be symbols and quotation of them, where needed, be by a 
single prefix quote, or even by a single prefix quote around the list with
no markers at all.

It's odd and sad to me that Dylan took this arguably good step of doing some
notations in a more compact way but others in a less compact way.  All in the
name of being more "mainstream", I guess.  But really I found the result much
less virtuous than it could have been.  It should have been:

  dog.color = 'black;

  vs 

  color_setter( 'black, dog );

(Yes, I rewrote the "-" to "_".  I absolutely can't agree to or forgive the
requirement of "space around hyphens if you want them to subtract" in an
infix language.  Dylan went to so much trouble to be like other infix 
languages and then broke this basic rule, thereby killing any reason for not
fixing other misfeatures in the process... They can't both reject my proposed
symbol syntax as "something C programmers wouldn't accept" and  then forgive
their own hyphen tokenization as "something C programmers would learn 
to live with".)

Ok, I said it.  Probably the wrong list.  But then I don't care to argue with
the Dylanites.  I'm just not going to use Dylan and this is principally among
my reasons.  They completely botched the syntax.  To me it isn't that infix
is good or bad, but there are rules of self-consistency and rules of taste, and
they did a bad job within their self-established constraints of being either
self-consistent or tasteful, and I can't stand the result.
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <B5BD3DCB.54FC%page@best.NOSPAM.com>
in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.13 22:15:

> I absolutely think dylan did a DREADFUL thing in making the syntax for symbols
> be #'symbol' rather than just symbol.  This means that a list of symbols must
> look like (#'my', #'name', #'is', #'fred') rather than just ('my, 'name, 'is,
> 'fred) or even '(my, name, is, fred).

Yes, I think the symbol syntax is visually noisome. But single quote is used
for character constants, so what can you do? Well, I guess there are a lot
of other characters to choose from, and it wouldn't hurt to branch out into
Unicode to expand the pool of possible characters.

Actually, I object more to the symbol syntax on the grounds that pound #
should be reserved exclusively for language keywords. Symbols are the only
thing that begin with # that aren't elements of the language (AFAIR).

> I absolutely can't agree to or forgive the requirement of "space around
> hyphens if you want them to subtract" in an infix language.

On the other hand, I can't agree to not using spaces around operators,
because I find "foo - bar" more readable than "foo-bar". So why not require
it in the language? I'm sure this is a matter of taste.

In any case, I think the bigger issue is that I like the fact that Dylan
allows a much larger set of characters to be part of a symbol name than
other languages. It isn't just about '-', either. What about '*'? Without
this rule, you couldn't use '*' in a name. I think it is an excellent
character for making global (special?) variables visually distinct.

If anything, I think they should have put some explicit Unicode characters
into the language, so that, for example, one could use a hyphen that is
distinct from minus.

Then again, these details are irrelevant once you move away from static
plain text files towards dynamic code presentation. Then you can highlight
globals or indicate intra-symbol word breaks using other methods.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <B5BD4398.5508%page@best.NOSPAM.com>
[Minor correction to my previous post...feel free to ignore.]

in article ··················@best.NOSPAM.com, Chris Page at
····@best.NOSPAM.com wrote on 2000.08.14 06:10:

> Actually, I object more to the symbol syntax on the grounds that pound #
> should be reserved exclusively for language keywords. Symbols are the only
> thing that begin with # that aren't elements of the language (AFAIR).

In Dylan, # is used for all literals, and it's double quotes for keywords,
not single quotes:

    #"string"   // Keyword (aka Unique String)
    #()         // List/pair literal
    #[]         // Vector literal

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  	significant indentation?
Date: 
Message-ID: <sfwr97rltlx.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> In Dylan, # is used for all literals, and it's double quotes for keywords,
> not single quotes:
> 
>     #"string"   // Keyword (aka Unique String)
>     #()         // List/pair literal
>     #[]         // Vector literal

IMO, this is wrong because it violates nesting principles.  It means
that a literal within a literal is repeatedly marked as a literal.

Without intending to make anyone feel bad, I have to say that this strikes
me as the kind of design choice that is made by a person with a background
in languages where literals do not nest, who doesn't realize how ugly

  #(#'this',#'literal',#'is',#(#'bold',#'really'),#'quoted')

looks.  It should have been # to introduce a literal, rather than single
quote if that's what people like, and then a syntax for each token within
it that doesn't repeat.

  #(this,literal,is,(bold,really),quoted)

Note that this is not a question of preferring one language's way of
doing things over another's that drives my remark.  This is a set of general
design principle applicable to all languages:  "consider how the item looks
in use, not just statically in isolation", "avoid repetitive marks that don't
add information" (contrasted with Lisp parens, which occur repetitively
but always add information--a non-literal within a literal makes no sense
unless you're designing backquote, and there are easier ways to do that,
so there's no reason to repeat it), etc.
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <B5BE38BB.5667%page@best.NOSPAM.com>
in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.14 09:01:

> Without intending to make anyone feel bad, I have to say that this strikes
> me as the kind of design choice that is made by a person with a background
> in languages where literals do not nest, who doesn't realize how ugly
> 
> #(#'this',#'literal',#'is',#(#'bold',#'really'),#'quoted')
> 
> looks.  It should have been # to introduce a literal, rather than single
> quote if that's what people like, and then a syntax for each token within
> it that doesn't repeat.
> 
> #(this,literal,is,(bold,really),quoted)
> 
> Note that this is not a question of preferring one language's way of
> doing things over another's that drives my remark.  This is a set of general
> design principle applicable to all languages:  "consider how the item looks
> in use, not just statically in isolation", "avoid repetitive marks that don't
> add information" (contrasted with Lisp parens, which occur repetitively
> but always add information--a non-literal within a literal makes no sense
> unless you're designing backquote, and there are easier ways to do that,
> so there's no reason to repeat it), etc.

I agree in general. And I think it's important to note that you are talking
about the readability of the code, which is one of my hot topics. If we had
dynamic displays, then you could decide how you want nested literals
displayed regardless of how they are represented in some canonical plain
text representation.

And I want to highlight the idea that plain text source formats should be
relegated to being canonical interchange formats, instead of the primary
means for displaying code to programmers.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  	significant indentation?
Date: 
Message-ID: <sfwsns7ltwv.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> Yes, I think the symbol syntax is visually noisome. But single quote is used
> for character constants, so what can you do?

Redesign the language with that in mind.  #\x  for example.

Given lack of compatibility constraints with other languages, it wouldn't
be hard.

> Actually, I object more to the symbol syntax on the grounds that pound #
> should be reserved exclusively for language keywords.

CL made a horrible error in having the &keywords at all, and Dylan copied the
idea to #keyword over my offered objections at the appropriate design time.

The claim, falsely, I believe given modern editor technology's ability to 
highlight such things if needed, was that it was important for these markers
to stand out.  However, in CL a set of :keywords would have worked as well and
I believe would have been much stronger.

In Lisp, for example, (defun foo (x :optional y) ...)
would have been better than &optional, and would have cleared the namespace
of an irritating hole that it now has, where some symbols are inelegantly
dependent on their names.

Oddly, a consequence of this bad design in Lisp is that language designers
are wary of extending the &keyword namespace (because it involves a package
change to CL package) but not wary of extending the :keyword namespace
(because it affects package KEYWORD, which is effectively already massively
cluttered).  This means that on occasion good proposals have been looked at
skeptically, or (I hypothesize) not written at all, because they risked
introducing &keywords that would have flown through if they'd involved 
:keywords.  

I can't remember how the dylan syntax works, but I think there's no real
problem syntactically with having

  x, y, opt: z, key: int foo: bar, ...

This would have eliminated the problem with # being the introducer for these.
(Even if that was a problem, a notation like #!key could have been used
that didn't lock down all of #.)

> On the other hand, I can't agree to not using spaces around operators,
> because I find "foo - bar" more readable than "foo-bar". So why not require
> it in the language? I'm sure this is a matter of taste.

The reason not to require it in the language is because it is a matter of
taste.  People ought to be able to write either as they choose, and the
author's choice should determine how well their code survives. Instead,
the language designers have made a choice for everyone, and a bad one.

> In any case, I think the bigger issue is that I like the fact that Dylan
> allows a much larger set of characters to be part of a symbol name than
> other languages. It isn't just about '-', either. What about '*'? Without
> this rule, you couldn't use '*' in a name. I think it is an excellent
> character for making global (special?) variables visually distinct.

Thanks for mentioning this * thing--I'd forgotten.  I am quite
comfortable not using * in a name in an infix language.  Thanks for
mentioning this one.  _foo_ or $foo or sp$foo or any of a million
other easy to create conventions would have been fine for Dylan if
they wanted to to be infix-compatible.  Again, by blowing this common
point of compatibility, they give the lie to any claim that they 
overcomplicated the rest of the language for the sake of brain compatibility
with infixers everywhere.

> If anything, I think they should have put some explicit Unicode characters
> into the language, so that, for example, one could use a hyphen that is
> distinct from minus.

A hyphen with a baseline one pixel off from a minus, or something like that?
MMmmmm.... uh, no.

> Then again, these details are irrelevant once you move away from static
> plain text files towards dynamic code presentation.

You mean in the year 3000.  We used to be waiting for that change to happen
"any day now" back in 1980, and it doesn't seem to be coming soon.  Maybe
in 1980 I'd design a language around my belief in the imminent death of 
7-bit ASCII, but today given history I would not repeat the mistake.
From: Bruce Hoult
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like 	significant indentation?
Date: 
Message-ID: <bruce-014E2E.17380414082000@news.akl.ihug.co.nz>
In article <···············@world.std.com>, Kent M Pitman 
<······@world.std.com> wrote:

> Chris Page <····@best.NOSPAM.com> writes:
> 
> > An extremely brief example:
> > 
> >     dog.color := #'black';
> > 
> >         vs.
> > 
> >     color-setter( #'black', dog );
> 
> I absolutely think dylan did a DREADFUL thing in making the syntax for 
> symbols be #'symbol' rather than just symbol.  This means that a list
> of symbols must look like (#'my', #'name', #'is', #'fred') rather than
> just ('my, 'name, 'is, 'fred) or even '(my, name, is, fred).

I agree.  That's yukky.

btw, you can also use:

   #(my:, name:, is:, fred:)

Symbols can be represented both as #"symbol" and as symbol:.  The second 
form tends to look better in things such as keyword arguments in 
function calls, though it looks strange in other places.  I dislike 
#"symbol" so much that I tend to use symbol: even in places that others 
use the first form.


> I found the result much
> less virtuous than it could have been.  It should have been:
> 
>   dog.color = 'black;
> 
>   vs 
> 
>   color_setter( 'black, dog );

How do you feel about:

    dog.color = black:;

Not ideal, I agree.


> (Yes, I rewrote the "-" to "_".  I absolutely can't agree to or forgive 
> the requirement of "space around hyphens if you want them to subtract"
> in an infix language.

That really bugs me too.


> Ok, I said it.  Probably the wrong list.  But then I don't care to argue 
> with the Dylanites.

Plenty of us here too :-)


> I'm just not going to use Dylan and this is principally 
> among my reasons.

Your choice, of course, but I've got to say that's an awfully trivial 
thing to reject an otherwise good language for.  I don't know that 
there's a popular language that would pass muster under those criteria.  
Certainly not C++ or Perl.

-- Bruce
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like 	significant indentation?
Date: 
Message-ID: <sfw8zu0tlud.fsf@world.std.com>
Bruce Hoult <·····@hoult.org> writes:

[...discussion of Dylan syntax nits omitted...]

> > I'm just not going to use Dylan and this is principally 
> > among my reasons.
> 
> Your choice, of course, but I've got to say that's an awfully trivial 
> thing to reject an otherwise good language for.  I don't know that 
> there's a popular language that would pass muster under those criteria.  
> Certainly not C++ or Perl.

Dylan should have pushed Lisp syntax.  The only reason for deviating, and 
alienating a way of life that had given birth to it, was the reasonable 
approach that Java took of using "syntax compatibility" with a known 
language.  But then it gave up that constraint.  At that point, it was
just "gratuitously different" and I give it no points for not returning
to the fold and giving me back Lisp syntax.

While working at Harlequin, I worked on a (Lisp) project where someone had
"helpfully" coded up some part of it in Dylan and then offered me the code
to use.  Unfortunately, since I couldn't link the Dylan, the code was useless
to me.  Had the situation been reversed, and had I been working in Dylan and
they offered me Lisp, I'd have spent the 10 minutes writing a Dylan printer
for Lispy code, and I would have had a more-or-less Dylan translation I could
manually bang into shape for inclusion in a Dylan application.  Because the
situation was reversed, though, they were not offering me "parseable data"
since there isn't (or wasn't at the time, anyway) any published Dylan 
read/print that would allow me to treat the application the person had written
as "data" for me to bang around with. 

I consider this failure to come up with a serious representation
of Dylan in a data-oriented way to be fatal to any usefulness of Dylan to me.
Read/print is extraordinarily important to me.  The myriad little syntax
differences of Dylan mean not only that *I* have to learn another language,
but also that there is less chance of an off-the-shelf parser for some other
language which will "accidentally work" for Dylan as well.

There are, as I said, other reasons I am not now using Dylan, too.
It's not a bad language semantically, but it is badly targeted
marketingwise.  The syntax is an example.  The lack of good tools for
manipulating the syntax compounds the offense, and makes it very
non-trivial.  It's a language that was targeted at disgusted C++
programmers jumping ship from C++ back in the days before Java, and it
didn't do the work it should have to address the presence of Java in
the marketplace after Java arrived.  If it was clever, and it still
couldn't bring itself to come back to Lisp, it would reform its syntax
around Java and look for disgusted Java programmers...  but for now it
tries to pretend it can afford to be all on its own, and I think
that's not a strong enough market position.  JMO.  Probably the wrong
newsgroup for extended further discussion.  But my point for this forum
is really that "syntax" is not the thing--syntax is a symptom:

Suitability for a purpose is what makes a language good or bad.  And
that means the whole "ergonomics" or "comfortability" or something of
the whole lifecycle of things you'll do with the language.  What makes
Lisp's parens good isn't that it's parens and not brackets or even
indentation.  What makes it work is that there is a wealth of software
for and experience with the syntax that was arbitrarily chosen, and
it's well established that people can use lisp's read/print, emacs'
indentation tools, etc. in ways that work and permit high-bandwidth
interchange of symbolic data.  It's not the Lisp syntax that's the standard
to measure up to, but rather the experience of productivity of being in the
lisp world that one has to measure up to.  Exchanging data in dylan syntax
has yet to be shown to work well in writing an AI text to teach people how
easy it is to write an eliza program with easy-to-understand lines like

  (if (match input '(my name is *)) ...)

compared to lines like

  if ( input == (#'my', #'name', #'is', *wildcard-token*) ) ....
    

or where people write programs that they later decide to use as data
or vice versa.  Yes, Dylan has macros, but as far as I know, testing those
macros is hard.  And anyway, the macros aren't fully general purpose turing
machines, nor are all idioms easy to do.  In Lisp, the parts can all be
called as functions interactively and manipulated in ways that take 
already-existing knowledge of symbol manipulation to a new application, rather
than requiring the learning of a new skill.  Again, that's the standard of
measurement of a good language... 
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <B5BD40F0.5501%page@best.NOSPAM.com>
in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.13 23:09:

> I consider this failure to come up with a serious representation of Dylan in a
> data-oriented way to be fatal to any usefulness of Dylan to me.

While I agree that it would be good for the Dylan standard to specify a
data-oriented way to encode the language, I feel that the facility for
manipulating the language directly in itself is a "vertical-market" tool.

I think that the "complete introspection and manipulation" feature of Lisp
is great if you want to write programming tools for the language in itself,
or if you want to write code that writes code (and I'm sure it's good for
other things too). But when I go shopping for a language to write
shrink-wrap consumer software, I don't look for these features beyond a
little type introspection.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  	significant indentation?
Date: 
Message-ID: <sfwpunblt4w.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> While I agree that it would be good for the Dylan standard to specify a
> data-oriented way to encode the language, I feel that the facility for
> manipulating the language directly in itself is a "vertical-market" tool.

My recollection is that the first release of TeX was either not or was just
barely Turing powerful, but was certainly a pain to program in.  I heard
indirectly that Knuth said this was because he didn't want people to waste
time programming it and he just wanted people to use established macro 
libraries and get on with writing papers/books, or some such.  The only little
glitch was that someone had to write those programming tools in the nearly
impossible to use language that he'd offered... so, as I heard it, he relented
and added more programming tools so that writing of those macro libraries
was (more) possible.  Whether that's how it went historically for TeX or not,
the fact is that it illustrates a reasonable view on what the problem is with
your paragraph here.  The vertical markets may not rely directly on this
feature, but they will rely on killer tools being available off the shelf,
and my bet is that some people making those tools will need this facility,
so those vertical markets will need it.  You may only see this effect in the
absence of more tools or more vertical markets because certain programmers
put off by the claim that they are an "ignorable part of the demographic"
fail to flock to your/Dylan's cause, and so you may not perceive the ill 
effect of omitting it.  But I personally stand as an example, and read-print
is another on my short list of things making Dylan unusable, exactly because
its syntax is so baroque that I can't imagine wanting to bother writing my
own parser to correct the problem.  It would be hard, the syntax is yucky 
enough that it wouldn't be "fun", and the target language was designed by 
people who devalued my opinions, so I didn't see the point in contributing to
their cause...  I don't say this out of "sour grapes" but to say that these
things matter, and they have sociological, not just technical effects.  A 
*lot* of potential Dylan users got teed off at the syntax change and jumped
ship.  IMO Dylan could have been the logical successor to Lisp, I think, and
fairly deliberately gave that up for something else which I don't see it 
having achieved; as such, I'm not sure the trade was a good one.  

> I think that the "complete introspection and manipulation" feature of Lisp
> is great if you want to write programming tools for the language in itself,
> or if you want to write code that writes code (and I'm sure it's good for
> other things too). But when I go shopping for a language to write
> shrink-wrap consumer software, I don't look for these features beyond a
> little type introspection.

Funny, I have always lived by the motto that people shouldn't write programs,
programs should write programs.  Since I don't believe in AI per se, I don't 
mean that literally.  But I use programs to generate other programs all
the time, and I would be absolutely crippled working with a language where
I couldn't do that.  Even with Java, I periodically fall back to writing Lisp
that generates Java.  But when given others' Java or Dylan or other parsed
languages, there is little mechanical transformation I can do on it to whip
it into some other form I might find useful; such syntaxes are not "data" to
me.  They are just noise.
From: Marius Vollmer
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  	significant indentation?
Date: 
Message-ID: <87punb8n1s.fsf@zagadka.ping.de>
Kent M Pitman <······@world.std.com> writes:

> My recollection is that the first release of TeX was either not or
> was just barely Turing powerful, but was certainly a pain to program
> in.  I heard indirectly that Knuth said this was because he didn't
> want people to waste time programming it and he just wanted people
> to use established macro libraries and get on with writing
> papers/books, or some such.  The only little glitch was that someone
> had to write those programming tools in the nearly impossible to use
> language that he'd offered... so, as I heard it, he relented and
> added more programming tools so that writing of those macro
> libraries was (more) possible.

If my recollection is right, it was Guy Steele who talked Knuth into
putting more programming facilities into TeX.  Ah, yes, here it is,
"Question and Answers III" from Digital Typography, page 648:

    Don: In some sense, I put in many of TeX's programming features
    only after kicking and screaming; [...] I know how Leslie
    [Lamport] went about writing LaTeX--first he would write the
    algorithm out in a high-level programming language, with while's
    and if-then's and so on; then he would pretty much mechanically
    convert the high-level code to TeX macros. [...]

    [...] Little by little, however, I needed more features and so the
    programming constructs grew.  Guy Steele began lobbying for more
    cpabilities early on, and I put many such things into the second
    version of TeX, TeX82, because of his urging. [...]  But the
    reason I didn't introduce programming features at first was
    because, as a programmer, I was tired of having to learn yet
    another almost-the-same programming language for every system I
    looked at; I was going to try to avoid that.  Later, I realized
    that it was sort of inevitable, but I tried to stay as close as I
    could to the paradigm of TeX as a character-by-character macro
    language.  As I said before, I was expectring that the really
    special applications would be done by changing things in the
    compiled code.  But people didn't do that; they wanted to put
    low-level things in at a higher level.
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <B5CCE8AF.7861%page@best.NOSPAM.com>
in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.14 09:11:

> ...I use programs to generate other programs all the time, and I would be
> absolutely crippled working with a language where I couldn't do that.

I certainly appreciate the value of program-writing programs in the
abstract. However, in contrast to you, I've never had to use this technique
in commercial software production (over ten years now and counting). Can you
give an example of a task that you have solved with a program-writing
program that might give me a sense of how I might want to use it?

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Craig Brozefsky
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <874s48vvyg.fsf@piracy.red-bean.com>
Chris Page <····@best.NOSPAM.com> writes:

> I certainly appreciate the value of program-writing programs in the
> abstract. However, in contrast to you, I've never had to use this technique
> in commercial software production (over ten years now and counting). Can you
> give an example of a task that you have solved with a program-writing
> program that might give me a sense of how I might want to use it?

Well, a good example of a program-writing program is any lisp macro.
I use macros quite a bit when writing production code.  Some of the
tasks I use program-writing programs for are:

* Specialized class definition macros that turn an abstract syntax into
  a program for defining a class and maintaining some other
  bookkeeping information

* Macros for turning an embedded SQL syntax into a program for
  building a tree of objects representing an SQL expression.

* A specialized language for controlling transactions which expands
  into a program which properly maintains data integrity thru the use
  of a lower level transaction management API.


-- 
Craig Brozefsky               <·····@red-bean.com>
Lisp Web Dev List  http://www.red-bean.com/lispweb
---  The only good lisper is a coding lisper.  ---
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <B5CFF088.7FE2%page@best.NOSPAM.com>
in article ··············@piracy.red-bean.com, Craig Brozefsky at
·····@red-bean.com wrote on 2000.08.26 09:16:

> Well, a good example of a program-writing program is any lisp macro.

in article ·················@mindspring.com, Lyman Taylor at
············@mindspring.com wrote on 2000.08.26 12:15:

> Lex/yacc        ( lex and yacc input files. )
> The C preprocessor ( the non trival #define's )
> m4 macro processor
> embedded SQL ( Craig mentioned in another reply about a  SQL syntax lisp
> macro, but think embedded SQL in C/Fortran/etc. is
> expanded.) 

I'm certainly aware of those examples. However, I wasn't under the
impression that Kent Pitman was talking about these kinds of systems, where
the transformation and results are internal to the macro- or pre-processor
and the compiler. I thought he was talking about writing programs that
create or transform programs, producing new source code that is maintained
apart from the original input to the macro-/pre-processor.

in article ···············@world.std.com, Kent M Pitman at
······@world.std.com wrote on 2000.08.26 11:52:

> This rewrites:
> 
> (foo bar baz)
> (alpha (beta gamma) delta)
> (1 (2 (3 4) (5 6)) (7 8))
> 
> to:
> 
> (bar foo baz)
> ((beta gamma) alpha delta)
> (1 (7 8) (2 (3 4) (5 6)))

I find this example too abstract. Perhaps I lack enough background to
understand it more concretely. I hate to keep asking, but can you provide an
example of a transformation that I could actually see my self wanting to
perform?

As I said before, I understand the value of programmatic transformations of
programs in the abstract. I'm just trying to understand why this is such an
important activity for you -- why you say you use this frequently. In my
experience this kind of task is extremely rare in commercial software
development. I'm hoping that you'll reveal something to me that I hadn't
considered, that will provide me with a new tool for solving problems that I
simply hadn't considered before.

For example, although I was not completely unaware of them, there were a
number of features of Dylan that I hadn't used or truly appreciated the
value of before being given the opportunity to use them frequently in a
language that supports them properly. For example, closures, multiple
inheritance, and multiple dispatch.

> I can't think of any equivalently concise way of rewriting Java.

I understand your point about Lisp being easier to transform
programmatically than Java. In fact I think it's almost obvious, because
Lisp has a simpler syntax.

But rather than perhaps require all future programming languages to make
easy transformation a priority language feature, I can imagine tools for
performing transformations that make it possible to describe the
transformations in a simple and deterministic fashion.

Which is to say I favor a future where computers do more of the work in
programming, as they have done for word-processing and bookkeeping.

I think you're saying something similar when you say you want to be able to
transform programs programmatically. However, I think perhaps I am expecting
computers to make it easy for you to write the transforming programs for
more complex target languages, whereas you would rather keep target
languages simple so that the transforming programs can be written without
much help from the computer.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	significant indentation?
Date: 
Message-ID: <sfwhf85qk1t.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> I find this example too abstract. Perhaps I lack enough background to
> understand it more concretely. I hate to keep asking, but can you provide an
> example of a transformation that I could actually see my self wanting to
> perform?

I translated about 20,000 lines of code written in Gold Hill Common Lisp
to ANSI Common Lisp.  The task took a small amount of weeks, but required
"correct" changes to nearly every line of code.  I had to actually look at
each place the transformations were to occur to make sure that I was doing
things right, but I spent probably about 2 seconds looking at each change
because the process of change was mostly entirely automated (by Emacs) and
all I had to do was glance at the thing, make sure it was the "expected case",
and punch the spacebar on my keyboard saying "go ahead".  Occasionally I'd
find a new case and have to stop and do something more elaborate.  But I was
never slowed down by the fact that someone just used a complex expression 
in a place I expected a simple one because in Lisp an expression is an
expression.  But in other languages, if I was wanting to swap the arguments
to some function, say GETHASH, because I knew that in dialect A the key came
second but in dialect B it comes first, then it's easy to see how a keyboard
macro which uses c-m-T to swap 

  (setq x (gethash a b))

would scale up to work for

  (setq x (gethash (this is more complex) (so is this)))

But in an infix language, c-m-T is not up to the task [nor is there another
thing which is].  Consider:

   x = gethash(a,b)

but this will be faked out by:

   x = f(g(a,b),c)

or by

   x = f(g(a,b) ? a : b, m)

becuase it requires the editor to have just a too-complex model of what's
going on.  And, by the way, the comma-separated arguments case is easy
compared to what happens in infix if I do:

   3*a*b+4
      ^
   cursor

what could c-m-T do here??  Lisp's printed form mirrors its structural shape.
Infix languages do not--they discard visible markers that would be useful to
distinguish multiple layers that are coincident on the sema text boundary after
the "helpful" reduction in textual size.  

> > I can't think of any equivalently concise way of rewriting Java.
> 
> I understand your point about Lisp being easier to transform
> programmatically than Java. In fact I think it's almost obvious, because
> Lisp has a simpler syntax.
> 
> But rather than perhaps require all future programming languages to make
> easy transformation a priority language feature, I can imagine tools for
> performing transformations that make it possible to describe the
> transformations in a simple and deterministic fashion.

You can imagine them.  But in point of fact most commercially successful
languages do not provide them, even after years of deployment.

> Which is to say I favor a future where computers do more of the work in
> programming, as they have done for word-processing and bookkeeping.

That's nice. I have no real opposition to that.  I just don't expect to live
to see it, except in the trivial sense that it seems obvious that soon people
will think they have programmed all that needs to meaningfully be programmed
and they will just "compose components" instead of programming.  This will be
horrid and clumsy and will cut off avenues of thought and creativity, but it's
not an impossible scenario.

> I think you're saying something similar when you say you want to be able to
> transform programs programmatically. However, I think perhaps I am expecting
> computers to make it easy for you to write the transforming programs for
> more complex target languages, whereas you would rather keep target
> languages simple so that the transforming programs can be written without
> much help from the computer.

Dick Waters, I think it was, observed that the nice thing about text is that
it allows one to move fluidly between levels of abstraction, picking operations
that are structural (the ESC c- commands or c-m- commands, if you like) or
operations that are line-oriented or operations that are character-oriented
as appropriate to the instant.  By requiring someone to work only structurally,
you necessarily cut off their ability to work textually; by requiring them to
work only textually, you cut off their ability to work structurally.  Lisp 
strikes a balance lost in other languages, even those with otherwise a lot of
cultural similarity, like Dylan.
From: Chris Page
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like    significant indentation?
Date: 
Message-ID: <B5D063F9.8159%page@best.NOSPAM.com>
Okay, I understand. Good comments all around.

Actually, I can provide one of my own examples. Often I'll add, remove, or
reorder the arguments for a function, requiring me to update all the call
sites. However, regular expression search/replace can often suffice, even in
an "infix" language.

In any case, this is common enough, I think, that I could see adding this
functionality to an editor, thereby making it simple for others to perform
this kind of transformation without them writing any programs. That is, even
if it's non-trivial compared to manipulating Lisp with some Lisp code, the
effort to write the code or editor macro can be leveraged, so it doesn't
matter as much that it's a more complex task to do the first time.

If a development environment were able to handle code in some internal
"parsed" representation, then I would expect that it would be just as easy
for a user to describe patterns for the transformations on Dylan, say, as it
is to describe similar transformations on Lisp in emacs macros and/or
regular expressions that operate on text. For example, to reorder two
arguments:

Search pattern:

    changed-function( \({expression}\), \({expression}\) )

Replace pattern:

    changed-function( \2, \1 )

Where "{expression}" is a token for any expression in the language, and the
rest of the patterns are in common regular expression syntax.

Since a development environment for Dylan/C/Java/Pascal/Eiffel, has to have
a parser anyway, this shouldn't take a huge effort to incorporate into the
editor.

-- 
Chris Page
Mac OS Guy
Palm, Inc.

let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
From: Erik Naggum
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <3176475011374927@naggum.net>
* Chris Page <····@best.NOSPAM.com>
| I thought he was talking about writing programs that create or
| transform programs, producing new source code that is maintained
| apart from the original input to the macro-/pre-processor.

  Why would _maintaining_ the code be a requirement for it to be a
  program written by a program?  In my view, the whole point with
  writing in a more abstract/powerful/whatever language would be to
  _avoid_ maintaining the result.

| I hate to keep asking, but can you provide an example of a
| transformation that I could actually see my self wanting to perform?

  This is a valid request, but impossible to fulfill.  I think this is
  one of those situations where if you haven't had the need for it, it
  would be nigh impossible to explain, except in the abstract.

| I'm just trying to understand why this is such an important activity
| for you -- why you say you use this frequently.

  One of the things I do all the time is to extract prototypes from C
  source code and stuff them in header files.  I used to hack C code
  with Emacs Lisp code, but various tools now exist to do this for me.
  (Of course, it's a ridiculous task -- the C system should be able to
  do this automatically and not rely on duplication of declarations.)
  The result is not maintained -- in the case of a change in the
  source files, the header files are automatically renegerated.

  If you consider makefiles to be programs, consider the boring task
  of keeping the dependencies intact.  Much of this job is done by
  tools that extract header file dependencies, understand how using a
  header file means using an object file, which means using a library.

  A long time ago, before I figured out that I didn't have to use C, I
  spent a lot of time writing Emacs Lisp code to help me figure out
  which header file to include if I wanted a particular function, and
  then automatically insert the right rules in the makefile.  Pretty
  pathetic stuff, really, when a decent programming system should have
  been able to figure out _all_ of this on its own, but, hey, that's
  Unix for you.

  Another case of software writing software is revision control
  systems that actually produce source files according to a bunch of
  criteria that are far from obvious.  Of course, this applies to
  _text_ files, not source code qua code, but I think it's worth
  mentioning because it might broaden the context enough that you find
  that you also keep doing some of this program-writing-programs stuff.

| In my experience this kind of task is extremely rare in commercial
| software development.

  Well, I'd hate to see a moderately large project maintain makefiles
  by hand, for instance.

  Incidentally, defsystems are somewhat easier to maintain than
  makefiles, but still cry out for automatic tools.  I wrote a small
  function a long time ago that helps me put together defpackage forms
  for my files, too.  No need to maintain the old code -- just discard
  the old form and recompute the new.

| But rather than perhaps require all future programming languages to
| make easy transformation a priority language feature, I can imagine
| tools for performing transformations that make it possible to
| describe the transformations in a simple and deterministic fashion.

  Hm.  I used to hear this from SGML people back in the early 1990's.
  It'll never happen.  Such tools become enormously complex if they
  are complete, and if they are complete, impossible to use, too.
  That's really why I use Common Lisp syntax for _everything_: No need
  to write (or (still) wait for, in the case of SGML, HTML, XML).  I
  think transformablity _should_ be a priority language feature.

| Which is to say I favor a future where computers do more of the work in
| programming, as they have done for word-processing and bookkeeping.

  This is interesting, because computers do _much_ less of the work in
  today's word-processing than people were actually _using_, not to
  mention working on, prior to the advent of WYSIWYG tools.

  (Accounting and book-keeping never should have involved humans in
  the first place.)

| I think you're saying something similar when you say you want to be
| able to transform programs programmatically. However, I think
| perhaps I am expecting computers to make it easy for you to write
| the transforming programs for more complex target languages, whereas
| you would rather keep target languages simple so that the
| transforming programs can be written without much help from the
| computer.

  That's just the issue: Writing the transformation program should be
  easier than doing it yourself.  The more complex and multifaceted
  the syntax, the harder that program becomes to write, and the more
  needs to be specified.  And worse, with a complex syntax, some
  transformations won't even be possible unless it had been thought of
  to begin with.  Simple, regular syntax avoids all of these problems.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Kent M Pitman
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   	significant indentation?
Date: 
Message-ID: <sfwem3bg8iu.fsf@world.std.com>
Chris Page <····@best.NOSPAM.com> writes:

> in article ···············@world.std.com, Kent M Pitman at
> ······@world.std.com wrote on 2000.08.14 09:11:
> 
> > ...I use programs to generate other programs all the time, and I would be
> > absolutely crippled working with a language where I couldn't do that.
> 
> I certainly appreciate the value of program-writing programs in the
> abstract. However, in contrast to you, I've never had to use this technique
> in commercial software production (over ten years now and counting). Can you
> give an example of a task that you have solved with a program-writing
> program that might give me a sense of how I might want to use it?

Sure.

Consider keyboard macros.  Imagine a keyboard macro that does:

 ESC C-a C-f ESC C-f ESC C-t ESC C-e ESC C-f ESC C-b 


This rewrites:

(foo bar baz)
(alpha (beta gamma) delta)
(1 (2 (3 4) (5 6)) (7 8))

to:

(bar foo baz)
((beta gamma) alpha delta)
(1 (7 8) (2 (3 4) (5 6)))

I can't think of any equivalently concise way of rewriting Java.
I'd have to do it by hand.  If I had 10,000 lines of code in which I needed
to quickly make a syntactic transformation, I could resort to SED, but I have
to say I neither trust it nor trust myself to write it nor do I think it
has anywhere close to the same power because it doesn't really understand
the syntax and can be faked out in myriad ways.  It only changes the problem
from "changing 10,000 lines" to "checking 10,000 lines for correctness", which
is almost as hard.
From: Lyman Taylor
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <39A81745.9A97C08F@mindspring.com>
Chris Page wrote:
...
> in article ···············@world.std.com, Kent M Pitman at
> ······@world.std.com wrote on 2000.08.14 09:11:
> 
> > ...I use programs to generate other programs all the time, and I would be
> > absolutely crippled working with a language where I couldn't do that.
> 
> I certainly appreciate the value of program-writing programs in the
> abstract. However, in contrast to you, I've never had to use this technique
> in commercial software production (over ten years now and counting). Can you
> give an example of a task that you have solved with a program-writing
> program that might give me a sense of how I might want to use it?

  Lex/yacc        ( lex and yacc input files. )
  The C preprocessor ( the non trival #define's ) 
  m4 macro processor 
  embedded SQL ( Craig mentioned in another reply about a  SQL syntax lisp
                  macro, but think embedded SQL in C/Fortran/etc. is 
                  expanded.) 
  
 I think the difference lies more so lies in the fact that somebody else
 wrote the program generator that you use.  Not that program generators
 aren't used by a sizable amount of the programming population. 
  
 That's partially because the difficulty level of writing the tools (and
 inserting them into the compilation process) is high enough so 
 that people don't wish to bother writing their own.  

 For instance serveral of the examples above are "read only". Or "read and
 print in a predefined format". 


Lyman
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <39963B1C.5CCAB7D2@kurtz-fernhout.com>
Kent-

Thanks for the very interesting comments. You make some excellent points
including ones about redundancy and the need for maintaining structure
in Lisp.

Still, I personally think the issue of exactly how fragile an
indentational syntax for S-expressions will be in practice is one that
might be worth some further exploration. I can point to two languages --
Occam and Python -- where syntactically significant indentation (without
block delimiters) works. Granted, these are both very different from
Lisp and Scheme in many ways.

One quibble -- I wouldn't call indentation "invisible". Indentation (to
me) indicates relationship -- and relationship is at the heart of
meaning. 

Consider for example, how long it took for zero to get accepted as a
"number" even after it was invented.
  http://users.telerama.com/~kristen/zero/zero.html
  http://www.theatlantic.com/issues/97jul/zero.htm
The argument was that "nothing" can't be a number. Before that people
actually did arithmetic in "Roman numerals" and such, because without
zero you can't use positional notation for numbers (since every slot
must have a non-zero value). And, what is positional notation, but
implicit overlapped indentation of numerals?

Quoting from that last link (from the Atlantic Monthly):
> The Greeks, Dantzig wrote, "could not conceive
> the void as a number let alone endow the void
> with a symbol." This shortcoming hampered
> Western physics, too, for well over a thousand
> years. The pre-Socratic Greek philosopher
> Democritus of Abdera put forth the idea of a
> void ("Nothing exists except atoms and empty
> space; everything else is opinion"). Plato,
> however, disagreed, and Democritus' particle
> physics was abandoned in the West until the
> Renaissance. Chris Quigg, a physicist at the
> theoretical division of the Fermi National
> Accelerator Laboratory, in Batavia, Illinois,
> says, "Nothingness is essential to physics. The
> vacuum is essential to the way we understand
> the world. Zero is a very important concept." 

So, syntactically significant indentation may be "invisible" in a way,
but just like the concept of "zero", it may be a great enabler.

And following along with the point of novel information being conveyed
by a language, I would see indentaion as the ultimate novel structural
information (for trees). It precisely and IMHO elegantly answers the
question of whether the next S-expression is to be added at the end of
the previously list, at the same level, or at the level of this list's
parent or above.

Example:

  quote
    a first list
      a child list
      a second child list
        a child of the second child list
    another list on the level of the first list
  list 'above 'the 'first 'list 

In fact, I might go so far as to say that the parentheses may obscure
the true activity of Lisp programming -- in the sense that what one is
really doing in Lisp programming is creating nested groups which are in
effect trees (and thus one rarely deals with a solitary group, except as
a leaf of a tree). Every Lisp program is a tree. Thus Lisp programming
(or S-expression construction) is really all about tree building, with
grouping supporting the tree building. When one starts thinking how to
help display trees as well as construct them, defining a hierarchial
tree by indentation seems a natural approach to me.

[True, one can build a web in Lisp or Scheme, and use it as a program,
but I don't imagine this is done in practice in many programs.] 

Having said all that, I would certainly agree with the sentiment of many
that editors and communication channels often do unexpected things to
whitespace which might change the meaning of structures defined by white
space. I hope this issue could be overcome, but it definitely is a
practical problem -- one that Python struggles with (especially
regarding inconsistent tab expansion / compression).

-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

Kent M Pitman wrote:
> 
> Dan Schmidt <····@harmonixmusic.com> writes:
> 
> > You look at the
> > rules and think that it would be a huge mess, but in practice it does
> > an excellent job of doing the Right Thing.
> 
> This is a situation in which "The Right Thing" cannot possibly apply.
> There is no "Right Thing" when it comes to representing all possible
> expressions, which is what programming languages are about.  You have
> to narrow your remarks to presuppositions about the kinds of programs
> you typically expect and/or want to encourage in order to know what's
> even statistically right for the given constraints.
> 
> As a rule, languages which are about writing an expected set of things
> (such as COBOL, where you can probably write some very typical expressions
> that are typical of all programming in COBOL because the typical
> application domain is constrained), are going to lend themselves to
> notations that are "statistically good" for some set of things.  But Lisp
> is often about writing programs to handle "the unexpected" and when you
> make your notation biased toward what you expect people to write, you
> risk making certain programs hard.
> 
> As a linguistics professor of mine, the late Bill Martin, used to say,
> "languages aren't about saying what is expected, but about what is
> not".  He would go on to say that if "cheese mouse eat" was enough as
> just a sequence of words to mean "the obvious thing" then there would be
> no need for syntax.  Just the words and their obvious meaning would be
> enough.  But languages are about being able to express complex
> situations like "the cheese ate the mouse", and that's why we have complex
> syntax.
> 
> In Lisp, grouping is a huge part of what it is.  And so to carry
> grouping in an "invisible" notation (indentation), rather than to
> emphasize it, gives short shrift to its importance and risks that when
> subtle differences in grouping really matter, they will likewise be
> invisible and/or hard to achieve.  One wants to be able to easily see
> not only the expected things, but the unexpected, and that's what Lisp
> syntax allows in a relatively domain-neutral way.
> 
> Grouping is SO IMPORTANT in Lisp, in fact, that we not only mark it
> with (...), but we ALSO make whitespace unimportant so that in
> practice it can be used to UNDERSCORE the paren level, providing a
> level of redundancy to emphasize paren grouping, making it possible to
> catch paren errors.  Carrying the information on only one channel
> would make the language too fragile.  It's only by using parens AND
> indentation AND auto-paren-flashing that we get the level of checking
> that is commensurate with the importance of the information being
> conveyed.
> 
> In fact, while I'm on the topic of grouping, Martin sometimes conjectured
> when we were working with his XLMS system for representing linguistic
> relationships that it was only "shape" of information that mattered and
> that the actual meaning of the terms didn't matter once you really got
> everything connected in the right way.  (That is, if an alien race made the
> web of connections from our dictionary and came up with a consistent meaning
> to all the terms as described merely by their connectivity, it sort of wouldn't
> matter if their understanding was "correct" as long as it was "predictive"
> and "ever consistent".  In fact, there'd be no way to find out if any one of
> us had a similar "error" in understanding as long as all of our reasoning
> processes worked self-consistently.)  If you believe any of this, then a
> consequence is, again, that it's "grouping" and "connectivity" that are the
> foundations of knowledge, and consequently you can at least understand why
> some among us (myself included) would think they were poor choices for
> using the fragility of mere indentation to carry such important semantics.
From: David Bakhash
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like   significant indentation?
Date: 
Message-ID: <m31yzsvczr.fsf@cadet.dsl.speakeasy.net>
Paul Fernhout <··········@kurtz-fernhout.com> writes:

> Consider for example, how long it took for zero to get accepted as a
> "number" even after it was invented.

Yeah.  Now consider the parens to be analogous to zero in the natural
numbers.  How would you feel if they wanted to take zero away?

dave
From: Dan Schmidt
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant indentation?
Date: 
Message-ID: <wkg0o71tn0.fsf@turangalila.harmonixmusic.com>
Kent M Pitman <······@world.std.com> writes:

| Dan Schmidt <····@harmonixmusic.com> writes:
| 
| > [regarding Haskell's use of indentation]
| > You look at the rules and think that it would be a huge mess, but
| > in practice it does an excellent job of doing the Right Thing.
| 
| This is a situation in which "The Right Thing" cannot possibly apply.

It's unclear to me whether you're disagreeing with one or more
particular aspects of the way Haskell uses indentation to denote
program structure, or making a general statement about programming
languages.  The rest of your post went on to talk mostly about Lisp.

If the former, I'd be interested to hear in what specific ways you
think Haskell fails to achieve its goals.

I did agree, in the part of my post that you snipped, that indentation
being meaningful is a bad idea for Lisp.

-- 
                 Dan Schmidt | http://www.dfan.org
Honest Bob CD now available! | http://www.dfan.org/honestbob/cd.html
From: Paul Fernhout
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <399630E5.18C2858A@kurtz-fernhout.com>
Dan-

Thanks for the comments and the pointer to Haskell.

-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

Dan Schmidt wrote:
> 
> I agree with a lot of the posters in this thread that
> indentation-signficance is not a good idea for Lisp (though I think
> it's great in Python).
> 
> That said, you may want to take a look at the functional language
> Haskell, which allows the programmer to specify structure explictly
> with parentheses or implicitly with indentation.  You look at the
> rules and think that it would be a huge mess, but in practice it does
> an excellent job of doing the Right Thing.
> 
> --
>                  Dan Schmidt | http://www.dfan.org
> Honest Bob CD now available! | http://www.dfan.org/honestbob/cd.html
From: Seth Gordon
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like  significant indentation?
Date: 
Message-ID: <399ABD5A.F3F9D33F@kenan.com>
There's a problem with this scheme (ahem) that, as far as I can tell, has
not been mentioned yet.

Let's say, for argument's sake, that an indentational Lisp syntax (i-syntax)
becomes somewhat popular.  We will then have two factions of Lisp
programmers -- those who use indentational syntax, and those who use
parenthesized syntax (p-syntax).

If, then, someone who uses one syntax posts a code sample on comp.lang.lisp
(or shares it in some other forum -- maybe scribbling it on the whiteboard
at a staff meeting), then the readers who use the other syntax will have to
convert it before understanding what's going on.  Since most Lisp
programmers spend far more time reading code in their preferred syntax than
in the other syntax, most will never become fluent in the conversion
process.

("Is that line an atom, the head of a list, or a list with one item?  What's
that dot doing there?...  That doesn't make sense -- maybe the original
poster hadn't tested this code and there's a syntax error....  Dang, what's
the URL for the i-syntax spec?...")

The i-syntax is intended to make Lisp easier to learn.  Therefore, in the
early stages of its popularity (if it ever becomes popular), the users of
i-syntax will tend to be novices.  But if an i-syntax user posts a question
with a code sample on comp.lang.lisp (or some other forum), then the number
of educated people willing to respond is capped by the number of people who
are either familiar with i-syntax or are willing to convert the code sample
to p-syntax.  Based on the traffic in this thread, I suspect that number
will be small.

And if someone answers the question, or illustrates another point, by
posting sample code in p-syntax, then the i-syntax users will have to
convert the code to i-syntax before using it in their own programs.
Likewise, i-syntax users will have to deal with dead-trees textbooks full of
sample code, which is all in p-syntax.  And people who write Lisp code
*professionally* will have to deal with other Lisp programmers (most of whom
would be using p-syntax), or Lisp code that other people wrote (which would
almost certainly be in p-syntax).

(Obviously, we can use programs to convert between i-syntax and p-syntax.
But if i-syntax is only useful when there are conversion tools available,
then you might as well treat it as a hack within the editor rather than an
extension to Lisp syntax itself.)

So i-syntax may postpone the Lisp novice's encounter with Lots of Insidious
Silly Parentheses, but cannot prevent it, and even the postponement comes at
a great practical cost.  Any Lisp novice, as soon as he or she realizes this
fact, will either buckle down and learn p-syntax, or abandon Lisp.  Either
way, i-syntax is unlikely to gain users.

I think it would be interesting, as a *presentation* issue, to change the
color of a parenthesis in Lisp code when the matching parenthesis is on a
different line.  (One could even use a variety of shades to indicate
different levels of parenthesis-distance.)  However, for all the reasons
discussed in this thread, the i-syntax scheme is a lost cause.

(This CAR and CDR nonsense, on the other hand, is a serious obstacle to
Lisp's market share....  :-)

--
--Why is it that most kids are attracted to computers while
  most adults are quite wary of computers?
--Most adults are smarter than most kids. ["Ask Uncle Louie"]
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
From: Marco Antoniotti
Subject: Re: RFC: Lisp/Scheme with less parentheses through Python-like significant   indentation?
Date: 
Message-ID: <y6cvgwk6r2a.fsf@octagon.mrl.nyu.edu>
Paul Fernhout <··········@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.

Why replace something that makes the language free form with something
that makes it look like you are still using ForTran columned format?

> 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.

That is because you are not using useful editors.
M-C-q is all you need.  Tab als already work.

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

If you use a proper editor (and you do not have much choice here :) )
you already have all the indentation you need.

OTOH if you slip an extra space in your Python program you are screwed
big time.

> 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.

Exactly.  I don't see the parenthesis.

> 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.

You should worry about the editor you are using. :)

> 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.

Exactly.

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

	... much deleted ..

> 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?

That what a good editor does for you.

> 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

I must apologize in advance for my bluntness and my admitted lack of
good humor and politeness today :)  BUT, from your post I infer
(probably wrongly) that:

1 - you are moslty a Python programmer
2 - your exposure to Lisp comes from Scheme
3 - you are *not* using THE good editor you should use.

Finally the question I have is: why not try to program someting
significant with Common Lisp using the best tools available bofeore
embarking on an entropy augmenting effort? :)

Cheers

-- 
Marco Antoniotti =============================================================
NYU Bioinformatics Group			 tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                          fax  +1 - 212 - 995 4122
New York, NY 10003, USA				 http://galt.mrl.nyu.edu/valis
comp.lang.lisp / 2000 / aug