Re: Specialized input parsing for code/REPL in DrScheme?

[John Clements <clements@cs.rice.edu>]

At 10:41 -0500 2000-08-10, Shriram Krishnamurthi wrote:
>Paul,
>
>There have been lots of efforts to create "less parenthesized"
>Schemes.  (Rob Warnock, who should be on this list, made a valiant
>attempt not very long ago.)  Most die painful deaths.  I don't,
>however, know that anyone has gone down the indentation-is-significant
>route.  I'm certainly interested in seeing the results.

I agree that this is an interesting project, and I'm quite sure that 
what you're describing could be done entirely in Scheme.

On the other hand, I'm really puzzled by the project itself.  Here 
are what I see as the benefits of such a parser:

1) easier on the eyes (for the "parenthetically challenged").

2) makes Scheme more terse.

3) spares the "9" and "0" keys on your keyboard.

Rebuttals to benefits:

1) The eyes get used to the parentheses.

2) Goodness, Scheme is already extremely terse.

3) ... key remapping?

Disadvantages:

1) Currently, the tabbing, as a derived piece of information, serves 
as extremely valuable syntax-debugging info.  Who among us has not 
hit (TAB) in emacs and discovered a missing ), }, or what have you. 
Your scheme would remove that environmental feedback.

2) I'm really not sure it saves a lot of keystrokes. Let's say that 
you have an editor that by default begins a line in the same column 
as the prior one.  Let's further assume, for the programmer's 
convenience, that there are some kind of indent and unindent keys 
that jump left or right to line up with later columns (this saves the 
programmer having to hit the delet^H^H^H^H^Hbackspace key all the 
time).  What's the net effect? Well, you save exactly one keystroke 
on every line that would have ended with close-parens matching 
opening ones on the same line.  On the other hand, you incur one 
extra keystroke for every line which would have had open parens which 
were not closed.

In other words, you save a whole bunch of keystrokes if your program 
contains a long sequence of one-line expressions.  On the other hand, 
a more functional style of programming would be penalized by this 
parser. I'd like to think that my programs tend to fall into the 
latter category.

3) In your parser, it's a lot harder to navigate with sexp-forward 
and sexp-back and sexp-cut keys.  Once you have these keys under your 
belt, it's hard to live without them.   For one thing, an edit 
sequence which contains nothing but these keys (+ paste) is 
guaranteed to take a balanced s-expression to a balanced 
s-expression. In order to supply these in your editor, the editor 
itself would have to do a whole lot of work.


In short, I guess I think it's a bad idea.  It's funny; the classic 
computer science mantra is "don't make the user do work that the 
computer could do for you", and yet in the syntax department, Scheme 
refutes that principle utterly.  However, I think it's the richer for 
it.


Anyhow, that's the way I (biased as heck) see it.

john clements

ps: How about this for an alternate editor idea: twist-up/down 
triangles that show or hide whole s-exp tree branches?  Frontier and 
the Mac OS (and just about every other file manager and outline 
editor on the planet) use this idea.  This could make it easier to 
navigate and edit large blocks of scheme code.