What is the reason Lisp code is not written with closing parenthesis on new lines?
michele
Example:
(defn myfn-a [a b]
(if (zero? b)
a
(recur
(afn (bfn (...)) a)
(dec b))))
(defn myfn-b [a b]
(if (zero? b)
a
(recur
(afn (bfn (...)) a)
(dec b)
)
)
)
Phil Hagelberg
> Wouldn't that make it easier to keep track of them.
It would make it easier for people to keep track of them. However,
keeping track of parentheses is not something people should be doing
since it's menial, repetitive, error-prone work. Computer programs are
much better at tasks like that.
-Phil
Sean Corfield
> (if (zero? b)
> a
> (recur
> (afn (bfn (...)) a)
> (dec b)
> )
> )
> )
I started out trying to do that but it ended up being far more work
that it was worth - as Phil said, computer programs (IDEs / editors)
do this much better. If you're using an IDE that auto-closes /
auto-deletes forms, you really don't need to think about parentheses
at all.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Nicolas Oury
only one parens.
At least for me.
There is no law. Do what is best for you.
You might, or not, change your mind when you have more practice with
all those parens.
Marc Spitzer
> On Wed, Aug 18, 2010 at 2:09 AM, michele <michel...@gmail.com> wrote:
>> (defn myfn-b [a b]
>> (if (zero? b)
>> a
>> (recur
>> (afn (bfn (...)) a)
>> (dec b)
>> )
>> )
>> )
>
> I started out trying to do that but it ended up being far more work
> that it was worth - as Phil said, computer programs (IDEs / editors)
> do this much better. If you're using an IDE that auto-closes /
> auto-deletes forms, you really don't need to think about parentheses
> at all.
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies, Inc. -- http://getrailo.com/
> An Architect's View -- http://corfield.org/
>
Also it adds up, you end up seeing much less code on your screen that way.
marc
--
Freedom is nothing but a chance to be better.
--Albert Camus
The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher
Brian Goslinga
the code. You do not want to be focusing on the parentheses, you want
to be focusing on the structure of the code. The idiomatic lisp
formatting style uses indentation to reveal the large scale structure
of the code, and so the parentheses can be neatly tucked away. With a
little experience, the parentheses will start to fade from view.
Additionally, putting them on separate lines waste vertical space, and
you should be using an editor that supports paren matching so you
don't need to count them.
Daniel E. Renfer
Generally, when I am working on a function, I will put the closing
parens anywhere with a ton of whitespace all around. Once I'm done with
the function, I make sure to delete all of the excess breaks so that
it's a nice neat block of code.
Using paredit in emacs makes it really easy to handle the closing
parens. I'm sure there are other good tools for the other editors.
Tim Daly
First, "code density", that is the number of
(/ number-of-lines-of-code number-of-lines-on-screen) should
approach 1 so that every line on the screen is code.
Second, real editors paren-bounce to show matching parens.
Third, "real lispers" don't exit the thought process until the
s-expression is complete :-)
Tim Daly
Greg
You may be interested in this link:
http://gregslepak.posterous.com/on-lisps-readability
There is much discussion about this topic there.
Cheers,
Greg
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Alan
myfn-a, because you've indented it correctly I can easily tell that
(dec b) is the second argument to recur, without looking at the
parentheses at all. Isolating close-parens would probably help a
little with this task, but the loss of screen real estate would far
outweigh the gains.
Without the indentation to help, indeed we would be lost in a sea of
parens and it might be necessary to put one on each line; but as Phil
points out, computers are better at that than we are, so we can leave
the parentheses as an "implementation detail" and work on top of the
indentation-based abstraction emacs (or whatever IDE) offers us.
Michael Gardner
> http://gregslepak.posterous.com/on-lisps-readability
That article is dishonest. The author changes indentation widths between examples, while focusing entirely on the trailing-parens. He claims in a comment that "the post is not solely about trailing parenthesis", but there's only one passing remark about 2-space indentation in the whole article. (I personally use 4-space indents precisely because they make code easy to parse at a glance.)
Greg
> On Aug 18, 2010, at 1:38 PM, Greg wrote:
>
>> http://gregslepak.posterous.com/on-lisps-readability
>
> That article is dishonest.
Speaking as the author, I'm a bit offended.
Yes, the indentation width was changed, and this was acknowledged both in the post and in the comments, but you seem to conveniently ignore everything else that was said.
Increasing the default indentation width does improve readability, but readability is still further improved by trailing parens, for the multitude of reasons the article mentions.
- Greg
> The author changes indentation widths between examples, while focusing entirely on the trailing-parens. He claims in a comment that "the post is not solely about trailing parenthesis", but there's only one passing remark about 2-space indentation in the whole article. (I personally use 4-space indents precisely because they make code easy to parse at a glance.)
>
Meikel Brandmeyer
Am 18.08.2010 um 11:09 schrieb michele:
> (defn myfn-a [a b]
> (if (zero? b)
> a
> (recur
> (afn (bfn (...)) a)
> (dec b))))
>
> (defn myfn-b [a b]
> (if (zero? b)
> a
> (recur
> (afn (bfn (...)) a)
> (dec b)
> )
> )
> )
I find it interesting, that people find the latter easier to read. In particular because the closing parens are now much farther away from their opening counterparts. For me, this is much harder to align. As others already said: I go mostly by indentation. When the auto-indentation is not what I expect, I did something wrong. I think in the end, it's the combination of auto-indentation, paren-match when editing, rainbow parens and small functions (where the number of parens stays in a reasonable number) that does the trick for me. Lisp syntax really isn't around the parens. But you can waste a lot of time, discussing where to place them. Just as much as you can waste time on the placement of {} in C. We should move on.
Sincerely
Meikel
Greg
> (MyFactory somearg
> )
> which makes me cringe.
That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line.
Trailing parens are placed only for certain blocks that traditionally would define a "scope" in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over "much loved C style" to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code.
Again, the link goes much more into depth on this.
Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this).
The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width.
- Greg
Greg
Just simply giving reasons for why some prefer one style over another. It's a personal thing, and I do not wish to engage in a flame war over it.
Best,
Greg
> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>
>> A more serious answer is that when I code in Java I use the
>> brace-on-a-line kind of indentation. When I code in Lisp I
>> never write single-line parens of any kind.
>>
>> I find that I think differently in each language.
>>
>> My Java code is always a pile of declare-this, do-this, do-this, return
>> Thus I find that I'm delimiting the scope of my variables, marking my
>> control flow and branching logic, try/catch logic, class boundaries, etc.
>>
>> My Lisp code mixes control flow and data structures in the same syntax.
>> Thus the idea that parens are some kind of control flow delimiter is
>> not particularly meaningful.
>>
>> To see the alternative case, take a Java program, find every function call
>> such as:
>> MyFactory(somearg);
>> throw away the ';', and move the paren left to get:
>> (MyFactory somearg)
>>
>> Now the question you're asking is, why don't lispers write
>> (MyFactory somearg
>> )
>> which makes me cringe.
>>
>> A second reason is that Lisp allows you to think things that Java
>> does not. Java has this imperative, object-oriented, hierarchical
>> style of writing. My lisp code sytle varies to fit the problem.
>> Sometimes it is imperative, sometimes functional, sometimes OO,
>> sometimes snobol-like pattern matching, sometimes class-based.
>> Occasionally I dynamically construct the code and execute it inline.
>> Or I use macros to create my own problem language and code in that.
>> And I create my data structures "on the fly" inline to the code.
>>
>> Once you really internalize lisp there are no real constraints
>> on what you think or write. Thus there is no question of "bracing
>> style" that is meaningful.
>>
>> The whole idea of "bracing style" is Java-think. Your language
>> choice has given you an OO-procedural mindset. So when you reach
>> for Lisp you want to see what you have come to expect. People who
>> work with bricks (Java) tend to wonder why they don't find bricks
>> among people who work with modelling clay (Lisp). The answer isn't
>> in the material, it is in your mindset.
>>
>> Just by looking at lisp code I can tell what your native language
>> is. Fortran programmers simulate COMMON blocks, C programmers use
>> things as pointers, etc. "You can write Fortran in any language"
>> is a famous quote but "you can't write Lisp in any language". And
>> you can quote me on that. (But only in my obituary :-) )
>>
>> In fact, I think that this is going to be the hardest barrier
>> to the adoption of Clojure. "Real Java Programmers" are not going
>> to like the bracing style (or lack thereof) in Clojure.
>>
>> Tim Daly
> <Screen shot 2010-08-18 at 1.32.09 PM.png>--
Phil Hagelberg
> Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this).
Again, that's quite a straw man--the attached code uses tabs for
indentation, (ick!) and you're viewing it with a different tab-stop
setting. It's also several times longer than reasonable.
-Phil
Joop Kiefte
find a lot easier to read: I don't need to scan all the page to find
what belongs where...
2010/8/18 Greg <gr...@kinostudios.com>:
> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>
>> A more serious answer is that when I code in Java I use the
>> brace-on-a-line kind of indentation. When I code in Lisp I
>> never write single-line parens of any kind.
>>
>> I find that I think differently in each language.
>>
>> My Java code is always a pile of declare-this, do-this, do-this, return
>> Thus I find that I'm delimiting the scope of my variables, marking my
>> control flow and branching logic, try/catch logic, class boundaries, etc.
>>
>> My Lisp code mixes control flow and data structures in the same syntax.
>> Thus the idea that parens are some kind of control flow delimiter is
>> not particularly meaningful.
>>
>> To see the alternative case, take a Java program, find every function call
>> such as:
>> MyFactory(somearg);
>> throw away the ';', and move the paren left to get:
>> (MyFactory somearg)
>>
>> Now the question you're asking is, why don't lispers write
>> (MyFactory somearg
>> )
>> which makes me cringe.
>>
--
Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004
Demandoj en aŭ pri Esperanto? Questions about Esperanto? Vragen over
Esperanto? Perguntas sobre o Esperanto? - http://demandoj.tk
Sean Corfield
But the indentation is broken in that code already. If the indentation
were fixed (and the long functions refactored) it would be a lot more
readable. In order to reformat it with trailing parens, you'd have to
fix the basic indentation first anyway...
In the blog post's example, I found the println 'parent' straight away
and the extra vertical whitespace didn't help (sorry but lone closing
parens just create vertical whitespace for me).
I did find the 4 char indents easier to read than the 2 char indents.
I wish CCW respected the "displayed tab width" setting as its
indentation in strict structural mode as I'd rather have 4 spaces than
2 but it seems 2 is pretty much the standard around here?
> The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width.
The readability of the attached screenshot is due to broken
indentation and the function being too long, IMO.
(and, for background, I'm far more used to programming in C-style
languages even tho' my Lisp usages dates back to the early 80's - but
I do find I naturally settle into a different style in Lisp to what I
use elsewhere)
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Michael Gardner
> On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote:
>
>> On Aug 18, 2010, at 1:38 PM, Greg wrote:
>>
>>> http://gregslepak.posterous.com/on-lisps-readability
>>
>> That article is dishonest.
>
> Speaking as the author, I'm a bit offended.
Too bad. If you wanted to focus on the trailing-parens (which you clearly did in that article), you should have kept everything else the same between your examples.
If you wanted to comment on indentation as well, you should have (a) given it equal prominence in your discussion, (b) used separate code examples for trailing-parens vs indentation, and/or (c) made a separate post.
Closing the comments after people started to question you on this wasn't a good move, either (otherwise I'd be commenting there rather than here).
Tim Daly
Greg wrote:
>> Now the question you're asking is, why don't lispers write
>> (MyFactory somearg
>> )
>> which makes me cringe.
>>
>
> That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line.
>
> Trailing parens are placed only for certain blocks that traditionally would define a "scope" in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over "much loved C style" to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code.
>
In lisp it is functions all the way down. Defining functions
that introduce "scope" and having them outdent is odd.
Some of those functions could be macros which introduce
lexical or dynamic scope. Should functions that are macros
use outdenting? Maybe some should, such as (with-open-file...)
but I often have macros that introduce binding blocks yet they
appear to the user to be a function. (e.g. the MyFactory macro)
"Scope" is a very slippery concept in a language like lisp.
Where it does occur in obvious cases (e.g. a "let") you'll
find that lispers universally indent their code, just like everyone else.
> Again, the link goes much more into depth on this.
>
Yes, I read the link. I'm going to hazard a guess that lisp is not your
native language :-)
> Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this).
>
> The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width.
>
Well, if all else fails, try (pprint your-expression) and see what the
canonical version is.
The modelling clay (lisp) doesn't care, it reflects the shape of your
thoughts.
If you want brick shapes (java), the lisp reader won't care.
Your claim seems to be that outdented code in brick form is easier to
read and understand.
That's a very personal issue and I don't think I've ever struggled to
understand code based
on the outdenting style. (Factory, Visitor, Facade, etc. DO cause me to
stumble :-) )
I do think it is interesting that most of the code snippets I see posted
here in Clojure
do not tend to use outdenting brace style. And when I look at core.clj I
don't see any
outdenting going on but I find the code highly readable. In fact, I
can't find a single
instance of outdenting anywhere in src/clj/clojure. Rich has obviously
discovered
his inner lisp.
Anyway, since this is a "religious issue" with no resolution I can only
recommend:
http://www.youtube.com/watch?v=5-OjTPj7K54
Beware the lightning :-)
Tim Daly
> - Greg
>
>
> ------------------------------------------------------------------------
>
>
> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>
>
>> A more serious answer is that when I code in Java I use the
>> brace-on-a-line kind of indentation. When I code in Lisp I
>> never write single-line parens of any kind.
>>
>> I find that I think differently in each language.
>>
>> My Java code is always a pile of declare-this, do-this, do-this, return
>> Thus I find that I'm delimiting the scope of my variables, marking my
>> control flow and branching logic, try/catch logic, class boundaries, etc.
>>
>> My Lisp code mixes control flow and data structures in the same syntax.
>> Thus the idea that parens are some kind of control flow delimiter is
>> not particularly meaningful.
>>
>> To see the alternative case, take a Java program, find every function call
>> such as:
>> MyFactory(somearg);
>> throw away the ';', and move the paren left to get:
>> (MyFactory somearg)
>>
>> Now the question you're asking is, why don't lispers write
>> (MyFactory somearg
>> )
>> which makes me cringe.
>>
> ------------------------------------------------------------------------
>
Greg
I consider Lisp to be one of my favorite languages (if not my favorite), and I've been coding in it for several years.
It's rather silly to assume something about someone's programming experience based on their code style. Sometimes you'd be right, and other times you'd be wrong, just as with any sort of stereotyping.
> "Scope" is a very slippery concept in a language like lisp.
> Where it does occur in obvious cases (e.g. a "let") you'll
> find that lispers universally indent their code, just like everyone else.
This I understand very well (as I mentioned in the post).
It really has no bearing on the central argument though. It's only introduced as a guideline as to where you might want to consider trailing your parens.
> That's a very personal issue and I don't think I've ever struggled to understand code based on the outdenting style.
>
I think I've said that several times now. :-)
I actually do like the succinctness of stacked parenthesis, but unfortunately that style has many shortcomings that I find rather annoying. Again, to each his own.
Sincerely,
Greg Slepak
Greg
Perhaps I should, then I wouldn't have to respond to your emails. :-p
As I've said multiple times now, now indentation width does help readability, but adding trailing parenthesis on top of that can increase it further.
From an information theoretic point of view, it should be obvious. Whereas on the one hand you only have one bit of information to judge what function you're in (just increasing indentation width), on the other you have two bits (indentation width + trailing parenthesis).
> Closing the comments after people started to question you on this wasn't a good move, either (otherwise I'd be commenting there rather than here).
Oh goodie, it seems like it was a good move after all. :-P
- Greg
Fogus
http://blog.fogus.me/2010/07/12/wadlers-law-extended-to-clojure/
:f
wwmorgan
Leiningen example from the blog post is confusing, and I don't think
paren style matters at all. The functions have grown over time,
they're now too big, and they need to be refactored into several
smaller functions. The paren style is a red herring. core.clj is
readable because its functions are short.
When your code makes you want to outdent, you can take this as a
signal that your function has gotten too big and needs to be
refactored.
- Will Morgan
>
>
> On Aug 18, 2010, at 1:17 PM, Tim Daly wrote:
>
> > A more serious answer is that when I code in Java I use the
> > brace-on-a-line kind of indentation. When I code in Lisp I
> > never write single-line parens of any kind.
>
> > I find that I think differently in each language.
>
> > My Java code is always a pile of declare-this, do-this, do-this, return
> > Thus I find that I'm delimiting the scope of my variables, marking my
> > control flow and branching logic, try/catch logic, class boundaries, etc.
>
> > My Lisp code mixes control flow and data structures in the same syntax.
> > Thus the idea that parens are some kind of control flow delimiter is
> > not particularly meaningful.
>
> > To see the alternative case, take a Java program, find every function call
> > such as:
> > MyFactory(somearg);
> > throw away the ';', and move the paren left to get:
> > (MyFactory somearg)
>
> > (MyFactory somearg
> > )
> > which makes me cringe.
>
Tim Daly
Tim Daly
Paul Stadig
I've rarely found these coding style discussions to be productive, and have wondered why source control systems don't just store code in a whitespace normalized format and automatically format the code to your own taste when you check it out, because, let's face it, formatting is semantically irrelevant. It may help *you* grasp the meaning more quickly, but the opposite may be true for others. But I guess automatic formatting would totally destroy the ability to talk about line 16 of a particular file.
Then I move on to thinking it best for a language designer to just legislate fomatting and make it a compiler error, but that would probably generate more discussion than otherwise, so I've just written the whole thing off as a lose-lose situation. But maybe I'm just getting cumudgenly in my old age.
I do however firmly believe that each language has a worldview and a culture that coaleces around it, and one is better off either adopting it whole hog, or finding another language that matches better with one's own worldview. Something akin to what Brenton said about choosing a language because it mirrors your thinking, not because of readability concerns. It is a disaster to try to force the idioms of one language to be true in another.
Paul
Mike Meyer
Paul Stadig <pa...@stadig.name> wrote:
> Then I move on to thinking it best for a language designer to just legislate
> fomatting and make it a compiler error, but that would probably generate
> more discussion than otherwise, so I've just written the whole thing off as
> a lose-lose situation. But maybe I'm just getting cumudgenly in my old age.
You could argue that this is the route that ABC/Python took -
formatting, not punctuation, dictates flow control. Broken formatting
generates compiler errors:
python /tmp/break.py
File "/tmp/break.py", line 3
print 4
^
IndentationError: unexpected indent
So people argue about putting back the punctuation instead of where
the punctuation goes. Not quite as much, but it still happens.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Cyrus Harmon
I'm reminded gigamonkey's footnote about when functions get too big:
"A friend of mine was once interviewing an engineer for a programming job and asked him a typical interview question: how do you know when a function or method is too big? Well, said the candidate, I don't like any method to be bigger than my head. You mean you can't keep all the details in your head? No, I mean I put my head up against my monitor, and the code shouldn't be bigger than my head." [1]
There are many different styles for source code, but my experience with lisp suggests that variable indentation (as provided by emacs lisp-mode or clojure-mode) and parens-not-on-their-own-line makes for much more readable code. core.clj is a good example where the code is generally readable, but I shudder to think what it would be like to read the code for doseq or destructure if each closing parenthesis were on its own line.
And, as for writing code, I couldn't live without paredit.
To each their own, but let's not go down the route of saying "hey, you're code formatting style sucks, but I don't want to start a flame war" :).
Cyrus
1. http://www.gigamonkeys.com/book/practical-a-simple-database.html
Greg
It may help *you* grasp the meaning more quickly, but the opposite may be true for others. But I guess automatic formatting would totally destroy the ability to talk about line 16 of a particular file.
Rayne
like that.
It may be helpful to some people, but I don't see the point when I
have an editor that can match parens for me without any real work on
my part. The parens aren't something I feel I need to "maintain",
because between paredit and paren matching, I never have problems with
them.
Shantanu Kumar
for humans.
Regards,
Shantanu
michele
will not put closing parenthesis on new lines. Even though the editor
helps me with the parenthesis, there have been situations - while
editing inside functions - that I had to count them. Here is an idea
(by Harold A.), I will try:
The trick I did back when I was actively programming LISP
in the '80s was to depend on EMACS to get the indentation
right and then each closing paren matches a level of
indentation. You'll note in your example above that there
are 4 closing parens and four levels of indentation
including 0 for the first paren.
Adam Burry
> There is no law. Do what is best for you.
But there OUGHT to be a law.
Adam
Greg
> but I shudder to think what it would be like to read the code for doseq or destructure if each closing parenthesis were on its own line.
Good thing no one suggested that. :-)
> And, as for writing code, I couldn't live without paredit.
What would you do without it?
- Greg
Brian Goslinga
> Thanks everyone for the your answers (and the internal debates). I
> will not put closing parenthesis on new lines. Even though the editor
> helps me with the parenthesis, there have been situations - while
> editing inside functions - that I had to count them.
stack of closing parens, and then spam the ) key until the Emacs
matches it to the desired opening paren. I can't remember a time that
I had to manually count the parens when using that technique.
Using paredit would be another solution, though (like most things) you
have to invest some time in learning it to put it to good use.
Greg
> indentation, (ick!) and you're viewing it with a different tab-stop
> setting
Whoops, you're right, it was an honest mistake on my part. I use tabs of size 4 and the tab-stop used there was 8 I believe.
This issue is making me look into SmartTabs:
http://www.emacswiki.org/emacs/SmartTabs
Although SmartTabs won't magically make other people's code look right (even in Emacs) if they use a tab-stop of 8 (unless there's some feature I'm missing), they will however ensure that *my* code looks the way it should in anyone else's editor.
I'm currently using this to activate it:
(smart-tabs-advice lisp-indent-line lisp-indent-offset)
And that *seems* to be working so far... If I'm doing it wrong though feel free to let me know!
Thanks,
Greg
Jim Wise
> Here is another trick that works for me in Emacs: delete most of the
> stack of closing parens, and then spam the ) key until the Emacs
> matches it to the desired opening paren. I can't remember a time that
> I had to manually count the parens when using that technique.
Note that if you are using SLIME, C-c C-] will close all parentheses
still open at point -- though as with the above method, it's good to
take a look and make sure that's really what you want.
Historically, several lisps have provided ']' to mean `close all
currently open parens' as well, as in
(defun foo (x) (progn (foo) (bar]
but as more lisps (R6RS, clojure, several older schemes) provide [ ] as
a separate syntactic form or as an equivalent to ( ), this is not really
an option any more.
--
Jim Wise
jw...@draga.com
Btsai
I have Paren Match Highlighting enabled and set to highlight the
entire expression within matching parens (the highlighting kicks in
when the cursor is before the opening paren or after the closing
paren):
(show-paren-mode 1)
(setq show-paren-style 'expression)
In addition to helping me match up parens, it also helps me see the
"scope" of extended expressions like "let" or "for" at a glance.
Laurent PETIT
On Wed, Aug 18, 2010 at 1:36 PM, Greg <gr...@kinostudios.com> wrote:
> Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this).But the indentation is broken in that code already. If the indentation
were fixed (and the long functions refactored) it would be a lot more
readable. In order to reformat it with trailing parens, you'd have to
fix the basic indentation first anyway...
In the blog post's example, I found the println 'parent' straight away
and the extra vertical whitespace didn't help (sorry but lone closing
parens just create vertical whitespace for me).
I did find the 4 char indents easier to read than the 2 char indents.
I wish CCW respected the "displayed tab width" setting as its
indentation in strict structural mode as I'd rather have 4 spaces than
2 but it seems 2 is pretty much the standard around here?
You can file an issue, I'll see how easy it is to do it.
The readability of the attached screenshot is due to broken
> The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width.
indentation and the function being too long, IMO.
(and, for background, I'm far more used to programming in C-style
languages even tho' my Lisp usages dates back to the early 80's - but
I do find I naturally settle into a different style in Lisp to what I
use elsewhere)
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
--
Sean Corfield
>> I did find the 4 char indents easier to read than the 2 char indents.
>> I wish CCW respected the "displayed tab width" setting as its
>> indentation in strict structural mode as I'd rather have 4 spaces than
>> 2 but it seems 2 is pretty much the standard around here?
>
> You can file an issue, I'll see how easy it is to do it.
Thanx Laurent. I guess I was more curious to understand what
"displayed tab width" actually does since if you create the code in
CCW, it has no tabs anyway...?
Here's the issue: http://code.google.com/p/counterclockwise/issues/detail?id=137
kyle smith
> Here is another trick that works for me in Emacs: delete most of the
> stack of closing parens, and then spam the ) key until the Emacs
> matches it to the desired opening paren.
Michał Marczyk
http://edward.oconnor.cx/elisp/hl-sexp.el
(Highlights the "innermost list structure".)
Sincerely,
Michał
Tim Daly
Put the open parens at the end of the line and it looks like python!
(
defun foo (
arg1 arg2 arg3 ) (
let (
tmp1 tmp2 ) (
firstFunction arg1 ) (
secondFunction arg2 ) (
thirdFunction arg3 )))
auggghhh! my eyes! my eyes!!!! :-)
Back in the pre-history while I worked in the "machine room"
a student came to me with FORTRAN code. He discovered that FORTRAN
ignored spaces so he has a solid block of code from column 8 to
column 71 that went on for pages.
There is no disputing taste. Fortunately, lisp doesn't care.
Since it is still "in the early days" of Clojure it might be a
good idea to follow the style set in clojure core.clj. You never
know when your code might become a candidate for inclusion and
the last thing you want is to be rejected for style.
Tim Daly
lprefo...@softaddicts.ca
generated up to now (I deleted the 28 ones without reading them after reading
a couple of replies to the original post).
Hmmm,,, I am about to think that we could have powered a small town
with all that electrical nerve impulse that has been spent on this subject
not withstanding the electricity spent in wires and servers to spread
this thread every where around the planet.
And yet no consensus has been reached... maybe we should drop the subject
for now ?
Luc P.
Tim Daly <da...@axiom-developer.org> wrote ..
michele
Being the one who asked the question and satisfied with the answers, I
agree. I never expected a question like this, about one of the oldest
programming languages, to generate so many responses and discussions.
Funny...
On Aug 29, 9:46 pm, lprefonta...@softaddicts.ca wrote:
> My rough estimate is that more than 40 replies to that thread heave been
> generated up to now (I deleted the 28 ones without reading them after reading
> a couple of replies to the original post).
>
> Hmmm,,, I am about to think that we could have powered a small town
> with all that electrical nerve impulse that has been spent on this subject
> not withstanding the electricity spent in wires and servers to spread
> this thread every where around the planet.
>
> And yet no consensus has been reached... maybe we should drop the subject
> for now ?
>
> Luc P.
>
nemoniac
On Aug 18, 11:09 am, michele <michelemen...@gmail.com> wrote:
> Wouldn't that make it easier to keep track of them.
>
> Example:
>
> (defn myfn-a [a b]
> (if (zero? b)
> a
> (recur
> (afn (bfn (...)) a)
> (dec b))))
>
> (defn myfn-b [a b]
> (if (zero? b)
> a
> (recur
> (afn (bfn (...)) a)
> (dec b)
> )
> )
> )
past them. The editor takes care of parentheses and indentation. To
a real Lisp programmer, your code above may as well look like this:
defn myfn-a [a b]
if zero? b
a
recur
afn bfn ... a
dec b
Viewed in that light, devoting a line to each close parenthesis is
just a shameful waste of screen real estate. It's similar to the
profligacy that programmers in languages like Java are guilty of when
they use 4 or even 8 character indents. Before you know it you've got
a page of code that's 160 characters wide and 1000 characters long and
you need a 40" screen just to find your way around.
The more code you can catch in one glance, the better your overview.