Re: clojure.spec merge+or bug?

I got bitten by this today as well... makes it hard to add a predicate that destructures the map and compares its values. On Friday, August 17, 2018 at 4:35:12 PM UTC-4, Alex Miller wrote: > > With s/and, conformed values flow through the predicates. This allows you > to take advantage of

Re: clojure.spec merge+or bug?

With s/and, conformed values flow through the predicates. This allows you to take advantage of structured values from early preds in later preds, so you're not having to re-understand the structure. (There are cases where having a non-flowing s/and would be useful and we've talked about adding

Re: clojure.spec merge+or bug?

Sorry, I meant to file a bug and even try to write a fix, but I was very pregnant at the time and then I gave birth so it sort of fell by the wayside. I'm interested in understanding why non-flowing behavior on conform is expected/desired behavior. I've found that when clojure design decisions go

Re: clojure.spec merge+or bug?

Thank you for explaining! Just in case, I opened a bug here https://dev.clojure.org/jira/browse/CLJ-2388 On Thursday, August 16, 2018 at 6:47:30 PM UTC-7, Alex Miller wrote: > > The non-flowing behavior on conform is expected behavior. > > Failure to roundtrip conform then unform is a bug (so

Re: clojure.spec merge+or bug?

The non-flowing behavior on conform is expected behavior. Failure to roundtrip conform then unform is a bug (so I'd so the bug here is in unform). On a quick search, I don't believe this was filed, but I could have missed it. On Thursday, August 16, 2018 at 8:28:54 PM UTC-5,

Re: clojure.spec merge+or bug?

Achhh, just spent the last few hours fighting this unexpected behavior with s/merge, until I finally came to realize that this is what it was.. I see this thread is quite old, did anyone open a bug for it as mentioned above? @Alex, you said this was the expected behavior, but then asked to

Re: clojure.spec gen-testing VS NaN

By definition NaN never equals any other number, including NaN itself, so isn't it a perfectly valid scenario to generate double NaNs? (Note: I've not used spec yet, so correct me if I'm completely off track) Am Montag, 7. November 2016 23:07:14 UTC+1 schrieb Alex Miller: > > I think it would

Re: clojure.spec gen-testing VS NaN

Yes it did: https://dev.clojure.org/jira/browse/CLJ-2054 On Tuesday, March 6, 2018 at 12:15:26 PM UTC-7, Wes Morgan wrote: > > Did this ticket get created? > > On Monday, November 7, 2016 at 3:26:15 PM UTC-7, Jim foo.bar wrote: >> >> Alright cool, I'll do that tomorrow :) >> >> Thanks, >> >>

Re: clojure.spec gen-testing VS NaN

Did this ticket get created? On Monday, November 7, 2016 at 3:26:15 PM UTC-7, Jim foo.bar wrote: > > Alright cool, I'll do that tomorrow :) > > Thanks, > > Dimitris > > On 07/11/16 22:07, Alex Miller wrote: > > I think it would be reasonable to log a jira enhancement request for the > spec any?

Re: [clojure.spec] Best practices for programmatically generating specs?

An eval requirement will still be an impediment to me but it's good to hear that things are still being worked on. I'm happy to do any early testing of proposed approaches and give feedback. Thanks for letting me know -- keep us posted! -Aaron On Wednesday, December 13, 2017 at 10:45:56 PM

Re: [clojure.spec] Best practices for programmatically generating specs?

Another possible option is using spec specs (CLJ-2112) to unform from a spec data form to a spec (but that would still need to be evaluated) - still very much a wip. However, we are working on a spec update that will target some of this, so stay tuned for that. On Wednesday, December 13,

RE: clojure.spec - Using :pre conditions (or not)?

@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of Alex Miller Sent: Wednesday, June 7, 2017 5:46 PM To: Clojure <clojure@googlegroups.com> Subject: Re: clojure.spec - Using :pre conditions (or not)? Preconditions are already assertions, so it makes more sense to use s/assert in you

Re: clojure.spec - Using :pre conditions (or not)?

Preconditions are already assertions, so it makes more sense to use s/assert in your code body than in a precondition. On Wednesday, June 7, 2017 at 8:12:22 AM UTC-5, David Goldfarb wrote: > > One big downside of using s/assert in a precondition: It does not work > with (s/nilable ...) specs,

Re: clojure.spec - Using :pre conditions (or not)?

One big downside of using s/assert in a precondition: It does not work with (s/nilable ...) specs, since s/assert returns valid values. I fell into this trap for a moment of head-scratching just now. On Wednesday, September 14, 2016 at 4:59:09 PM UTC+3, Alex Miller wrote: > > Another option

Re: clojure.spec merge+or bug?

You can file a bug on the s/merge unform - anything that doesn't roundtrip should be a bug. On the coll-of one, I thought that was just fixed in the latest spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076) - are you using latest there? -- You received this message because

Re: clojure.spec merge+or bug?

It also seems to come up with coll-of + or: user> (s/def ::a (s/or :even even? :odd odd?)) user> (s/def ::c (s/coll-of ::a)) user> (s/conform ::c [1 2 3 4]) [[:odd 1] [:even 2] [:odd 3] [:even 4]] user> (s/unform ::c (s/conform ::c [1 2 3 4])) [[:odd 1] [:even 2] [:odd 3] [:even 4]] It looks

Re: clojure.spec merge+or bug?

thanks for the fast reply! do you think it will always be this way? it does seem to violate the expected conform/unform relationship. On Wed, May 31, 2017 at 9:51 PM, Alex Miller wrote: > This is actually the expected result. s/merge doesn't flow like s/and - > only the

Re: clojure.spec merge+or bug?

PS - I just realize I wasn't using the latest version of spec, as is evident from my require, but I just tried again with the latest and it doesn't change the result. And I should have mentioned that I'm happy to take a stab at a fix, assuming I'm correct that this is a bug. -- You received

Re: [clojure.spec/form] Need for evaluated subspecs

Thanks Alex, I am surprised by info that *"s/and (and all of the spec forms) are macros to facilitate capturing the spec form for use in s/form and error reporting." *but everything makes sense considering it. Marián On Thursday, May 18, 2017 at 6:35:46 PM UTC+2, Alex Miller wrote: > > > > On

Re: [clojure.spec/form] Need for evaluated subspecs

Hi Alex, thanks for replying. Indeed I don't have practical use for s/form right now; I'm just trying to guess what could be a good use in the future :) On Thursday, May 18, 2017 at 10:01:25 PM UTC+2, Alex Miller wrote: > > > > On Thursday, May 18, 2017 at 12:37:26 PM UTC-5, Leon Grapenthin

