I'm pretty sure you can't use a bare colon - Clojure will attempt to read it as a keyword and will fail since there's nothing following. :- is just a normal keyword.
I think you can take the minimalist syntax too far, if there were no separator at all then you'd have to be counting elements to see which was the type and which was the param. This works for let and other similar forms, but their elements are generally aligned vertically so it's usually very clear which is which; this is usually not the case for parameters. On 25 September 2017 at 18:34, Didier <didi...@gmail.com> wrote: > Agree, but I'm not a huge fan of :- as the syntax. Its fine, but why not > just colon like in pascal based languages? > Or even just have the spec follow the arguments and the arg list? > > I think for spec, macros of a different name might be best, since I think > its not useful to have fns that don't have all its args specced and its > return argument specced. > So I think it would make more sense to choose to either spec fully or not. > Only the fn-spec should be optional. > If you do so, then you can use generative testing and instrumentation, and > maybe even run spectrum static checks. > > My 2 cents. > > On Sunday, 24 September 2017 10:34:22 UTC-7, Tommi Reiman wrote: >> >> Would also love to see the spec-aware fn, def, defn and defrecord utils >> somewhere. One thing I like most about Clojure(Script) is it's conciseness >> and Schema provided just that with it's schema-aware def(n)s & the plumbing >> defnk. The current fdef seems good for libraries, but feels noisy for >> apps. >> >> Some related links: >> >> - https://github.com/plumatic/schema#beyond-type-hints >> - https://github.com/gfredericks/schpec/blob/master/src/com/ >> gfredericks/schpec/defn%2Bspec.clj >> - https://github.com/plumatic/schema/issues/366 >> - https://github.com/metosin/spec-tools/issues/72 >> >> Hopefully there will be one good solution for this, for tools like >> Cursive to do static analysis on (as it does with the Schema syntax). Not >> sure if anyone is working on the spec-tools issue right now, looking >> forward to the Orchestra implementation. >> >> Meanwhile: https://www.typescriptlang.org/docs/handbook/typescript-in- >> 5-minutes.html >> >> lauantai 23. syyskuuta 2017 21.42.13 UTC+3 Jeaye kirjoitti: >>> >>> Last I checked, on our Clojure back-end, instrumentation was taking up >>> 2% of our total test running time. This is with jdbc's instrumentation >>> disabled though; I think it's significantly slower due to its extensive >>> usage of s/or s/alt and spec regexes. Our specs are almost entirely s/keys >>> and clojure.core predicates. >>> >>> Our fn spec coverage is 47% on the back-end. So the performance impact >>> of instrumentation really hasn't been a concern. >>> >>> On Fri, Sep 22, 2017 at 10:18:52PM -0700, Didier wrote: >>> > > The goal is to add the macro to orchestra, as a tool to help >>> encourage spec'ing all functions. >>> > >>> > That would be great. My macro for now was also not supporting all defn >>> cases yet. And it automatically instruments the fn with orchestra. So if >>> orchestra had a more complete one defacto, I wouldn't need one. >>> > >>> > For performance, I've been thinking that caching validation (with some >>> configurable cache bounds), or having sample based validation, so >>> validating only a percentage of calls, and maybe even having the sampling >>> rate controlled by execution time metrics, or cpu metrics or call rates, >>> etc. would be interesting possibilities. So in prod, you could tweek the >>> validation to only get as much of it as you can afford. >>> > >>> > -- >>> > 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 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+u...@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. > -- 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.
