Fork me on GitHub
#clojure-dev
<
2019-02-12
>
slipset09:02:35

Out of curiosity, how much work would it be to get a better error message for this:

slipset09:02:39

10:07 $ clj
Clojure 1.10.0
user=> (defn foo [{:key [lol]}] )
Syntax error macroexpanding clojure.core/defn at (REPL:1:1).
{:key [lol]} - failed: vector? at: [:fn-tail :arity-n :bodies :params] spec: :clojure.core.specs.alpha/param-list
({:key [lol]}) - failed: Extra input at: [:fn-tail :arity-1 :params] spec: :clojure.core.specs.alpha/param-list
user=>

slipset09:02:41

I would have expected something that told me that :key was not a valid destructuring thing.

borkdude09:02:09

@slipset Interesting. I think you can already experiment with this yourself, by overriding the specs here in your REPL: https://github.com/clojure/core.specs.alpha/blob/master/src/main/clojure/clojure/core/specs/alpha.clj#L89

slipset09:02:46

I did. For five minutes. Then returned to work 🙂

alexmiller13:02:29

In short, not easily - the keys of the destructuring map are symbols, vectors, or a set of different known or open key sets

alexmiller13:02:16

Maybe it would be possible to write a predicate and then s/merge a map spec that narrowed the keys to that. I’ve messed with all that a bit, never got happy with it

borkdude21:02:52

Speaking about core specs: https://github.com/clj-commons/secretary/pull/105#issuecomment-462940480 I’ve seen this error more than once.

alexmiller23:02:13

Is there a question?

borkdude08:02:16

Not really a question. More an observation that these specs forbid something that used to work before and occurred in people’s code.

alexmiller14:02:53

that has never worked. before it just silently had no effect, now it tells you.

borkdude14:02:51

ah right! in this case the import wasn’t even needed: https://github.com/joelkuiper/yesparql/commit/b7e9f30b606d9ef043c95bb565d3139a8ec61549 that set me on the wrong foot 🙂

alexmiller14:02:52

that is true of literally 100% of these (because they previously had no effect)

borkdude14:02:44

Hail the spec!

dpsutton22:02:26

would there be any interest to extend the integer regex to allow for an l suffix to require Long in the same way you can add an N to require a BigInt? Not often used but coworker was surprised by the type promotion to BigInteger

dpsutton22:02:59

seems to align with known jvm syntax but also dangerously close to the "who would ever use this" line? Just wondering

alexmiller23:02:25

What problem are you trying to solve?

dpsutton23:02:55

i think it was more flashbacks from silent type promotion in php. We were reading the source after a discussion in #beginners and he was surprised that he couldn't guarantee the return type of the literal. IE, all theoretical and no actual problem at hand

alexmiller23:02:44

That sounds like a pretty weak problem statement :)

dpsutton23:02:25

i agree 🙂

seancorfield23:02:00

Any objections to adding @zulip-mirror-bot to this channel to mirror messages to Clojurians on Zulip > slack-archive stream > clojure-dev topic?

seancorfield23:02:42

(mostly I've just been adding it to channels here but I figured I'd ask for this channel)

seancorfield23:02:03

Mind you, @logbot is already so I guess it's about the same thing. I'll add it. If anyone objects, I can remove it again 🙂