Re: [clojure.spec/form] Need for evaluated subspecs

On Thursday, May 18, 2017 at 12:37:26 PM UTC-5, Leon Grapenthin wrote: > > I also have this problem. > > 1. If I create a dynamic spec constructor per defmacro and invoke it, it's > s/form gives the primitive specs form - because spec doesn't provide me > with a way to facilitate specs that

Re: [clojure.spec/form] Need for evaluated subspecs

I also have this problem. 1. If I create a dynamic spec constructor per defmacro and invoke it, it's s/form gives the primitive specs form - because spec doesn't provide me with a way to facilitate specs that capture their form. 2. If I apply that invocation to another primitive spec, s/form

Re: [clojure.spec/form] Need for evaluated subspecs

On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, marian.hor...@vacuumlabs.com wrote: > > Hi, > > I am writing a function that transforms Specs to another formats (similar > to the JSON Schema). Assuming from this post >

Re: Clojure.spec: need function equivalents of library macros?

On Tuesday, May 9, 2017 at 6:21:29 AM UTC-5, Dave Tenny wrote: > > My issues aren't about qualified or unqualified keys (and the APIs > generally need to accept unqualified keys - I do use qualified keys in > various contexts, just not this post where the topic is macros vs. > non-macro

Re: Clojure.spec: need function equivalents of library macros?

