Optional commas in map literals

[dkick-cni]

Community standards mentions optional commas in map literals

`;; [1] good
{:name "Bruce Wayne" :alter-ego "Batman"}

;; [2] good and arguably a bit more readable
{:name "Bruce Wayne"
:alter-ego "Batman"}

;; [3] good and arguably more compact
{:name "Bruce Wayne", :alter-ego "Batman"}`

As far as I can tell, zprint only supports commas yes, or commas no. Is there a way to configure it to never [1] but [2] or [3] depending on either: 1, space in the right margin; 2, it's been asked to respect newlines, and so will not add commas to [2] but would add them to [1] to turn [1] into [3]?

[kkinnear]

You are right, zprint sees :comma? as a boolean. It is hard for zprint to decide to do comma's based on the space remaining on the line -- in part, because formatting proceeds by following the nesting level of the parentheses, and the deeper levels have no insight into what will happen later on the line. I suppose commas could be added and then removed if it made things tight on the line, though that makes me cringe for some reason. One thing that zprint does do is manage the right margin very strictly (in contrast to most other formatters), which allows it to use the space up to the right margin effectively.

I would consider implementing what you suggest -- but I don't actually understand the details. I see roughly two things:

1. Put commas in unless they ... cause the expression to overflow onto the next line? ... or what criteria would you use?
2. When respecting newlines, add commas to maps that format onto a single line -- but not maps that format onto multiple lines.

Both of these things are conditioned on whether things are on one line or not, which is not a great condition for formatting for zprint (as I alluded to earlier).

Before I could even consider implementing either of these things, I need additional details and examples of what you want. #1 needs more details, and I suppose that #2 is fully specified as written, but I'm guessing that is actually not (entirely) what you were asking for.

If you flesh out the descriptions of what you want with some more words, and give some additional examples, I will try to figure out what I can do to make zprint format things the way you would like it.

[dkick-cni]

I think your #1 "Put commas in unless they ..." and #2 "... add commas to maps that format onto a single line .." are somewhat similar ... maybe? When you write about whether things are on one line or not, I wonder about the pairing in, for example, cond

(cond
(short-x?) (short-x)
(short-y?) (short-y))

(cond
(annoying-really-long-name-for-a-thing-x?)
(annoying-really-long-name-for-a-thing-x)

(annoying-really-long-name-for-a-thing-y?)
(annoying-really-long-name-for-a-thing-y))

Perhaps right margin isn't the correct term for the condition to trigger splitting the pairs into multiple lines. But I am often formatting code, for example, with lots of deps, just to use some common lib examples [and I'll just have to see what the markup does with indentation and try to fix it up]:

{:deps {hato/hato {:mvn/version "0.8.2"}
http-kit/http-kit {:mvn/version "2.8.0"}}}

As an example of non-comma, where I don't think the community standard wants them (commas) to be added, but don't try to collapse because it's already multiple lines. For example, this would fit onto one line, but should be left as multiple lines:

{:deps {hato/hato {:mvn/version "0.8.2"}, http-kit/http-kit {:mvn/version "2.8.0"}}}

However, I think that finding

