Could be my favourite improvement in 1.4

[Daniel Gagnon]

Allow colon as whitespace in map literals

That's a very subtle subtle change but with this it will be easier to experiment with JSON or Python data I want to just grab and paste.

That attention to little detail is very appreciated.

[Phil Hagelberg]

JSON as readable Clojure was discussed and shot down a while back, albeit with a weirder implementation: http://groups.google.com/group/clojure-dev/browse_thread/thread/5b066af1224efe8e/9ae78e878f873058 The idea of colons having special treatment in the context of maps is rather distasteful to me personally.

-Phil

[Alan Malloy]

On Dec 19, 9:25 pm, Phil Hagelberg <p...@hagelb.org> wrote:
> JSON as readable Clojure was discussed and shot down a while back, albeit

> with a weirder implementation:http://groups.google.com/group/clojure-dev/browse_thread/thread/5b066...

> idea of colons having special treatment in the context of maps is
> rather distasteful to me personally.
>
> -Phil

I agree, this horrifies me. It isn't even as simple as "letting them
be whitespace", because presumably you want (read-string "{a: b}") to
result in (hash-map 'a 'b), but (read-string "{a :b}") to result in
(hash-map 'a :b). So you can't just say they're whitespace - you have
to recognize the context they're in to decide what they attach to, if
anything. The existing behavior is much cleaner.

[Cedric Greevey]

+1

[Alex Baranosky]

For what it's worth, I think colon's as whitespace in maps adds confusion, without, imo adding a ton of power or readability.  In terms of power, it gives you the ability to paste JSON into a Clojure REPL; I wonder how often that use case comes up?  In terms of readability, any benefit it gives you in readability would be counterweighted by the additional syntax rules it adds.

The only way I could see this as worth it, would be if people wanted to paste 'foreign' map data into a Clojure REPL a ton more frequently than I imagine they do.

Alex

[jweiss]

Even if they did, it's pretty easy to surround the paste with (read-
json "... ").

On Dec 20, 10:36 am, Alex Baranosky <alexander.barano...@gmail.com>
wrote:

[Laurent PETIT]

Anyway, the issue has not even the start of an argumentation, use
case, or whatever ...

2011/12/20 jweiss <jeffrey...@gmail.com>:

> --
> 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 Malloy]

Well, that would be sufficient if we had HEREDOCs like Alex asked for,
but surrounding some JSON with ""s will usually break.

[Julien Kirch]

for these cases wouldn't be simpler to paste the map in a string and to create a function that could parse such a json-compatible map into a clojure map ?

A.

[Tavis Rudd]

This issue could be avoided by only treating a colon as whitespace when followed by a comma. As easy cut-paste of json seems to be the key motivation here, the commas are going to be there anyway: valid {"v":, 1234} vs syntax error {a-key: should-be-a-keyword}.

[Alex Baranosky]

This seems like a strange special case. 

What percentage of users need to paste JSON into the REPL?
Of those users, what percentage of the time do they need to do this?

On Mon, Jan 16, 2012 at 1:19 PM, Tavis Rudd <tavis...@gmail.com> wrote:

This issue could be avoided by only treating a colon as whitespace when followed by a comma. As easy cut-paste of json seems to be the key motivation here, the commas are going to be there anyway: valid {"v":, 1234} vs syntax error {a-key: should-be-a-keyword}.

--

[Justin Steward]

On Tue, Jan 17, 2012 at 5:19 AM, Tavis Rudd <tavis...@gmail.com> wrote:
> {"v":, 1234}

Except that's not valid JSON, so it's still not a simple cut and paste
solution. I personally think that confusing a colon with whitespace
under any circumstances is an unnecessary confusion leading to
unnecessary errors.

~Justin

[Tavis Rudd]

On Jan 16, 2:23 pm, Justin Steward <althalu...@gmail.com> wrote:

> On Tue, Jan 17, 2012 at 5:19 AM, Tavis Rudd <tavis.r...@gmail.com> wrote:
> > {"v":, 1234}
>
> Except that's not valid JSON, so it's still not a simple cut and paste
> solution. I personally think that confusing a colon with whitespace
> under any circumstances is an unnecessary confusion leading to
> unnecessary errors.
>
> ~Justin

Er, brain fart. I was typing faster than I was thinking and put the
comma in the wrong place. In my head I meant the form following the
colon would have to have a comma after it. Thus, {"a-json-key":
1234, ...} would be valid while {"a-json-key": was-supposed-to-be-a-
keyword "another-json-key" foo} would complain about the colon being
an Invalid Token. I don't see the need for it, however. Search and
replace is just as easy as cut and paste.

[Jonathan Cardoso]

brain fart lol

[Jeremy Heiler]

On Tue, Dec 20, 2011 at 2:05 AM, Alan Malloy <al...@malloys.org> wrote:

> I agree, this horrifies me. It isn't even as simple as "letting them
> be whitespace", because presumably you want (read-string "{a: b}") to
> result in (hash-map 'a 'b), but (read-string "{a :b}") to result in
> (hash-map 'a :b). So you can't just say they're whitespace - you have
> to recognize the context they're in to decide what they attach to, if
> anything. The existing behavior is much cleaner.

+2

[Jonathan Fischer Friberg]

+3