Re: any? in clojure 1.9.0 alpha

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

Re: [core.spec] Stricter map validations?

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

Re: [core.spec] Stricter map validations?

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

Re: Help ship Clojure 1.9!

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: -

Re: any? in clojure 1.9.0 alpha

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

RE: [core.spec] Stricter map validations?

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

[ANN] Clojure 1.9.0-beta2

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 -

[ANN] spec.alpha 0.1.134

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

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

Re: [core.spec] Stricter map validations?

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

Re: [core.spec] Stricter map validations?

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 #_=> )

Re: [core.spec] Stricter map validations?

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"

Re: How to try/catch Let bindings?

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 >

Clojure In Toronto: University Health Network

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

Re: How to properly spec this simple structure

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