(defn f [x {:keys [y] :as m :or {y 'y}}]
[x y m])

And converting it to

(defn f [x {:keys [y], :as m, :or {y 'y}}]
[x y m])

Is an improvement, per the community standard. And doesn't see

(defn f
[x
{:keys [y]
:as m
:or {y 'y}}]
[x y m])

As necessarily always better?

I'm not sure if this helps clarify? Or only reinforces the kind of fuzzy logic about this?

[kkinnear]

Just a note -- clojure.core isn't formatted per the self-described "community standard". Not that the community standard is bad, particularly. Just that Lisp's have a very long history, and many people who use Clojure have a history with other Lisps where their ideas of "correct" formatting were formed. Which is why the defaults for zprint are what they are -- I tried to make them close to the formatting of clojure.core with departures for things that mean a lot to me, as I too have a long history with other Lisps.

Not that any other Lisps (to my knowledge) ever had commas be white-space to the reader, or even had commas be syntactic elements, for that matter.

zprint will format the example defn you gave as a single line, unless you enable :style :respect-nl, in which case it will format it on three lines. It will never (by default) put the three map key-value pairs on separate Iines unless the width is really small (or the key-value pairs are really large) or you tell it to specifically:

; The example you gave
(print i364a)
(defn f [x {:keys [y] :as m :or {y 'y}}]
  [x y m])

; Default  zprint
(czprint i364a {:parse-string? true})
(defn f [x {:keys [y], :as m, :or {y 'y}}] [x y m])

; Respect-nl 
(czprint i364a {:parse-string? true :style :respect-nl})
(defn f
  [x {:keys [y], :as m, :or {y 'y}}]
  [x y m])

; Force newlines between key-value pairs
 (czprint i364a {:parse-string? true :map {:force-nl? true}})
(defn f
  [x
   {:keys [y],
    :as m,
    :or {y 'y}}]
  [x y m])

; When map is too long to fit on one line, you get the k-v pairs on multiple lines
(czprint i364b {:parse-string? true})
(defn f
  [x
   {:keys [yyyyyyyyyyyyyyyyyy],
    :as mmmmmmmmmmmmmmmmmm,
    :or {yyyyyyyyyyyyyyyyyy 'y}}]
  [x y m])

1. It looks like you (or of the community standards?) generally like commas in maps when multiple pairs show up on one line, and not so much when pairs end up on separate lines. Which I can sort of understand. I think I could get zprint to do that, though I won't be sure until I prototype the actual code. Would that be of value to you?

As far as the :deps you list above -- to a first approximation, zprint will format anything that fits on one line, on one line. zprint's goal is to reduce cognitive load by giving you the most code possible on your screen, which translates into using the available space in the :width as much as possible, while keeping things aligned in a way that reflects the structure of the code. The various function styles dictate multiple lines for many things, particularly defns.

The specific :deps you listed will show up on the same line unless they don't fit or you use :style :respect-nl or :map {:force-nl? true}. You said you are often formatting code with "lots of deps". Which is ... interesting. I would be interested in seeing some examples of the code with lots of deps. Or a link to where I might see such code. Perhaps I'm missing something, but I don't regularly deal with code with lots of deps in with the code and don't recall seeing that in the code I've looked at on GitHub. So I'd be delighted to see some actual examples of the code and deps together, and which ones you think are good and which ones are not so good. From that I can probably abstract out some rules that reflect what you want zprint to do, and then I can either show you how to configure zprint to do that (possibly creating a guide to do that), or consider what new features zprint would need to make that possible.

So far, #1 above is the only thing I've been able to come up with regarding commas, and it would take code to implement -- there is no way to configure zprint to do that right now. But (if it truly is what you would like), I expect you probably aren't alone in that, and I could see adding it to the worklist for 1.3.1 (which is in progress right now).

I'll look forward to some code examples with lots of deps.

[dkick-cni]

Which is why the defaults for zprint are what they are -- I tried to make them close to the formatting of clojure.core with departures for things that mean a lot to me, as I too have a long history with other Lisps.

Yeah, I first fell in love with parenthesis in a college course using VAX Common Lisp (IIRC) on a Vax VMS. And, like, I'd also like to take this opportunity to thank you for giving us zprint; very much appreciated.

Not that any other Lisps (to my knowledge) ever had commas be white-space to the reader, or even had commas be syntactic elements, for that matter.

For what it's worth, I not a huge fan of it. I'd much rather (let [[x 13] [y 69]] ...) and let [grimace] the usual thing to do with parenthetical groupings just do its thing. I almost wish Erik Naggum were still around to rant about it.

It looks like you (or of the community standards?) generally like commas in maps when multiple pairs show up on one line, and not so much when pairs end up on separate lines. Which I can sort of understand. I think I could get zprint to do that, though I won't be sure until I prototype the actual code. Would that be of value to you? ... (if it truly is what you would like), I expect you probably aren't alone in that, and I could see adding it to the worklist for 1.3.1 (which is in progress right now).

Yes, it would be quite valuable, please and thank you. I know that I'm not the only one because I've worked in a Clojure shop where a number of coworkers wanted to be able to do this. In my own spaces, I've settled on ...

{:binding {:nl-separator? true}
:map {:comma? false
:force-nl? true
:nl-separator? true}
:pair {:nl-separator? true}
:style [:community :extend-nl :justified :sort-dependencies :how-to-ns
:sort-require :respect-nl]}

... and I'm fine with {:keys [...] :as m} expanding onto multiple lines. Other people's mileage definitely varied on that, though.