On Monday, November 17, 2014 5:20:36 PM UTC-5, Jan-Paul Bultmann wrote:
>
> To be honest I think that all the whitespace retaining approaches kinda
> miss the point.
> The reason code is mannually formatted is only because it consists of
> characters in a grid aka text. To me manual formatting is a chore, most of
> the time I rely on paredits or codemirrors auto formatting capabilities
> anyways.
>
> The ability to have a consistent idiomatic visual source structure
> enforced is a feature to me not a bug.
>
Disagree. There are lots of times when I use whitespace to enhance
readability in a way that would be destroyed by round-tripping through
read/pprint.
Example 1:
(reduce f1 #{}
(map f2
(some lengthy collection expr here)))
Most clojure tools and editor autoindents would like to indent that like
this instead:
(reduce f1 #{}
(map f2
(some lengthy collection expr here)))
but that's unaesthetic and wastes horizontal space. And
(reduce
f1
#{}
(map
f2
(some lengthy collection expr here)))
is unaesthetic and wastes vertical space. The original puts the "smaller"
arguments with the operator, and the "big" argument (the thing being
processed, rather than details of how it's being processed) onto the next
line, and strikes me as more readable. If it was nested a lot more deeply,
it might be better to use a threading macro, but
(-> (some lengthy collection expr here)
(map f2)
(reduce f1 #{}))
seems like overkill for only two nesting levels of expressions. I'd like
the choice of using either threading macros OR indenting as if "reduce f1
#{}" was "the operator" and not just "reduce". Giving the machine full
control of the whitespace would take away that choice.
Example 2:
[[(dec x) y w h ]
[x (dec y) w h ]
[x y (inc w) h ]
[x y w (inc h)]]
Sometimes I want tabular literal data, or a tabular expression, with
aligned columns. On the other hand, not every nest of vectors in vectors
(or other data structures) is actually tabular data. Consider
(let [[x y] (transform-pt x1 y1)
[a b c] (some-fn x y some-other-arg)
...]
...)
That probably should not be formatted with an attempt to align columns.
Other cases where I don't want alignment are not as easy to automatically
detect as "exclude all binding vectors containing destructuring forms",
however. And not every case where I want columns involves vectors, either:
(cond
(pred1) (consequence1)
(pred2 x z) (consequence2))
When the preds and consequences are mostly not very long, this is often
nicely compact and readable. Of course, most autoindents also screw up
(cond
(pred1)
(consequence1)
(pred2 x z)
(consequence2))
preferring to eliminate the additional indentation of the consequences
which helps them to stand out from the conditions that decide which to
apply.
All of this, of course, is to say nothing of the minor issues of preserving
comments; preserving comment column alignments where desired; and
preserving commas where useful in literal data (though I personally tend to
eschew them).
Code is data, and sometimes the best way to format that data for human
readability is sufficiently ad-hoc that no autoindent/pprinter could do a
fully general good job.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
