Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-12-08

Channels

#clojure-spec
<
2021-12-08
>
Drew Verlee00:12:22

> For this we have exercise, which returns pairs of generated and conformed values for a spec What if we just want the generated values?

Drew Verlee00:12:24

i can fish them out, but i'm guessing there is a convention rather then threading with calls to first.

Drew Verlee03:12:19

thanks alex. ill read that shortly!

Drew Verlee04:12:46

that likely does what i need. it would be nice if i had away to easily jump from one doc to another. that fns args are are just & args and the doc string is that its a lazy version of another fn. not much to go off! i guess i should just jump to the code?

Drew Verlee04:12:16

well, im guessing that would be very educational 

(lazy-combinators hash-map list map not-empty set vector vector-distinct fmap elements
  bind choose one-of such-that tuple sample return
  large-integer* double* frequency shuffle)

Drew Verlee04:12:27

but not very direct 🙂

borkdude16:12:30

I'm working on better clojure.spec support for babashka. I'm testing expound with instrumentation. How do people generally get to see expound's output when running with instrumented functions? What do you have to configure, besides the explain printer? It seems you have to catch the ExceptionInfo and push the ex-data through s/explain-out yourself?

borkdude16:12:21

Besides that question: what are some libraries that leverage clojure.spec that I should test.

delaguardo17:12:06

reitit with spec based coercions

borkdude17:12:08

reitit doesn't work because it isn't pure Clojure, it has custom Java classes

vemv22:12:14

https://github.com/nedap/speced.def perhaps, we've wanted to use it for bb scripting sometimes (@UHJH8MG6S)

➕ 1
abrooks23:12:53

We have a library that provides and conforms against specs for incoming complex values. Within the values can be maps and s/keys will, as the doc string says: > In addition, the values of all namespace-qualified keys will be validated (and possibly destructured) by any registered specs. If the caller puts their own namespaced keys in the map (which is fine) and they have defined specs for these, those specs will be validated (and conformed) when we validate or conform the larger structure. This creates problems in providing good error messages since, when we conform, we don't know if the caller has violated our spec or their own spec. There's no way to conform only our parts of the spec first to validate the shape of their input without also conforming and failing on their values. This leads to a very confusing error message that we can't help to resolve.

abrooks23:12:43

Is there a sane work around for this? I'd really like an s/keys option or similar that doesn't validate keys beyond those expressed.

Alex Miller (Clojure team)23:12:30

a) you could narrow the data before conforming b) hopefully you can differentiate by key namespace either for narrowing or for error gen?

👍 1
abrooks14:12:03

(a) doesn't work since we actually want the data preserved in the conformed result. I'll look at (b) but would love to mention that having local specs (similar to local Clojure hierarchies) is really what I think I want as a user. You can have the global spec (just like global-hierarchy) but also provide a local subset or curated spec for a particular context.

abrooks18:12:13

Oh, I love namespaced names and the general global usage is fine but, as Stu and Rich have noted, a la carte features are valuable for application domain use cases not just programming domain use cases. I'd love to have spec for application domain use cases which is exactly what hierarchies allows for. Global for programming domain, a la carte for application domain. Often the specs overlap so you want to be able to re-use them between the two.

abrooks18:12:53

metosin/malli supports this, FWIW.