Proposal: read single characters of : as whitespace, ala ,, so that json files can be directly read into Clojure maps, without having to clean the colons out.

You can't def a : anyway, so it's pretty much useless as a single character otherwise

there actually is a very old proposal for this in jira

https://dev.clojure.org/jira/browse/CLJ-899

I'd say at this point that it's unlikely we're ever going to do this

hmmm, a lot of "boo" votes on that ticket... Thanks for the context, @alexmiller

I think if you look at the details, there are a lot of subtle points about reader ambiguity being made that are well-founded

Very nicely written, Alex https://clojure.org/community/contributing

thx, still needs some review from Rich and Stu so might go through some changes :)

lol and some not so subtle 😉 I don't know, I don't find them very convincing. JSON keys are strings, so I don't think you'd have such ambiguity.

But it seems like adding another white space char would be perceived as extra "pollution" to the syntax.

Admittedly, I dislike the noise of commas

json allows not quoting keys

Some parsers do I guess

all do

oh, huh, I guess not

wild

maybe json-ld doesn't

or allows them rather

that must be the difference between literal objects in js and json

because come to think of it, the only place I have every seen it done is actually in js

Yeah, js allows it, json doesn't.

Anyway, even if they did accept unquoted keys, I still don't think that'd be a sufficient objection on it's own. If some json accidentally has unquoted keys with colons beside them, with no space between them, you'd get a symbol with a colon at the end.

I do wonder though if the extra logic branch to accept and then ignore : would slow down reads on keywords at all

map keys are not always keywords

automatically turning json string keys in to keywords instead of leaving them as strings would be another thing

Well, this would imply that you could read a syntactically correct JSON map and the reader wouldn't even know it's not a map already

sure

but you are are talking about dealing with ":" in the reading of keywords

nah just ignore them

and keywords can be read anywhere, not just inside maps

when they're a single char

you just said "I do wonder though if the extra logic branch to accept and then ignore : would slow down reads on keywords at all"

Well, hitting : is going to trigger the keyword-read function

Then fail

it may or may not

it depends a lot on the implementation

If : is read as a singular token, I think it'll fail. And you can't def it as a symbol

the reader is not a parser combinator thing where you can read and fail and try something else

AFAICT, : is not currently usable as a token by itself anywhere

I don't know if anyone is keeping a formal analysis, but the reader is, if I recall generally LL(1)

{"a":true} seems to be the killer counter-argument to this whole discussion.

ah, I missed that one 😕

It's right there in the ticket.

Yeah, I just didn't process that part

and {"a":123}

Yeah, false alarm. Bad idea... Pretend I didn't say any of what I just said 😉

Well, yeah, but I wanted to lead with a well-defined, valid keyword example 🙂 :123 works but... 🙂

Feel free to delete all your messages above (and we'll delete ours) 🙂

or just wait for slack to delete them for us

right

It doesn't. It just makes them unsearchable. If we paid for a month, they'd all still be there.

Mind you, at this point, they're all enshrined in the ClojureVerse log archive and in Zulip's infinite searchable archive 🙃

I'll just suffice to apologize for all the noise in the dev channel. Interesting thoughts though. Thanks folks.

no worries