Path: utzoo!attcan!uunet!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: Matching Parens (was Virtues of LISP Syntax?) Message-ID: <3473@skye.ed.ac.uk> Date: 1 Oct 90 17:17:38 GMT References: <12676@accuvax.nwu.edu> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 91 In article <12676@accuvax.nwu.edu> lynch@aristotle.ils.nwu.edu (Richard Lynch) writes: >>> I like to make closing parens be on the same line or straight below the >>> opening paren. >>straz@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... > >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. > 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 mbr@breeze.bellcore.com (Mark Rosenstein), who writes in : 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