From: Richard Lynch
Subject: Re: Matching Parens (was Virtues of LISP Syntax?)
Date: 
Message-ID: <12676@accuvax.nwu.edu>
>>I sez:
>>  I like to make closing parens be on the same line or straight below the
>>  opening paren.

>·····@media-lab.MEDIA.MIT.EDU (Steve Strassmann) sez
>Nothing personal, but I hope you're all alone.  If people paid half as
>much attention to their user interface as they did to their compilers,
>we wouldn't have to deal with silliness like this.
>
>Perhaps you should be using an editor like emacs that comes with some
>smarts about traditional lisp formatting. For me at least, the
>indentation of the immediately following line tells me all I need to
>know about any close-parens.
>
>For example, in lisp-mode in many versions of emacs, <tab> indents a
>given line, and <C-M-q> indents a given s-expression. Typing a close
>parenthesis blinks the corresponding open parenthesis. <C-M-f> and
><C-M-b> take you back and forth over a given s-expression so you can
>see its beginning and end.

Just for the record, I *AM* using an EMACS-like editor (FRED:  Fred
Resembles Emacs Deliberately) as described in another follow-up.  It goes
emacs one better by flashing the matching paren on and off AUTOMATICALLY
when the cursor is at a paren.  This means you don't have to ALTER code to
INSPECT it which seems barbaric (though admittedly trivial) to me.  Nor do
you have to memorize arcane keyboard commands to see a whole expression.  A
double click on a closing paren will hightlight the entire form.

<FLAME ON>
As far as interface goes, *I'M* using a Mac where more thought has gone
into the interface than went into the whole compiler of most other systems.
<FLAME OFF>

What precisely is silly about having clear, concise, simple, FOOLPROOF
rules about where a matching paren can be found?  Can you look at a
print-out of your code (that is NOT debugged and MAY contain parenthesis
errors) and immediately tell me where any given form is closed?  I can for
mine.  Of course you have to indent as well, but a lot of times in writing
code that is long, tedious, and too dissimilar to turn into a function or
macro (such as code that draws a lot of slightly different objects in a
program that pays plenty of "attention to [my] user interface"), the forms
that are being lined up may well be several screenfuls away from each
other.

[A *LONG* time ago I was using SPF on an IBM mainframe.  It allowed you to
HIDE as many lines as you wanted (without deleting them, mind you) so that
you could ignore the sections that you "knew" were right, and line up and
concentrate on the rest.  The hidden lines would be replaced by a single
line with the text "XXXXX lines hidden" in its place.  Would love to see
this feature on my FRED editor in MACL.  Anybody write this yet?]

"TANSTAAFL" Rich ·····@aristotle.ils.nwu.edu

From: Mark Rosenstein
Subject: Re: Matching Parens (was Virtues of LISP Syntax?)
Date: 
Message-ID: <MBR.90Sep28095128@ponape.flash.bellcore.com>
In article <·····@accuvax.nwu.edu> ·····@aristotle.ils.nwu.edu (Richard Lynch) writes:

   Path: bellcore!bellcore-2!rutgers!mailrus!accuvax.nwu.edu!mmdf
   From: ·····@aristotle.ils.nwu.edu (Richard Lynch)
   Newsgroups: comp.lang.lisp
   Date: 27 Sep 90 18:44:43 GMT
   Sender: ····@accuvax.nwu.edu
   Lines: 52

   <FLAME ON>
   As far as interface goes, *I'M* using a Mac where more thought has gone
   into the interface than went into the whole compiler of most other systems.
   <FLAME OFF>
--Total aside ----
Error messages from the Symbolics compiler, and their use of the
error system are quite impressive. For instance I make package errors
often enuf so that when the debugger says, symbol not found. And then
asks to use symbol in so-and-so package, man life is wonderful!
--End total aside--
   What precisely is silly about having clear, concise, simple, FOOLPROOF
   rules about where a matching paren can be found? 