My issues aren't about qualified or unqualified keys (and the APIs generally need to accept unqualified keys - I do use qualified keys in various contexts, just not this post where the topic is macros vs. non-macro forms). s/merge is a good point about composition. However often all I really

Re: Clojure.spec: need function equivalents of library macros?

Is there any reason why you're using unqualified keys? If you're using qualified keys, then a simple (s/keys) spec will validate all registered keys in the map so you can cover all of your optional attribute cases that way. Another possibility worth mentioning is using s/merge to combine

Re: Clojure.spec: need function equivalents of library macros?

Oops, some corrections to my original post. On Monday, May 8, 2017 at 11:38:34 AM UTC-4, Dave Tenny wrote: > > Let's say I have a namespace that provides access to the database, > say our table has these fields (as clojure specs) > > (s/def ::job-id nat-int?) ; 1 2 3 ... > (s/def ::job-name

Re: clojure.spec explain and multi-arity functions with first optional argument

Please try whether my CLJ-2013 patch fixes the issue for you. From my observation it should. On Saturday, April 22, 2017 at 7:31:48 PM UTC+2, Yegor Timoshenko wrote: > > (require '[clojure.spec :as s]) > (require '[clojure.spec.test :refer

Re: clojure.spec s/keys map key with alternative definitions in same namespace

>From my perspective, there are two specs. I'm not trying to mash them together, however I would like to use the appropriate spec with the same keyword in maps, in different contexts. It wouldn't be an issue if the contexts were in separate namespaces. It's only an issue because the two specs

Re: clojure.spec s/keys map key with alternative definitions in same namespace

Spec names are intended to have enduring global semantics. So the notion of the same spec name having different semantics at different times seems to be at odds with that. In general, it's often helpful to think about all the possible values that an attribute will have - that's the true spec.

Re: Clojure.spec, maps, restrict valid keywords, easier way?

Bruce Hauman has done some work in this area both in figwheel and in a branch of leiningen. Basically, if I understand correctly, he looks for misspelled keywords in configuration maps by taking the levenstein distance between expected, valid, keywords and non-matching keywords in the

Re: Clojure.spec, maps, restrict valid keywords, easier way?

I have found eastwood to be useful for a number of things, however on keyword checking it failed terribly on our code base, though perhaps there have been updates since I last tried it. Thanks for the suggestion though. On Friday, February 3, 2017 at 7:26:01 PM UTC-5, Ben Brinckerhoff wrote: >

Re: Clojure.spec, maps, restrict valid keywords, easier way?

I'm actually planning to do exactly that in Cursive, and it's more or less what Eastwood does too per the link Ben posted. On 4 February 2017 at 14:23, Linus Ericsson wrote: > It would be great if an editor highlighted a (possibly qualified) keyword > that was used

Re: Clojure.spec, maps, restrict valid keywords, easier way?

It would be great if an editor highlighted a (possibly qualified) keyword that was used only in that particular place (given all code loaded). This wouldn't be bullet-proof, but would have highlighted mistakes like :encypted (but could still confuse :encrypted? with :encrypted, and whatnot).

Re: Clojure.spec, maps, restrict valid keywords, easier way?

The eastwood linter can also be configured to look for possibly misspelled keyword typos https://github.com/jonase/eastwood#keyword-typos On Friday, February 3, 2017 at 3:47:21 AM UTC-7, John Schmidt wrote: > > I suggest something like (defn fetch-encrypted [] (fetch-important-data > {:encrypt

Re: Clojure.spec, maps, restrict valid keywords, easier way?

I suggest something like (defn fetch-encrypted [] (fetch-important-data {:encrypt true})) + unit tests On Friday, February 3, 2017 at 2:56:34 AM UTC+1, Michael Gardner wrote: > > What would be the Right Way to deal with typos like (fetch-important-data > {:encypt true}), where the :encrypt key

Re: Clojure.spec, maps, restrict valid keywords, easier way?

What would be the Right Way to deal with typos like (fetch-important-data {:encypt true}), where the :encrypt key is optional? Timothy mentions auto-complete, which is better than nothing but doesn't feel like a real solution (especially to those who don't use auto-complete). > On Feb 2, 2017,

Re: Clojure.spec, maps, restrict valid keywords, easier way?

A good editor should auto-complete your keywords for you. Since using this feature in Cursive (same sort of thing is available in other editors) the cases where I've mis-spelled a keyword have dropped dramatically. It's a lot harder to mis-spell a keyword when you can just do: :egg/th and the rest

Re: Clojure.spec, maps, restrict valid keywords, easier way?

Ugh, don't do that. Introducing layers that add no value is a bad idea. Just use the keyword directly. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members

Re: Clojure.spec, maps, restrict valid keywords, easier way?

Keyword literals are inherently misspellable and trying to solve that problem with Spec does not really hit the nail on the head. But there is a solution: You do not have to use keyword literals very much! Instead of using, say, :egg/thunder throughout your program, def a var as :egg/thunder

Re: Clojure.spec, maps, restrict valid keywords, easier way?

Hello Alex, The idea is (as I understand it) that every function should accept any map and pick keys which it understands. If some keys are critical, then they should be marked as such in the spec. Function might iterate over keys and raise an error if there are keys which belong to the

Re: Clojure.spec, maps, restrict valid keywords, easier way?

On Thursday, February 2, 2017 at 10:07:31 AM UTC-5, Alex Miller wrote: > > We don't encourage you to do this, but I don't have an easier solution > than this. > Yes, and from the general standpoint of map handling I understand that. >From the standpoint of functions that take options and don't

Re: Clojure.spec, maps, restrict valid keywords, easier way?

We don't encourage you to do this, but I don't have an easier solution than this. On Thursday, February 2, 2017 at 7:05:37 AM UTC-6, Dave Tenny wrote: > > I want to specify in clojure spec that only declared keywords are > permitted in function calls. > This is to catch what are usually

Re: clojure.spec: behaviour of ? macro

Hi Leon, thanks a lot for your explanation that a "regex-op outside of a regex-op always specs a collection". Then the behaviour is indeed clear Best regards Marc Am Sonntag, 29. Januar 2017 00:32:14 UTC+1 schrieb Leon Grapenthin: > > Hi Marc, > > note that the return of gen/sample is 10

Re: clojure.spec: behaviour of ? macro

Hi Marc, note that the return of gen/sample is 10 examples. Each one is a collection. So the collection [] matches your spec, as does [:c]. And so on. A regex-op outside of a regex-op always specs a collection. If used within another regex-op, it just specs an element. To illustrate:

Re: clojure.spec bug?

No worries! Big thanks for digging into this, I saw your update on the JIRA as well and it certainly seems like you've found the likely culprit. On Monday, January 2, 2017 at 4:47:53 PM UTC+1, miner wrote: > > > On Jan 1, 2017, at 7:13 PM, John Schmidt > wrote: > >

Re: clojure.spec bug?

> On Jan 1, 2017, at 7:13 PM, John Schmidt wrote: > > Steve: both ::game3 and ::game4 from your suggestions result in the same > error. > Sorry for my mistaken conjecture. My issue with the macroexpansion looks like a red herring. I guess I confused myself with

Re: clojure.spec bug?

JIRA filed: http://dev.clojure.org/jira/browse/CLJ-2094. Steve: both ::game3 and ::game4 from your suggestions result in the same error. On Saturday, December 31, 2016 at 5:44:47 PM UTC+1, Alex Miller wrote: > > You can file a jira on this. > > On Saturday, December 31, 2016 at 10:16:00 AM

Re: clojure.spec bug?

You can file a jira on this. On Saturday, December 31, 2016 at 10:16:00 AM UTC-6, miner wrote: > > > On Dec 30, 2016, at 9:42 AM, John Schmidt > wrote: > > (s/def ::game1 #(satisfies? Game %)) > (s/def ::game2 (partial satisfies? Game)) > > > (s/explain ::game2

Re: clojure.spec bug?

> On Dec 30, 2016, at 9:42 AM, John Schmidt wrote: > > (s/def ::game1 #(satisfies? Game %)) > (s/def ::game2 (partial satisfies? Game)) > > (s/explain ::game2 (spec-test.foo/->Foo)) > val: #spec_test.foo.Foo{} fails spec: :spec-test.core/game2 predicate: > (partial

Re: clojure.spec bug?

Sorry, I read your original email on my phone and misread part of your code (thinking I’d seen an `instrument` call in there), so I thought it was the problem with instrumentation breaking (some) protocol-based functions. Now I look at this on the big screen, I realize my mistake. I

Re: clojure.spec bug?

Thanks for the reply Sean. Could you explain a bit more why/how this is the same issue? The ticket seems to revolve around instrumentation and results in exceptions, not validation failures. And if the issue is with protocol functions, how come the ::game1 spec works while the ::game2 spec

Re: clojure.spec bug?

See http://dev.clojure.org/jira/browse/CLJ-1941 (in particular, the comments about protocols) Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood On 12/30/16, 6:42 AM,

Re: Clojure.spec - Why should you use and when

Hi Rickesh Take a look at this: http://clojure.org/about/spec -Patrick On Sunday, December 11, 2016 at 5:30:19 PM UTC+1, Rickesh Bedia wrote: > > Hello, > > I have recently watched Rich Hickeys talk at Cojure Conj 2016 ( > https://www.youtube.com/watch?v=oyLBGkS5ICk - here's the link in case

Re: clojure.spec - seeking a working example of stest/instrument with the :replace option

Alex - Perfect. Thank you for the clarification. I wasn’t sure from the documentation. Specs for functions in spec would be really helpful. Thank you very much. > On Nov 8, 2016, at 08:59, Alex Miller wrote: > > The issue is in the call to instrument: > >

Re: clojure.spec - seeking a working example of stest/instrument with the :replace option

The issue is in the call to instrument: (stest/instrument `ranged-rand {:replace {`ranged-rand ::ranged-const}}) The :replace map is "a map from var-name symbols to replacement fns". Here, you are passing a spec name, rather than a function. So you want something like this instead:

Re: clojure.spec gen-testing VS NaN

Alright cool, I'll do that tomorrow :) Thanks, Dimitris On 07/11/16 22:07, Alex Miller wrote: I think it would be reasonable to log a jira enhancement request for the spec any? generator to avoid generating double NaNs. On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote:

Re: clojure.spec gen-testing VS NaN

I think it would be reasonable to log a jira enhancement request for the spec any? generator to avoid generating double NaNs. On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote: > > Hi Alex, > > Oh yeah I've seen `s/double-in` but as you point out that doesn't help me > if I

Re: clojure.spec predicate generator question

On Sunday, November 6, 2016 at 5:01:23 AM UTC-6, Jim foo.bar wrote: > > Hi all, > > Without having looked at the test.check internals, I'm trying to figure > out roughly what kind of generator function, the following spec will give: > > (s/def ::predicate (s/fspec :args (s/cat :x any?) >

Re: clojure.spec gen-testing VS NaN

Hi Alex, Oh yeah I've seen `s/double-in` but as you point out that doesn't help me if I want to :ret spec a function with similar semantics as remove (a fn that transforms a seq given a predicate), which I find a very common indeed. I'm only starting playing with clojure.spec (in fact i've

Re: clojure.spec gen-testing VS NaN

Please also take a look at s/double-in, which allows you to exclude NaN (and Infinity/-Infinity) as valid values. (I realize this does not address the any? question, but that seems like a rarer issue to me than cases where I'm explicitly spec'ing a double but don't want to allow NaN.) On

Re: clojure.spec - relationship between :args

Hi Michal, Oh yeah, I've actually improved the spec I shared over the weekend, in a similar direction you're hinting. Basically, i've split the :found & :not-found cases, and using `gen/one-of`. Many thanks :) regards, Dimitris On 07/11/16 11:41, Michał Marczyk wrote: Only one quick

Re: clojure.spec - relationship between :args

Only one quick bit of feedback – it's preferable to use test.check facilities instead of (rand) because they're "repeatable": the seed emitted in test.check output can be used to rerun the test with the same test.check PRNG state (see the docstring on clojure.test.check/quick-check, specifically

Re: clojure.spec - relationship between :args

Hi Alex, I think I've figured it out. Here is the complete solution I've come up with in case you feel like providing feedback: (defn- extract-sensible-k-gen "Gen override for `::extract-args`." [] (gen/bind (spc/gen ::persistent-coll) #(let [r (rand) heads? ( >= r0.5)];;

Re: clojure.spec - relationship between :args

HI Alex, Many thanks for your response, it was very helpful. I see your point about customizing the generator, and in fact the video in the link does something sort of similar to what I am trying to. So yeah I'll figure it out tomorrow :). Thanks again! Dimitris On 03/11/16 18:53, Alex

Re: clojure.spec - relationship between :args

On Thursday, November 3, 2016 at 1:12:39 PM UTC-5, Jim foo.bar wrote: > > Hi everyone, > > I'm starting to get familiar with clojure.spec, and in my very first spec > I needed to specify relationship between the args themselves (similar to > how :fn specs allow for specifying some relationship

Re: clojure.spec: Relationships Between Specs

Very cool. Thanks! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group,

Re: clojure.spec: Relationships Between Specs

Sorry, should have been :req, not ::req in there. :) It generates too: user=> (gen/sample (s/gen ::xrange)) (#:user{:x0 0, :x1 1} #:user{:x0 1, :x1 5} #:user{:x0 0, :x1 1} #:user{:x0 0, :x1 1} #:user{:x0 2, :x1 9} #:user{:x0 0, :x1 13} #:user{:x0 0, :x1 6} #:user{:x0 1, :x1 62} #:user{:x0 2,

Re: clojure.spec: Relationships Between Specs

s/and will flow the conformed result to the next predicate so something like this should work: (s/def ::xrange (s/and (s/keys ::req [::x0 ::x1]) (fn [{:keys [::x0 ::x1]}] (< x0 x1 On Wednesday, October 19, 2016 at 12:27:04 PM UTC-5, Mark Bastian wrote: > > Is it possible to

Re: clojure.spec, conform and returned value

On Tuesday, October 11, 2016 at 1:30:18 PM UTC-5, plamen.use...@gmail.com wrote: > > Hello, > > I have a problem which is probably not in the spirit of clojure.spec as > being a library for "only" checking/generating valid values, but of > substantial practical value for my use case: > > Let

Re: clojure.spec, conform and returned value

Amazing! Lot of thanks Josh! This solves everything. It is even written in the API doc, but I missed the important piece of "(possibly converted) value"... With best regards Plamen On Tuesday, October 11, 2016 at 8:49:16 PM UTC+2, Josh Tilles wrote: > > I think you’re looking for conformer >

Re: clojure.spec, conform and returned value

I think you’re looking for conformer ; the spec it produces will pass along the converted value instead of the original input. It could be used like: (defn str->double [s] (try (Double/valueOf s)

Re: clojure.spec to match string

Thanks for all. I will look at your suggestions. > On Sep 29, 2016, at 20:59, lvh <_...@lvh.io> wrote: > >> >> On Sep 29, 2016, at 11:42 AM, Sean Corfield > > wrote: >> >> The test.chuck library from Gary Fredericks has a generator for regex >>

Re: clojure.spec to match string

> On Sep 29, 2016, at 11:42 AM, Sean Corfield wrote: > > The test.chuck library from Gary Fredericks has a generator for regex strings > that works pretty well. Whenever I get some time (not soon, if my inbox is anything to go by), I’ll add the equivalent part to schpec.

Re: clojure.spec to match string

The test.chuck library from Gary Fredericks has a generator for regex strings that works pretty well. Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood On 9/29/16, 7:20

Re: clojure.spec to match string

Thank you Alex. That’s true, I can use just predicate to validate string. But I want a little more from this. I really want to use generators and conforming. I know that strings are seqable, s/cat works with seq. So my question is: Are there any way to combine this? > On Sep 29, 2016, at

Re: clojure.spec question

#{{"id" 1 "name" "john"}} is a valid spec for that On Saturday, September 24, 2016 at 9:46:55 AM UTC-5, Philos Kim wrote: > > How can I define the following spec? > > {"id" 1 "name" "john"} > > 1) The keys of a map must be the string type, not the keyword type. > > 2) The values must be fixed.

Re: clojure.spec - suggestion on how to simplify :pre and :post conditions by using specs.

I think a natural place of the :post condition shold be after the argument brackets (and that should be possible to implement I think): (defn user-name [user :core/user] :user/name (-> user :user/name)) On Friday, September 16, 2016 at 1:34:47 PM UTC+2, joakim.t...@nova.com wrote: > > (ns

Re: clojure.spec - Using :pre conditions (or not)?

I agree with you that an IllegalArgumentException is preferable to AssertionError. The reason that I used AssertionError was that I wanted to keep the same behaviour as when using s/valid? (it throws an AssertionError). Maybe only s/assert should throw AssertionError and s/valid? should throw

Re: clojure.spec - Using :pre conditions (or not)?

When function is throwing exception because of argument. I would prefer to throw IllegalArgumentException not AssertionError. (defn check [type data] (if (sp/valid? type data) true (throw (IllegalArgumentException. (sp/explain type data) Br, Mamun On Friday, September 16,

Re: clojure.spec - Using :pre conditions (or not)?

I came up with this solution: (ns spec-test.core (:require [clojure.spec :as s])) (s/def :user/name string?) (s/def :common/user (s/keys :req [:user/name])) ;; with this little helper function... (defn check [type data] (if (s/valid? type data) true (throw (AssertionError.

Re: clojure.spec - Using :pre conditions (or not)?

Thanks for the tip! On Thursday, September 15, 2016 at 3:11:32 PM UTC+2, Shantanu Kumar wrote: > > Hi Joakim, > > You might be interested in Paul Stadig's library > https://github.com/pjstadig/assertions that leverages Java's `-ea` > (enable-assertions, which you may want to keep enabled in

Re: clojure.spec - Using :pre conditions (or not)?

Hi Joakim, You might be interested in Paul Stadig's library https://github.com/pjstadig/assertions that leverages Java's `-ea` (enable-assertions, which you may want to keep enabled in dev) command-line flag. If you have a bunch of things together to assert, you may want to use the

Re: clojure.spec - Using :pre conditions (or not)?

Ok, thanks! In the Java world, the assertions is also something that need to be turn on explicitly. In that sence, they are kind of not mandatory to be executed (or at least signals that to the reader of the code). I would be happier if you guys could add another method, that I can use in my

Re: clojure.spec - Using :pre conditions (or not)?

Another option that has been added since the guide was written is s/assert which seems closer to what you're suggesting. (defn name [user] {:pre [(s/assert :common/user user)]} (-> user :user/name)) ;; need to enable assertion checking - this can also be enabled globally with system

Re: clojure.spec origin story

>From clojure.spec - Rationale and overview : Almost nothing about spec is novel. See all the libraries mentioned above, RDF , as well as all the work done on various contract systems, such as Racket’s

Re: clojure.spec origin story

I haven't checked it myself but I remember reading that Clojure Specs were roughly based on Racket's Contracts. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send

Re: clojure.spec for specifying sequences of states over time

A few thoughts on your design and a possible solution to your problem. Firstly if we are concerned about the correct ordering of values over time, then it sounds like we are dealing with something that contains hidden mutable state. That hidden state is a can be problematic. In general, when

Re: clojure.spec for specifying sequences of states over time

There are a variety of possible extensions to what is currently offered by spec wrt regex derivatives but that's up to Rich. On Friday, August 5, 2016 at 12:37:15 PM UTC-5, Russell Mull wrote: > > Suppose you have a reactive process, something that receives a message, > processes it, updates

Re: clojure.spec merge is excellent, but do you consider dissoc spec for keys?

Well first I'd say it's actually more important here that you are reusing the attribute specs for ::fname ::lname etc across front and back. And second, perhaps you should be breaking out the common parts into a spec you can reuse instead: (s/def ::person-shared-spec (s/keys ::req-un [::fname

Re: clojure.spec and generic map with couple of special keys

That’s what I needed! Thanks On Tue, Jul 5, 2016 at 8:15 PM gsnewmark wrote: > If I'm not mistaken, similar issue was recently discussed on the > Clojurians Slack (direct link - > https://clojurians.slack.com/archives/clojure-spec/p146738221722 , > archive link - >

Re: clojure.spec regression bug for 1.9.0-alpha6

There is nothing provided or planned to do that. On Tuesday, July 5, 2016 at 8:43:31 AM UTC-5, Nikita Prokopov wrote: > > How to I make spec/fdef and regular clojure.test (not generative ones) > work together? I’d like for my :ret specs and HOF :ret specs to be checked > during regular tests.

Re: clojure.spec and generic map with couple of special keys

If I'm not mistaken, similar issue was recently discussed on the Clojurians Slack (direct link - https://clojurians.slack.com/archives/clojure-spec/p146738221722 , archive link - https://clojurians-log.clojureverse.org/clojure-spec/2016-07-01.html - discussion starts from @ghadi's post at

Re: clojure.spec regression bug for 1.9.0-alpha6

How to I make spec/fdef and regular clojure.test (not generative ones) work together? I’d like for my :ret specs and HOF :ret specs to be checked during regular tests. Is that possible? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to

Re: clojure.spec and generic map with couple of special keys

I ran into this same issue while trying to spec Clojure's destructuring language. I asked a question about this on Stack Overflow: http://stackoverflow.com/q/38151446/5044950 On Tuesday, July 5, 2016 at 9:16:40 AM UTC-4, Nikita Prokopov wrote: > > Imagine I have a generic keyword => string map

Re: clojure.spec - s/and interferes with regular expressions

Using s/& and Mark’s fdef does “work” but the failure messages seem misleading: boot.user=> (f 2 :even 4) nil boot.user=> (f 2 :even 3) clojure.lang.ExceptionInfo: Call to #'boot.user/f did not conform to spec:     val: () fails at: [:args :options] predicate: (&

Re: clojure.spec - s/and interferes with regular expressions

As soon as you introduce the s/and, you have dropped out of regex land and into a predicate. You are then matching something in a new nested regex inside the and like: [[::even 4]]. To stay within the top-level regex and supply extra predicates, use s/& instead: (s/def ::options (s/&

Re: clojure.spec Invalid token error from different namespace when specs are registered with number

According to the reader page (http://clojure.org/reference/reader), keyword names can't start with a number. However, unqualified keywords that start with a number have (accidentally) worked for a long time and we have effectively grandfathered them in. You're seeing some of the ragged edges

Re: clojure.spec Invalid token error from different namespace when specs are registered with number

I believe that this is a problem with how the reader resolves aliased keywords as the problem can be reproduced without spec. You should file a JIRA ticket. On Wednesday, June 29, 2016 at 9:22:49 AM UTC+2, Mamun wrote: > > Hi, > > Invalid token error from different namespace when specs are

Re: clojure.spec Invalid token error from different namespace when specs are registered with number

Have isolated more: Namespaced keywords with numbers in the name all don't work, but when using double-colon syntax they can be fabricated. :a/1 -> RuntimeException Invalid token: :a/1 clojure.lang.Util.runtimeException (Util.java:221) :user/1 -> RuntimeException Invalid token: :a/1

  1   2   3   >