Fork me on GitHub
#clojure-dev
<
2019-05-02
>
john19:05:52

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.

john19:05:44

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

alexmiller19:05:24

there actually is a very old proposal for this in jira

alexmiller19:05:30

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

john19:05:39

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

alexmiller19:05:11

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

alexmiller20:05:49

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

john20:05:11

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.

john20:05:08

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

john20:05:37

Admittedly, I dislike the noise of commas

hiredman20:05:52

json allows not quoting keys

john20:05:18

Some parsers do I guess

hiredman20:05:19

oh, huh, I guess not

john20:05:50

maybe json-ld doesn't

john20:05:03

or allows them rather

hiredman20:05:00

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

hiredman20:05:35

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

dominicm20:05:21

Yeah, js allows it, json doesn't.

john20:05:05

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.

john20:05:30

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

hiredman21:05:36

map keys are not always keywords

hiredman21:05:22

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

john21:05:52

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

hiredman21:05:18

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

john21:05:29

nah just ignore them

hiredman21:05:32

and keywords can be read anywhere, not just inside maps

john21:05:35

when they're a single char

hiredman21:05:01

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"

john21:05:39

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

john21:05:45

Then fail

hiredman21:05:35

it may or may not

hiredman21:05:56

it depends a lot on the implementation

john21:05:24

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

hiredman21:05:26

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

john21:05:51

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

hiredman21:05:27

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

seancorfield21:05:27

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

john21:05:04

ah, I missed that one 😕

seancorfield21:05:13

It's right there in the ticket.

john21:05:32

Yeah, I just didn't process that part

john21:05:12

and {"a":123}

john21:05:59

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

seancorfield21:05:00

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

seancorfield21:05:19

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

hiredman21:05:35

or just wait for slack to delete them for us

1
seancorfield21:05:55

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

seancorfield21:05:28

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

john21:05:30

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