clojure-dev 2023-01-02 | Slack Archive

Hey all! Reader conditionals implementation leads to some surprising behaviors.

user=> (read-string {:read-cond :allow} "[^#?@(:clj [:b a c])]")
[^{:b true} a c]
user=> (read-string {:read-cond :allow} "[#_#?@(:clj [:b a c])]")
[a c]
(read-string {:read-cond :allow} "[# #?@(:clj [inst \"1978\" :etc])]")
[#inst "1978-01-01T00:00:00.000-00:00" :etc]

@baptiste-from-paris and I are tempted to treat them as undefined behaviors (and don’t replicate them in ClojureDart’s reader) as we can’t foresee any sensible usage for these. Any advice?

souenzzo13:01:51

edamame, that powers #CHY97NXE2, #C015LCR9MHD, #CLX41ASCS, etc can't parse any of these cases. it just throws

Alex Miller (Clojure team)15:01:13

The first two kind of make sense to me, but not the third

cgrand15:01:09

@U064X3EF3 For the first point I don’t see the value in writing [^#?@(:clj [:b a c] :cljs [:x y z])] instead of [#?@(:clj [^:b a c] :cljs [^:x y z])]. Ditto for the second.

Alex Miller (Clojure team)15:01:26

Agreed but it’s a tokenizing machine and it makes sense to me for that machine to do what the first two do

cgrand15:01:15

Understood.

Alex Miller (Clojure team)15:01:24

The last one effectively splits a token so that seems weird

cgrand15:01:36

Well, the reader being a recursive descent parser directly consuming characters it tokenizes in a context dependent manner so anything can happen.

2023-01-02

Channels