Parens really aren't very interesting. To my mind code has a shape, that
my editor (GNU) supports. "If" looks like
   (if (some-test)
       (yep-its-true)
       (nope-guess-again))
If it doesn't look like that well something's wrong. Defuns look like
   (defun hi-ima-function (some-arg some-other-arg &rest etc)
      (first-form)
      (second-form)
      (when (some-test)
        (do-some-stuff))
      etc)
[I'm not in lisp mode and my defun isn't in the first line, so I'm
really not sure how many spaces m-c-\ would really put in, but I hope
you get the idea].

   Can you look at a
   print-out of your code (that is NOT debugged and MAY contain parenthesis
   errors) and immediately tell me where any given form is closed? 
Sure. It'll be indented wrong. First thing I do when I look at someone
elses code is run formating over it. Otherwise its just characters.
   I can for
   mine.  Of course you have to indent as well, but a lot of times in writing
   code that is long, tedious, and too dissimilar to turn into a function or
   macro (such as code that draws a lot of slightly different objects in a
   program that pays plenty of "attention to [my] user interface"), the forms
   that are being lined up may well be several screenfuls away from each
   other.
I guess this is a stylistic point, but functions over a page make me
queezy. I guess I'm not embarrased to write a function or macro that'll
only be called once. I find that once I free the functionality, along
comes some other piece of code that wants it.
   [A *LONG* time ago I was using SPF on an IBM mainframe.  It allowed you to
   HIDE as many lines as you wanted (without deleting them, mind you) so that
   you could ignore the sections that you "knew" were right, and line up and
   concentrate on the rest.  The hidden lines would be replaced by a single
   line with the text "XXXXX lines hidden" in its place.  Would love to see
   this feature on my FRED editor in MACL.  Anybody write this yet?]
I guess I do all my hidden stuff in lots of little functions. And
(slight sarcastic voice) I don't have all those empty lines with only
parens on 'em), so my code may be more compact?
Maybe it is all style, but first thing I'd do with the code you sent
me is write a little GNU macro to move all them parens up. 

Mark.
From: Jeff Dalton
Subject: Re: Matching Parens (was Virtues of LISP Syntax?)
Date: 
Message-ID: <3473@skye.ed.ac.uk>
In article <·····@accuvax.nwu.edu> ·····@aristotle.ils.nwu.edu (Richard Lynch) writes:

>>>  I like to make closing parens be on the same line or straight below the
>>>  opening paren.

>>·····@media-lab.MEDIA.MIT.EDU (Steve Strassmann) sez
>>Nothing personal, but I hope you're all alone.  If people paid half as
>>much attention to their user interface as they did to their compilers,
>>we wouldn't have to deal with silliness like this.

>Just for the record, I *AM* using an EMACS-like editor

Clearly, a good editor is (almost) necessary, but not sufficient.
If you think it's important to be able to find close parens when
reading code, you'll want them to stand out.  But if you want to
bwe able to avoid having to pay much attention to parens when
reading code, you'll want them to be less conspicuous.  At least
that's my view of it.

>This means you don't have to ALTER code to INSPECT it

Do I have to alter code in Emacs?  Not the last time I checked...

><FLAME ON>
>As far as interface goes, *I'M* using a Mac where more thought has gone
>into the interface than went into the whole compiler of most other systems.
><FLAME OFF>

Which is not to say that more thought has gone into the *Lisp*
interface (nor is it the case that more thought = better).

>What precisely is silly about having clear, concise, simple, FOOLPROOF
>rules about where a matching paren can be found?  Can you look at a
>print-out of your code (that is NOT debugged and MAY contain parenthesis
>errors) and immediately tell me where any given form is closed? 

Of course not, and neither can you.  If the code contains parenthesis
errors, the form may not be closed at all.  

Perhaps what you mean is that you can see where the close paren
*should* be.  Well, so can I: on the last line of the form.

