date:20171006

Re: any? in clojure 1.9.0 alpha

2017-10-06 Thread Alex Miller

This ship has sailed.

> On Oct 6, 2017, at 6:04 PM, Alan Thompson  wrote:
> 
> Before 1.9.0 is officially released, I would like to propose a revisit to the 
> semantic mismatch introduced by the clojure.core/any? function.
> 
> Many, many people are dissatisfied by the choice of clojure.core/any? to be 
> defined as (constantly true), which is completely in conflict with 
> clojure.core/not-any? .After all, any logical person would automatically 
> assume that:
> 
> (= (not-any? args...) (not (any? args...))  
> 
> for any set of legal arguments.  This follows the well-established tradition 
> in Clojure of having negated pairs such as if vs if-not,  when vs when-not, 
> every? vs not-every?, etc.
> 
> However, I can see that it is convenient to say something like this:
> 
> (s/fdef clojure.core/declare
> :args (s/cat :names (s/* simple-symbol?))
> :ret any?)
> 
> It seems a simple solution to the problem would be to just define some 
> keyword specs in place of the globally visible any? function.  The following 
> example shows that we could define :clojure.spec/pass-all and 
> :clojure.spec/pass-none which would could serve as an exact replacement for 
> any? (& its negative).
> 
> (:require [clojure.spec.alpha :as s] ...)
> (deftest demo
>   (s/def ::s/pass-all  (constantly true))
>   (s/def ::s/pass-none (constantly false))
> 
>   (is  (s/valid? ::s/pass-all 5 ))
>   (is  (s/valid? ::s/pass-all "joe" ))
>   (is  (s/valid? ::s/pass-all { :blah 42 :blue 66 :hut! 'hut! }))
>   (is (not (s/valid? ::s/pass-none 5 
> 
> Since 1.9.0 is not out yet, is not too late to avoid a permanent pollution of 
> the language with a gigantic mistake such as any?.  At the very least, the 
> function could be moved to clojure.spec/any? from clojure.core.  If we insist 
> on adding this blatant contradiction to clojure.core, we won't even have the 
> excuse of a committee to blame it on.
> 
> Alan Thompson
> 
> 
> 
>> On Sun, Nov 13, 2016 at 4:15 PM, Nathan Smutz  wrote:
>> Is there a Tricky Names for Nubies page?
>> We might save some stack-overflow searches.
>> 
>> In the spirit of Honest Trailers: if we named functions for what they do:
>> or-> first-truthy
>> some  -> first-satisfying
>> some? -> not-nil?
>> any?  -> return-true
>> 
>> Are there others?
>> 
>> --
>> 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, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojure-dev.
> For more options, visit https://groups.google.com/d/optout.

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [core.spec] Stricter map validations?

2017-10-06 Thread Leon Grapenthin

The argument that existence of specs provided to s/keys can only be checked 
at runtime is false.

The argument that that recursive specs are impossible if existence of specs 
provided to s/keys was checked at compile time is also false. 

The usecase for libraries is not convincing: If the libraries author states 
"the map has to have a key K" nobody can spec K further since that would be 
a race condition among consumers (who s/defs K first?). Requiring the 
libraries author to declare K as any? would at least require him to decide 
and convey his intent.

The argument that not checking a value associated with a key is 
corresponding to a guding design principle of map specs being based on a 
keyset is not stating enough to justify discussed behavior. The utility of 
knowing that a keyset is present is close to none, which should be the main 
reasons why s/keys validates values. Again: Saying "A map that has a key 
called ::foo" is pretty pointless in Clojure. If every map in every Clojure 
program I wrote had a key ::foo they would all produce the exact same 
results as if they didn't and I bet yours would, too. 

Prototyping is indeed a bit more easy if one does not have to to declare 
every spec used in a s/keys. However, that is particularly damning if you 
forget to add that spec later or mistype its name when doing so. Which 
happens, and which is why I'm unhappy with this design letting such typical 
human errors pass compilation. It would also help my prototyping needs if I 
could reference symbols that are not declared, but I prefer the compiler 
errors before going live. 

On Saturday, October 7, 2017 at 12:01:34 AM UTC+2, Sean Corfield wrote:
>
> As one of the (apparently pretty uncommon) users who actually does happily 
> define s/keys specs without correspondingly speccing the leaves as an 
> "incrementally lock down/validate" approach, I wouldn't be too upset if I 
> lost that ability and it started throwing an error. I mean it throws an 
> error if I go to generate it anyway.
>
>  
>
> **puts hand up!**
>
>  
>
> I don’t want to have to write (s/def ::some-key any?) all over the place 
> as I’m developing specs, just to satisfy an overly eager checker (in my 
> mind). Worse, since the check would need to be deferred until validation 
> time, as Beau notes, the omission of an “any?” key spec might not even show 
> up until much further down the line.
>
>  
>
> To me, this default behavior of silently not checking the _*value*_ 
> associated with a _*key*_ is in keeping with the design principles of 
> spec which focus on maps being based on a *key set*, while offering 
> functions to allow you to optionally check values.
>
>  
>
> 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
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Beau Fabry 
> *Sent:* Friday, October 6, 2017 9:10:36 AM
> *To:* Clojure
> *Subject:* Re: [core.spec] Stricter map validations? 
>  
> A use case that comes to mind is a system/library that specifies the 
> structure of some inputs/outputs, but lets users/consumers (optionally) 
> specify further validation of the leaves. I suppose that would be possible 
> with (s/def ::foo any?) but you'd have to be a bit more careful about load 
> order. The other use case (which is mine) is I'm just lazy and only want to 
> write out broad strokes specs sometimes without getting into the nitty 
> gritty. 
>
> If s/keys were to validate that the keys it's provided have specs it would 
> have to do it at validation time, so you wouldn't get the error until 
> something was actually validated against that key spec. Trying to do it at 
> definition time would break recursive specs.
>
> As one of the (apparently pretty uncommon) users who actually does happily 
> define s/keys specs without correspondingly speccing the leaves as an 
> "incrementally lock down/validate" approach, I wouldn't be too upset if I 
> lost that ability and it started throwing an error. I mean it throws an 
> error if I go to generate it anyway.
>
> On Friday, October 6, 2017 at 8:58:38 AM UTC-7, Leon Grapenthin wrote: 
>>
>> Thanks, Beau. 
>>
>> I am still interested why this default behavior has been chosen. It 
>> doesn't seem like a reasonable trade-off at this point.
>>
>> It enables me to say: "The map must have this key", without specifying 
>> how the data mapped to it will look like.
>>
>> If I ever wanted to do that, I could as well spec that key with "any?".
>>
>> What are other benefits? They must justify the expense of likely runtime 
>> errors.
>>
>>
>> On Friday, October 6, 2017 at 5:34:16 PM UTC+2, Beau Fabry wrote: 
>>>
>>> Leon, perhaps you could add this code to your test suite? 
>>>
>>> boot.user=> (let [kws (atom #{})]
>>>#_=>   (clojure.walk/postwalk (fn [x] (when

Re: [core.spec] Stricter map validations?

2017-10-06 Thread Leon Grapenthin

The argument that existence of specs provided to s/keys can only be checked 
at runtime is false.

The argument that that recursive specs are impossible if existence of specs 
provided to s/keys was checked at compile time is also false. 

The usecase for libraries is not convincing: If the libraries author states 
"the map has to have a key K" nobody can spec K further since that would be 
a race condition among consumers (who s/defs K first?). Requiring the 
libraries author to declare K as any? would at least require him to decide 
and convey his intent.

The argument that not checking a value associated with a key is 
corresponding to a guding design principle of map specs being based on a 
keyset is not stating enough to justify discussed behavior. The utility of 
knowing that a keyset is present is close to none, which should be the main 
reasons why s/keys validates values. Again: Saying "A map that has a key 
called ::foo" is pretty pointless in Clojure. If every map in every Clojure 
program I wrote had a key ::foo they would all produce the exact same 
results as if they didn't and I bet yours would, too. 

So prototyping is indeed more easy if one does not have to to declare every 
spec used in a s/keys. However, that is particularly damning if you forget 
to add that spec later or mistype its name when doing so. Which happens, 
and which is why I'm unhappy with this design letting such typical human 
errors pass compilation. It would also help my prototyping needs if I could 
reference symbols that are not declared, but I the compiler errors before I 
go live. 

On Saturday, October 7, 2017 at 12:01:34 AM UTC+2, Sean Corfield wrote:
>
> As one of the (apparently pretty uncommon) users who actually does happily 
> define s/keys specs without correspondingly speccing the leaves as an 
> "incrementally lock down/validate" approach, I wouldn't be too upset if I 
> lost that ability and it started throwing an error. I mean it throws an 
> error if I go to generate it anyway.
>
>  
>
> **puts hand up!**
>
>  
>
> I don’t want to have to write (s/def ::some-key any?) all over the place 
> as I’m developing specs, just to satisfy an overly eager checker (in my 
> mind). Worse, since the check would need to be deferred until validation 
> time, as Beau notes, the omission of an “any?” key spec might not even show 
> up until much further down the line.
>
>  
>
> To me, this default behavior of silently not checking the _*value*_ 
> associated with a _*key*_ is in keeping with the design principles of 
> spec which focus on maps being based on a *key set*, while offering 
> functions to allow you to optionally check values.
>
>  
>
> 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
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Beau Fabry 
> *Sent:* Friday, October 6, 2017 9:10:36 AM
> *To:* Clojure
> *Subject:* Re: [core.spec] Stricter map validations? 
>  
> A use case that comes to mind is a system/library that specifies the 
> structure of some inputs/outputs, but lets users/consumers (optionally) 
> specify further validation of the leaves. I suppose that would be possible 
> with (s/def ::foo any?) but you'd have to be a bit more careful about load 
> order. The other use case (which is mine) is I'm just lazy and only want to 
> write out broad strokes specs sometimes without getting into the nitty 
> gritty. 
>
> If s/keys were to validate that the keys it's provided have specs it would 
> have to do it at validation time, so you wouldn't get the error until 
> something was actually validated against that key spec. Trying to do it at 
> definition time would break recursive specs.
>
> As one of the (apparently pretty uncommon) users who actually does happily 
> define s/keys specs without correspondingly speccing the leaves as an 
> "incrementally lock down/validate" approach, I wouldn't be too upset if I 
> lost that ability and it started throwing an error. I mean it throws an 
> error if I go to generate it anyway.
>
> On Friday, October 6, 2017 at 8:58:38 AM UTC-7, Leon Grapenthin wrote: 
>>
>> Thanks, Beau. 
>>
>> I am still interested why this default behavior has been chosen. It 
>> doesn't seem like a reasonable trade-off at this point.
>>
>> It enables me to say: "The map must have this key", without specifying 
>> how the data mapped to it will look like.
>>
>> If I ever wanted to do that, I could as well spec that key with "any?".
>>
>> What are other benefits? They must justify the expense of likely runtime 
>> errors.
>>
>>
>> On Friday, October 6, 2017 at 5:34:16 PM UTC+2, Beau Fabry wrote: 
>>>
>>> Leon, perhaps you could add this code to your test suite? 
>>>
>>> boot.user=> (let [kws (atom #{})]
>>>#_=>   (clojure.walk/postwalk (fn [x] (when

Re: Help ship Clojure 1.9!

2017-10-06 Thread Alan Thompson

Before Clojure 1.9 is shipped, I would like to reiterate the appeal from
many in the community to stop the terrible, permanent mistake that is
*clojure.core/any?*

For those who have not seen past emails on this topic, you may view the
main threads here:

   -

https://groups.google.com/forum/#!searchin/clojure/semantic$20mismatch$20any%7Csort:relevance/clojure/f25y6N1OiIo/5Gq70PV1CAAJ
   -

https://groups.google.com/forum/#!searchin/clojure/any$20not-any$20mismatch%7Csort:relevance/clojure/2l2f1jKExUc/aX4KpqlABAAJ
   -

https://groups.google.com/forum/#!searchin/clojure/any$20not-any$20mismatch%7Csort:relevance/clojure/tPiW2DGHTN0/A4LyknV4BAAJ

Alan

On Wed, Oct 4, 2017 at 1:27 PM, Michał Marczyk 
wrote:

> I've run into a behaviour change that was actually already present in
> alpha20 – with the CLJ-99 patch in place, {min,max}-key now return the
> first argument with the minimum/maximum key, whereas previously they
> returned the last such argument.
>
> The new behaviour seems like the more natural one, but this is a breaking
> change, so I filed https://dev.clojure.org/jira/browse/CLJ-2247 to track
> this (with a patch that takes the "default" approach of restoring
> established behaviour).
>
> Cheers,
> Michał
>
>
> On 3 October 2017 at 21:11, Beau Fabry  wrote:
>
>> We've been using 1.9 in a small app for a while with no issues. After
>> upgrading schema to the latest version (with the PR above) I've also
>> successfully run our larger codebase with 1.9.
>>
>> On Tuesday, October 3, 2017 at 4:41:14 AM UTC-7, stuart@gmail.com
>> wrote:
>>>
>>> Hi Mark,
>>>
>>> I think this approach totally makes sense, and the alpha naming exists
>>> to inform this kind of decision-making.
>>>
>>> For libraries where the use of spec does not have to be user-facing, I
>>> am putting specs in separate (Clojure) namespaces, and loading them in such
>>> a way that they can coexist with non (or maybe different) spec
>>> environments. But that is extra work for sure.
>>>
>>> Stu
>>>
>>> On Mon, Oct 2, 2017 at 3:35 PM, Mark Engelberg 
>>> wrote:
>>>
 On Mon, Oct 2, 2017 at 7:55 AM, Stuart Halloway 
 wrote:

> Hi David,
>
> Spec will be in alpha for a while. That is part of the point of it
> being a separate library. Can you say more about what problems this is
> causing?
>
> Stu
>
>
 As a library maintainer, I am forced to upgrade and release my library
 any time something I depend upon makes a breaking change.  I don't get paid
 for maintaining open source libraries, it's something I do in my spare
 time, so I prefer to do it on my own schedule.  When an underlying library
 makes a breaking change, I get dozens of urgent requests from people who
 need me to cut a new release ASAP, and by Murphy's Law, that often happens
 when I have very little time to do it.  It's a nuisance.

 Clojure is pretty good about not making breaking changes, but it
 happens from time to time.  Clojurescript is less good about not making
 breaking changes, and therefore, maintaining Clojurescript libraries is
 more of a headache.  On the plus side, Clojurescript users seem to care
 very little about backwards compatibility (most keep up with the latest
 version), so sometimes it is easier to make a change to keep up with a
 change in Clojurescript than one in Clojure, where I am expected to not
 only support the latest breaking change, but also the last several 
 releases.

 Anything that is labeled as "alpha" is waving a big red flag that there
 could be breaking changes at any time with little warning.  For my
 libraries which depend on spec, there's no way I'm going to bring them out
 of alpha status until spec comes out of alpha status.  If I make an
 official release of something that depends on spec, then I'm going to be on
 the hook to rapidly cut a new release every time spec changes, which could
 be at any time.  I don't want that hassle.  I don't want to make a promise
 to the community to maintain a stable product if the thing I depend upon
 has not made a similar promise.  When spec reaches a point where the API
 will not be changing, or rather, when we know that new changes will only be
 additive, I can begin to trust that it won't be a huge maintenance headache
 to release something based on spec.

 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You

Re: any? in clojure 1.9.0 alpha

2017-10-06 Thread Alan Thompson

Before 1.9.0 is officially released, I would like to propose a revisit to
the semantic mismatch introduced by the *clojure.core/any? *function.

Many, many people are dissatisfied by the choice of *clojure.core/any?* to
be defined as *(constantly true)*, which is completely in conflict with
*clojure.core/not-any?* .After all, any logical person would
automatically assume that:

(= (not-any? args...) (not (any? args...))

for any set of legal arguments.  This follows the well-established
tradition in Clojure of having negated pairs such as* if* vs *if-not*,
*when *vs *when-not*, *every? *vs* not-every?*, etc.

However, I can see that it is convenient to say something like this:

(s/fdef clojure.core/declare
:args (s/cat :names (s/* simple-symbol?))
:ret any?)

It seems a simple solution to the problem would be to just define some
keyword specs in place of the globally visible *any? *function.  The
following example shows that we could define *:clojure.spec/pass-all *and
*:clojure.spec/pass-none* which would could serve as an exact replacement
for *any? *(& its negative).

(:require [clojure.spec.alpha :as s] ...)
(deftest demo
  (s/def ::s/pass-all  (constantly true))
  (s/def ::s/pass-none (constantly false))

  (is  (s/valid? ::s/pass-all 5 ))
  (is  (s/valid? ::s/pass-all "joe" ))
  (is  (s/valid? ::s/pass-all { :blah 42 :blue 66 :hut! 'hut! }))
  (is (not (s/valid? ::s/pass-none 5 

Since 1.9.0 is not out yet, is not too late to avoid a permanent pollution
of the language with a gigantic mistake such as *any?*.  At the very least,
the function could be moved to *clojure.spec/any?* from *clojure.core*.  If
we insist on adding this blatant contradiction to *clojure.core*, we won't
even have the excuse of a committee to blame it on.

Alan Thompson

On Sun, Nov 13, 2016 at 4:15 PM, Nathan Smutz >
wrote:

> Is there a Tricky Names for Nubies page?
> We might save some stack-overflow searches.
>
> In the spirit of Honest Trailers: if we named functions for what they do:
> or-> first-truthy
> some  -> first-satisfying
> some? -> not-nil?
> any?  -> return-true
>
> Are there others?
>
> --
> 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, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [core.spec] Stricter map validations?

2017-10-06 Thread Sean Corfield

As one of the (apparently pretty uncommon) users who actually does happily 
define s/keys specs without correspondingly speccing the leaves as an 
"incrementally lock down/validate" approach, I wouldn't be too upset if I lost 
that ability and it started throwing an error. I mean it throws an error if I 
go to generate it anyway.

*puts hand up!*

I don’t want to have to write (s/def ::some-key any?) all over the place as I’m 
developing specs, just to satisfy an overly eager checker (in my mind). Worse, 
since the check would need to be deferred until validation time, as Beau notes, 
the omission of an “any?” key spec might not even show up until much further 
down the line.

To me, this default behavior of silently not checking the _value_ associated 
with a _key_ is in keeping with the design principles of spec which focus on 
maps being based on a key set, while offering functions to allow you to 
optionally check values.

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

From: clojure@googlegroups.com  on behalf of Beau 
Fabry 
Sent: Friday, October 6, 2017 9:10:36 AM
To: Clojure
Subject: Re: [core.spec] Stricter map validations?

A use case that comes to mind is a system/library that specifies the structure 
of some inputs/outputs, but lets users/consumers (optionally) specify further 
validation of the leaves. I suppose that would be possible with (s/def ::foo 
any?) but you'd have to be a bit more careful about load order. The other use 
case (which is mine) is I'm just lazy and only want to write out broad strokes 
specs sometimes without getting into the nitty gritty.

If s/keys were to validate that the keys it's provided have specs it would have 
to do it at validation time, so you wouldn't get the error until something was 
actually validated against that key spec. Trying to do it at definition time 
would break recursive specs.

As one of the (apparently pretty uncommon) users who actually does happily 
define s/keys specs without correspondingly speccing the leaves as an 
"incrementally lock down/validate" approach, I wouldn't be too upset if I lost 
that ability and it started throwing an error. I mean it throws an error if I 
go to generate it anyway.

On Friday, October 6, 2017 at 8:58:38 AM UTC-7, Leon Grapenthin wrote:
Thanks, Beau.

I am still interested why this default behavior has been chosen. It doesn't 
seem like a reasonable trade-off at this point.

It enables me to say: "The map must have this key", without specifying how the 
data mapped to it will look like.

If I ever wanted to do that, I could as well spec that key with "any?".

What are other benefits? They must justify the expense of likely runtime errors.

On Friday, October 6, 2017 at 5:34:16 PM UTC+2, Beau Fabry wrote:
Leon, perhaps you could add this code to your test suite?

boot.user=> (let [kws (atom #{})]
   #_=>   (clojure.walk/postwalk (fn [x] (when (qualified-keyword? x) 
(swap! kws conj x)) x) (map s/form (vals (s/registry 
(clojure.set/difference @kws (set (keys (s/registry
   #_=> )
#{:clojure.spec.alpha/v :clojure.spec.alpha/k}
boot.user=>

On Friday, October 6, 2017 at 5:56:29 AM UTC-7, Leon Grapenthin wrote:
Open maps/specs are fine.

s/keys supporting unregistered specs are not.

At least to me. I just fixed two more bugs in production that were would not 
have happened.

What are the supposed benefits of this feature?

I can only infer "being able to require keys without their spec being known" 
which is a usecase I had exactly 0.00% of the time so far.

Anything I have missed?

Kind regards,
 Leon.

On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:
Seems like that's the reasonable place to check it, otherwise you're forced 
into an ordering for your specs and cannot write recursive strict map specs.

On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko wrote:
Thanks. This approach is also different from the macro because it will check 
specs existence at the validation time, not at the s/def call.

On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
Yuri Govorushchenko  writes:

> Thank you the pointers! So far I ended up with writing a small `map` macro
> which is similar to `s/keys` but checks that keys are already in the
> registry: 
> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2

Note that you can simply combine a custom predicate and `s/keys` in
clojure.spec to verify that all keys in a given map have a underlying
spec:

```
(s/def ::whatever (s/and (s/keys ...)
 #(every? keyword? (keys %))
 #(every? (comp boolean s/get-spec) (keys %)) )
```

--
You received this message because you are subscribed to the Google
Groups "Clojure"

[ANN] Clojure 1.9.0-beta2

2017-10-06 Thread Alex Miller

Clojure 1.9.0-beta2 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-beta2
- Leiningen: [org.clojure/clojure "1.9.0-beta2"]

1.9.0-beta2 includes the following changes since 1.9.0-beta1:

- CLJ-700  - (fix) 
`contains?`, `get`, and `find` broken for transient collections
- CLJ-2247  - (regression) 
restore and doc last match semantics of {min,max}-key
- CLJ-2239  - (regression) 
fix Guava javadoc location
- Updated dep to spec.alpha 0.1.134 - see changes 


We would appreciate anything you can do to try out this release. We do not 
plan to make any further changes prior to 1.9.0 release unless regressions 
are found.

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] spec.alpha 0.1.134

2017-10-06 Thread Alex Miller

spec.alpha 0.1.134 is now available.

Try it via:  [org.clojure/spec.alpha "0.1.134"]

0.1.134 includes the following changes:

   - CLJ-2103  - s/coll-of 
   and s/every gen is very slow if :kind specified without :into
   - CLJ-2171  - Default 
   explain printer shouldn't print root val and spec
   - Mark Clojure dependency as a provided dep so it's not transitively 
   included

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [core.spec] Stricter map validations?

2017-10-06 Thread Beau Fabry

A use case that comes to mind is a system/library that specifies the 
structure of some inputs/outputs, but lets users/consumers (optionally) 
specify further validation of the leaves. I suppose that would be possible 
with (s/def ::foo any?) but you'd have to be a bit more careful about load 
order. The other use case (which is mine) is I'm just lazy and only want to 
write out broad strokes specs sometimes without getting into the nitty 
gritty.

If s/keys were to validate that the keys it's provided have specs it would 
have to do it at validation time, so you wouldn't get the error until 
something was actually validated against that key spec. Trying to do it at 
definition time would break recursive specs.

As one of the (apparently pretty uncommon) users who actually does happily 
define s/keys specs without correspondingly speccing the leaves as an 
"incrementally lock down/validate" approach, I wouldn't be too upset if I 
lost that ability and it started throwing an error. I mean it throws an 
error if I go to generate it anyway.

On Friday, October 6, 2017 at 8:58:38 AM UTC-7, Leon Grapenthin wrote:
>
> Thanks, Beau. 
>
> I am still interested why this default behavior has been chosen. It 
> doesn't seem like a reasonable trade-off at this point.
>
> It enables me to say: "The map must have this key", without specifying how 
> the data mapped to it will look like.
>
> If I ever wanted to do that, I could as well spec that key with "any?".
>
> What are other benefits? They must justify the expense of likely runtime 
> errors.
>
>
> On Friday, October 6, 2017 at 5:34:16 PM UTC+2, Beau Fabry wrote:
>>
>> Leon, perhaps you could add this code to your test suite?
>>
>> boot.user=> (let [kws (atom #{})]
>>#_=>   (clojure.walk/postwalk (fn [x] (when (qualified-keyword? x) 
>> (swap! kws conj x)) x) (map s/form (vals (s/registry 
>> (clojure.set/difference @kws (set (keys (s/registry
>>#_=> )
>> #{:clojure.spec.alpha/v :clojure.spec.alpha/k}
>> boot.user=>
>>
>> On Friday, October 6, 2017 at 5:56:29 AM UTC-7, Leon Grapenthin wrote:
>>>
>>> Open maps/specs are fine.
>>>
>>> s/keys supporting unregistered specs are not.
>>>
>>> At least to me. I just fixed two more bugs in production that were would 
>>> not have happened.
>>>
>>> What are the supposed benefits of this feature? 
>>>
>>> I can only infer "being able to require keys without their spec being 
>>> known" which is a usecase I had exactly 0.00% of the time so far.
>>>
>>> Anything I have missed?
>>>
>>> Kind regards,
>>>  Leon.
>>>
>>>
>>> On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:

 Seems like that's the reasonable place to check it, otherwise you're 
 forced into an ordering for your specs and cannot write recursive strict 
 map specs.

 On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko 
 wrote:
>
> Thanks. This approach is also different from the macro because it will 
> check specs existence at the validation time, not at the s/def call.
>
> On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>>
>> Yuri Govorushchenko  writes: 
>>
>> > Thank you the pointers! So far I ended up with writing a small 
>> `map` macro 
>> > which is similar to `s/keys` but checks that keys are already in 
>> the 
>> > registry: 
>> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 
>>
>> Note that you can simply combine a custom predicate and `s/keys` in 
>> clojure.spec to verify that all keys in a given map have a underlying 
>> spec: 
>>
>> ``` 
>> (s/def ::whatever (s/and (s/keys ...) 
>>  #(every? keyword? (keys %)) 
>>  #(every? (comp boolean s/get-spec) (keys %)) 
>> ) 
>> ``` 
>>
>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [core.spec] Stricter map validations?

2017-10-06 Thread Leon Grapenthin

Thanks, Beau. 

I am still interested why this default behavior has been chosen. It doesn't 
seem like a reasonable trade-off at this point.

It enables me to say: "The map must have this key", without specifying how 
the data mapped to it will look like.

If I ever wanted to do that, I could as well spec that key with "any?".

What are other benefits? They must justify the expense of likely runtime 
errors.


On Friday, October 6, 2017 at 5:34:16 PM UTC+2, Beau Fabry wrote:
>
> Leon, perhaps you could add this code to your test suite?
>
> boot.user=> (let [kws (atom #{})]
>#_=>   (clojure.walk/postwalk (fn [x] (when (qualified-keyword? x) 
> (swap! kws conj x)) x) (map s/form (vals (s/registry 
> (clojure.set/difference @kws (set (keys (s/registry
>#_=> )
> #{:clojure.spec.alpha/v :clojure.spec.alpha/k}
> boot.user=>
>
> On Friday, October 6, 2017 at 5:56:29 AM UTC-7, Leon Grapenthin wrote:
>>
>> Open maps/specs are fine.
>>
>> s/keys supporting unregistered specs are not.
>>
>> At least to me. I just fixed two more bugs in production that were would 
>> not have happened.
>>
>> What are the supposed benefits of this feature? 
>>
>> I can only infer "being able to require keys without their spec being 
>> known" which is a usecase I had exactly 0.00% of the time so far.
>>
>> Anything I have missed?
>>
>> Kind regards,
>>  Leon.
>>
>>
>> On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:
>>>
>>> Seems like that's the reasonable place to check it, otherwise you're 
>>> forced into an ordering for your specs and cannot write recursive strict 
>>> map specs.
>>>
>>> On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko 
>>> wrote:

 Thanks. This approach is also different from the macro because it will 
 check specs existence at the validation time, not at the s/def call.

 On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>
> Yuri Govorushchenko  writes: 
>
> > Thank you the pointers! So far I ended up with writing a small `map` 
> macro 
> > which is similar to `s/keys` but checks that keys are already in the 
> > registry: 
> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 
>
> Note that you can simply combine a custom predicate and `s/keys` in 
> clojure.spec to verify that all keys in a given map have a underlying 
> spec: 
>
> ``` 
> (s/def ::whatever (s/and (s/keys ...) 
>  #(every? keyword? (keys %)) 
>  #(every? (comp boolean s/get-spec) (keys %)) 
> ) 
> ``` 
>


-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [core.spec] Stricter map validations?

2017-10-06 Thread Beau Fabry

Leon, perhaps you could add this code to your test suite?

boot.user=> (let [kws (atom #{})]
   #_=>   (clojure.walk/postwalk (fn [x] (when (qualified-keyword? x) 
(swap! kws conj x)) x) (map s/form (vals (s/registry 
(clojure.set/difference @kws (set (keys (s/registry
   #_=> )
#{:clojure.spec.alpha/v :clojure.spec.alpha/k}
boot.user=>

On Friday, October 6, 2017 at 5:56:29 AM UTC-7, Leon Grapenthin wrote:
>
> Open maps/specs are fine.
>
> s/keys supporting unregistered specs are not.
>
> At least to me. I just fixed two more bugs in production that were would 
> not have happened.
>
> What are the supposed benefits of this feature? 
>
> I can only infer "being able to require keys without their spec being 
> known" which is a usecase I had exactly 0.00% of the time so far.
>
> Anything I have missed?
>
> Kind regards,
>  Leon.
>
>
> On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:
>>
>> Seems like that's the reasonable place to check it, otherwise you're 
>> forced into an ordering for your specs and cannot write recursive strict 
>> map specs.
>>
>> On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko 
>> wrote:
>>>
>>> Thanks. This approach is also different from the macro because it will 
>>> check specs existence at the validation time, not at the s/def call.
>>>
>>> On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:

 Yuri Govorushchenko  writes: 

 > Thank you the pointers! So far I ended up with writing a small `map` 
 macro 
 > which is similar to `s/keys` but checks that keys are already in the 
 > registry: 
 https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 

 Note that you can simply combine a custom predicate and `s/keys` in 
 clojure.spec to verify that all keys in a given map have a underlying 
 spec: 

 ``` 
 (s/def ::whatever (s/and (s/keys ...) 
  #(every? keyword? (keys %)) 
  #(every? (comp boolean s/get-spec) (keys %)) ) 
 ``` 

>>>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [core.spec] Stricter map validations?

2017-10-06 Thread Leon Grapenthin

Open maps/specs are fine.

s/keys supporting unregistered specs are not.

At least to me. I just fixed two more bugs in production that were would 
not have happened.

What are the supposed benefits of this feature? 

I can only infer "being able to require keys without their spec being 
known" which is a usecase I had exactly 0.00% of the time so far.

Anything I have missed?

Kind regards,
 Leon.


On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:
>
> Seems like that's the reasonable place to check it, otherwise you're 
> forced into an ordering for your specs and cannot write recursive strict 
> map specs.
>
> On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko 
> wrote:
>>
>> Thanks. This approach is also different from the macro because it will 
>> check specs existence at the validation time, not at the s/def call.
>>
>> On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>>>
>>> Yuri Govorushchenko  writes: 
>>>
>>> > Thank you the pointers! So far I ended up with writing a small `map` 
>>> macro 
>>> > which is similar to `s/keys` but checks that keys are already in the 
>>> > registry: 
>>> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2 
>>>
>>> Note that you can simply combine a custom predicate and `s/keys` in 
>>> clojure.spec to verify that all keys in a given map have a underlying 
>>> spec: 
>>>
>>> ``` 
>>> (s/def ::whatever (s/and (s/keys ...) 
>>>  #(every? keyword? (keys %)) 
>>>  #(every? (comp boolean s/get-spec) (keys %)) ) 
>>> ``` 
>>>
>>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to try/catch Let bindings?

2017-10-06 Thread 'bertschi' via Clojure



On Monday, October 2, 2017 at 11:04:52 PM UTC+2, Didier wrote:
>
> > Even in an impure language such as Common Lisp we frown on such LET forms
>
> True, but as far as I know, in Common Lisp, the condition handler is 
> always in scope of where the error happened, so I wouldn't face this 
> problem.
>
> I also struggle to split this up into functions without making it even 
> more complicated. I'm intrigued by the interceptor pattern mentioned, I'll 
> have to try it out, I worry its overkill, but not sure.
>
> My opposition to turning this into a chain, is that it complects the order 
> of things, with the work of each step. My steps are pure functions, they 
> take inputs and return outputs. They don't know anything about the full 
> workflow, just their transformation. My orchestrating function is the one 
> which knows how to compose the smaller pure steps, so that it can fulfill 
> the business process.
>
No, your functions are not pure. Besides returning a value they can throw 
an exception, i.e. they have a side-effect!
As we know from Haskell, this forces them to be evaluated in a sequential 
order ... just ask yourself what value the variable c should be bound to if 
an exception is thrown by doB.

Both suggested solutions seem to be reasonable. While try-let ignores all 
bindings when an error occurs (check with macroexpand), the interceptor 
chain probably can see all bindings established before the error occured (I 
have not tested this though) and thus correctly imposes a sequential order.

Best,

 Nils

The interceptor chain seems to still complect this a little. At least it 
> has the steps know about each other since it relies on a common context, 
> and expects previous steps to properly assoc the data needed by later steps.
>
>

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Clojure In Toronto: University Health Network

2017-10-06 Thread Jon Pither

Hi All,

Read about Clojure being used in Toronto to help with medical research,
featuring a Q with Dmitri Sotnikov (Yogthos).

https://juxt.pro/blog/posts/clojure-in-university-health-network.html,

Regards,

Jon.

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to properly spec this simple structure

2017-10-06 Thread Alex Bezhan

Yeah, thanks for noticing, Peter.

-- 
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: any? in clojure 1.9.0 alpha

Re: [core.spec] Stricter map validations?

Re: [core.spec] Stricter map validations?

Re: Help ship Clojure 1.9!

Re: any? in clojure 1.9.0 alpha

RE: [core.spec] Stricter map validations?

[ANN] Clojure 1.9.0-beta2

[ANN] spec.alpha 0.1.134

Re: [core.spec] Stricter map validations?

Re: [core.spec] Stricter map validations?

Re: [core.spec] Stricter map validations?

Re: [core.spec] Stricter map validations?

Re: How to try/catch Let bindings?

Clojure In Toronto: University Health Network

Re: How to properly spec this simple structure

15 matches

Site Navigation

Mail list logo

Footer information