Fork me on GitHub
#clojure-spec
<
2020-07-01
>
misha13:07:14

harold

:1
=> :1

(keyword "foo" "1")
=> :foo/1

:foo/1
Syntax error reading source at (REPL:1:1).
Invalid token: :foo/1

alexmiller13:07:19

there's a lot of tedious history here but keywords with numbers as the name part are technically not valid in the reader

alexmiller13:07:08

due to a long-standing bug in the regex for keywords, things like :1 are actually read however and we've decided not to make them invalid

misha13:07:54

backward compatibility is tough

alexmiller13:07:05

and just generally, there are a lot of keywords you can make programatically that are not print/read roundtrippable (https://clojure.org/guides/faq#unreadable_keywords)

misha13:07:09

this is I am aware of, yes. trying to choose generated keyword format, suitable for all of: item spec (:foo/i1) cat/or branch spec for that item (:i1), conformed value walking (idx) etc.

misha13:07:08

@alexmiller is it possible to get quoted form of lambda verbatim as edn? e.g. #(+ % 2) so it could be printed out exactly like this #(+ % 2) ?

misha13:07:30

'#(+ % 2)
=> (fn* [p1__7217#] (+ p1__7217# 2))

alexmiller13:07:28

if you're worried about the gensyms, you can transform to (fn [%] (+ % 2)) - spec does this for forms

alexmiller13:07:06

(as an aside, there is a ticket and some work on better controlling gensym construction - this is often a tricky case when trying to symbolically compare macroexpanded code chunks)

misha13:07:20

I am generating lambda forms for generated specs, and often fn one is way too long, so I might as well just defn it:

(defn <=10? [x] (<= x 10))
(defn >=5? [x] (>= x 5))
(s/def :user/root (s/and number? >=5? <=10?))

misha13:07:55

which is, arguably, better, than

(s/def :user/root (s/and number? (fn [x] (>= x 5)) (fn [x] (<= x 10))))

Jan K23:07:56

You could also do #(<= 5 % 10)

misha08:07:46

not gonna: • complicates lib code • less granular spec errors • less similar to source json-schema, so when(if) you gonna debug things – you will have to recalculate another transformation in your mind

misha15:07:32

> range from start (inclusive) to end (exclusive). - only for ints - (ex)Inclusiveness is baked in - requires both limits - specifically range spec was not the point, but readability of inline functions was

misha13:07:13

but then, there are things like ratios, decimals, etc opieop