But maybe you want to know exactly which paren, not just which line.
That may matter to you, because you want close parens for multi-line
forms to stand out.  Since I *don't* want them to stand out (because
it gets in the way when reading), the "exact location" problem doesn't
matter much to me.

Indeed, one of the main points of proper indentation is to make it
unnecessary to *read* parens.  I agree with ···@breeze.bellcore.com
(Mark Rosenstein), who writes in <·················@ponape.flash.
bellcore.com>:

   Parens really aren't very interesting. To my mind code has a shape,
   that my editor (GNU) supports.

Besides, you're assuming I have to *debug* my code in order to find
paranthesis errors.  It's really a question of editing, rather than
debugging.  If I think some code has wrong parens, I ask my editor
to reindent it; and that shows me what goes with what.

>     Of course you have to indent as well, but a lot of times in writing
>code that is long, tedious, and too dissimilar to turn into a function or
>macro (such as code that draws a lot of slightly different objects in a
>program that pays plenty of "attention to [my] user interface"), the forms
>that are being lined up may well be several screenfuls away from each
>other.

And when you get to then middle of the thrid screen and see

        )

all on a line of its own, it what way are you better off than I am?
I don't see what your point is.

>[A *LONG* time ago I was using SPF on an IBM mainframe.  It allowed you to
>HIDE as many lines as you wanted (without deleting them, mind you) so that
>you could ignore the sections that you "knew" were right, and line up and
>concentrate on the rest.  The hidden lines would be replaced by a single
>line with the text "XXXXX lines hidden" in its place.  Would love to see
>this feature on my FRED editor in MACL.  Anybody write this yet?]

This is a good example of how an editor can help you to write
unreadable code or, at best, code that can be read only with a
similar editor.  

It's also an example of the kind of coding style that arises in
situations in which a procedure call is regarded as expensive and
where people haven't learned to think in terms of small procedures.

-- Jeff
From: Todd Kaufmann
Subject: Re: Matching Parens (was Virtues of LISP Syntax?)
Date: 
Message-ID: <TOAD.90Oct4150501@MADRID.MT.CS.CMU.EDU>
   <FLAME ON>
   As far as interface goes, *I'M* using a Mac where more thought has gone
   into the interface than went into the whole compiler of most other systems.
   <FLAME OFF>

Well, I think you lose here, and are wrong.  I used to be as attached to a
lisp-machine-like editor.  Unfortunately, all it did was keep me from
discovering GNU Emacs.  (``Amen, brother!''  ``tell it like it is!'')

   [A *LONG* time ago I was using SPF on an IBM mainframe.  It allowed you to
   HIDE as many lines as you wanted (without deleting them, mind you) so that
   you could ignore the sections that you "knew" were right, and line up and
   concentrate on the rest.  The hidden lines would be replaced by a single
   line with the text "XXXXX lines hidden" in its place.  Would love to see
   this feature on my FRED editor in MACL.  Anybody write this yet?]

I use this feature in GNU Emacs, for CL and Elisp (although it can work on
arbitrary buffers); it's really nice.  Also, it has some idea of levels, so
you can see one line/per page, open to see top-level comments, defuns, etc.

For example, here's what a 200-line file of mine might look like as some point
when I'm hacking on it:

   ;;; -*- Mode: Lisp -*-

   ;;;% Header ...

   ;;;% Object definition ...

   ;;;% Global parameters controlling panner behavior ...
   ;;;% Draw method for a panner ...

   ;;;% special proc for a link: ...

   #| ...
   |#

   (defun draw-link-scaled (link x0 y0 tx ty scale) ...

   ;;;% click action for a panner ...

   ;;;% Create a panner instance in the current window ...

   ;;;% add the command to the menu ...


Although it could just as easily a 100K file, with an arbitrary amount hiding
in the "...".  Just as you can move up & down lists, you can move up and
levels, and expand and contract on levels or arbitrary regions.


Just one more reason...