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.
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
Greg wrote:
It's almost purely community convention that has been adopted from Lisp.
You may be interested in this link:
http://gregslepak.posterous.com/on-lisps-readability
There is much discussion about this topic there.
Cheers,
Greg
On Aug 18, 2010, at 2:09 AM, michele 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)
)
)
)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
------------------------------------------------------------------------
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
