A consequence of #1721

[sogaiu]

With the changes in #1721, the output from my testing code has changed from looking like:

form:
(eq? (-> iz down right) (-> iz down right right right))

to:

form:
(eq?
 (->
  iz
  down
  right)
 (->
  iz
  down
  right
  right
  right))

Is there a way I might recover the past behavior?

The above is just one example. I do want multiline output for "data", but the above is more like "code".

I think the code that produce the above uses %m, here.

I suppose it's my fault for not using something specialized for formatting code.

[McSinyx]

Hi, author of #1721 here, what do you think of #1733?

[sogaiu]

Thanks for taking a look and working on #1733.

I gave it a try and for the case mentioned above, it seemed familiar (so previous behavior):

with #1733:

(printf "%m" '(eq? (-> iz down right) (-> iz down right right right)))
(eq? (-> iz down right) (-> iz down right right right))

with #1721:

(printf "%m" '(eq? (-> iz down right) (-> iz down right right right)))
(eq?
 (->
  iz
  down
  right)
 (->
  iz
  down
  right
  right
  right))

---

Since there was an opportunity, I tried printing something else:

with #1733:

(printf "%m" '{:a 1 :b 2 :c [:x :y]})
{:a 1 :b 2 :c [:x :y]}

with #1721:

(printf "%m" '{:a 1 :b 2 :c [:x :y]})
{:a 1
 :b 2
 :c [:x
     :y]}

For this case, I like #1721's behavior better. How about you?

---

Reflecting on things a bit, if we think of %m and friends as being about "data", I think we're a bit in somewhat unchartered territory for "round paren tuple" printing. At least in usage that I typically observe in Janet, I don't really see those kinds of tuples being used for "data" much (if at all...or perhaps I'm not recognizing situations).

Perhaps my use of %m (and the like) for printing forms was a bit of an "abuse". May be best to leave things the way they are (improved via your #1721) and I should use another way to print "code" [1].

---

[1] This may keep everything simpler and perhaps Tony Hoare would have approved.

[sogaiu]

Just a note that I've addressed the issue in my own code by not performing any formatting [1].

---

I don't know if it's practical, but had the sort of related thought that %j could avoid producing round paren tuples and produce square bracket tuples instead for tuples.

This idea doesn't really address the formatting issue in a direct fashion, but it does side-step having to figure out what one might do with round paren tuples. I think it's fairly clear that curly braces and square bracket tuples have been used for "data" (e.g. in hiccup-like situations).

One additional benefit is that JDN content would be less problematic to evaluate. If a snippet of JDN contains round parens, and one tries to evaluate it (e.g. in a REPL-like situation) then all kinds of fun can ensue (more like errors).

I don't know if there would be any compatibility issues, but if that's an issue, I wonder if we could use %J (so capital J) as a specifier instead.

This probably doesn't work for %m and friends though as it would be too much of a behavior change that might break things.

---

[1] I retrieve fragments of the original source and more or less use the original formatting. This slows my testing program down a bit, but it's probably a more stable long-term solution.