Re: Inconsistent clojure spec forms?
I'd say that's a bug in s/nilable (and I wrote it, so I'll take the blame :). I created a ticket and a patch here: http://dev.clojure.org/jira/browse/CLJ-2100 On Thursday, January 19, 2017 at 11:35:47 AM UTC-6, marian.hor...@vacuumlabs.com wrote: > > Hi, > > this sequence of commands in Clojure 1.9.0-alpha14 suprised me: > > => (clojure.spec/def :test/name string?) > :test/name > > => (clojure.spec/form (clojure.spec/and :test/name)) > (clojure.spec/and :test/name) > > => (clojure.spec/form (clojure.spec/nilable :test/name)) > (clojure.spec/nilable clojure.core/string?) > > Is there any reason, why *clojure.spec/**nilable *resolves the keywords > in its form and *clojure.spec/and* does not? If I understand it > correctly, the keywords are resolved explicitly by the line (let [pf (res > pred)]. > > In the following paragraph I'll try to explain, why this bothers me. We > are developing the API that will be used by external applications. To > validate input data, we decided to use the clojure specs, that serves this > purpose perfectly. However, we would like to reuse our definitions to > generate specifications in other languages like Swagger or JSON Schema. > Using *clojure.spec/form* we were able to detructuralize the spec and > translate it. It is not a surprise that there were some specs that cannot > be translated automatically. The best solution is to associate the > registered keyword of the unsupported spec with the valid translation. The > occurence of *clojure.spec/**nilable* (or, for example, *clojure.spec/def*) > then looses the information about the keywords it was used on and therefore > the translation is incorrect. > > Do you think it is a good idea to translate the specs to the other data > specification languages? Is so, is there a better way to do it? > > Generally, I think that registering a spec to keyword gives some context > to it - at least the name. It is a shame to throw this information away. > > Thanks for your time, > Marián > > -- 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.
Inconsistent clojure spec forms?
Hi, this sequence of commands in Clojure 1.9.0-alpha14 suprised me: => (clojure.spec/def :test/name string?) :test/name => (clojure.spec/form (clojure.spec/and :test/name)) (clojure.spec/and :test/name) => (clojure.spec/form (clojure.spec/nilable :test/name)) (clojure.spec/nilable clojure.core/string?) Is there any reason, why *clojure.spec/**nilable *resolves the keywords in its form and *clojure.spec/and* does not? If I understand it correctly, the keywords are resolved explicitly by the line (let [pf (res pred)]. In the following paragraph I'll try to explain, why this bothers me. We are developing the API that will be used by external applications. To validate input data, we decided to use the clojure specs, that serves this purpose perfectly. However, we would like to reuse our definitions to generate specifications in other languages like Swagger or JSON Schema. Using *clojure.spec/form* we were able to detructuralize the spec and translate it. It is not a surprise that there were some specs that cannot be translated automatically. The best solution is to associate the registered keyword of the unsupported spec with the valid translation. The occurence of *clojure.spec/**nilable* (or, for example, *clojure.spec/def*) then looses the information about the keywords it was used on and therefore the translation is incorrect. Do you think it is a good idea to translate the specs to the other data specification languages? Is so, is there a better way to do it? Generally, I think that registering a spec to keyword gives some context to it - at least the name. It is a shame to throw this information away. Thanks for your time, Marián -- 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: component dependency cleanup problem
Hi Sean… thanks a lot, indeed, this is a good hint :-). Does not affect the stop strangeness, however. I had a quick look into the code, namely update-system-reverse, and it looks to me like the deps update is a no-op here as the update code in the reduce is the same as in the is the update-system (forward). If one is really interested in fixing the deps (who uses stopped components, anyway ;-), a second pass with (alter-var-root #'my-system component/update-system (keys my-system) identity) fixes it. An inline fix is non trivial as it IMHO requires a assoc-dependencies-reverse function. Ciao …Jochen -- 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] BOB 2017 (February 24, Berlin) - early-bird registration ends Jan 23
We have a strong focus on functional programming, and are great friends with :clojureD, which happens on the very next day. Come & enjoy a day of great talks! BOB 2017 Conference "What happens if we simply use what's best?" February 24, 2017 Berlin http://bobkonf.de/2017/ Program: http://bobkonf.de/2017/program.html Registration: http://bobkonf.de/2017/registration.html BOB is the conference for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experiences. The program features 14 talks and 8 tutorials on current topics: http://bobkonf.de/2017/program.html The subject range of talks includes functional programming, advanced front-end development, and sophisticated uses of types. The tutorials feature introductions to Haskell, Swift, PureScript, React, QuickCheck, Agda, CRDTs and Servant. John Hughes will give the keynote talk. Registration is open online: http://bobkonf.de/2017/registration.html NOTE: The early-bird rates expire on January 23, 2017! BOB cooperates with the :clojured conference on the following day. There is a registration discount available for participants of both events. http://www.clojured.de/ -- 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.
