Thanks for checking it out! (: That is an unfortunately great point about implicits, I apologize! It's been in my head so long that I didn't realize that I never explained them. My concisest way of explaining implicits would be automatic glue code generation. You already have these functions annotated with their inputs and outputs, why would you have to write the code to stick them together? It solves the problem of which functions should you call in which order to get what you want. The long-term goal would be to write better code than a human could possibly write (I think that the problem of solving for a desired output from a set of inputs is not in P, not sure though) and being generally easy to maintain/change since it hopefully is a productivity multiplier. Perhaps "implicits" is the wrong word though, but I can't think of a better one at the moment (I would happily change it if someone else had a better idea though).
The outfn's are actually macros, which is how the verification can happen without them being called, thus the normal things that work only with functions such as map/apply, etc. won't work. This is a desired property though, because the moment you use map or apply, you're passing an opaque data structure into some function, thus not being clear to the reader. You could still do (map #(some-outfn :foo 42 :this-argument %) coll) to keep the higher order functions and call clarity. On Thursday, October 30, 2014 7:02:39 PM UTC-7, Atamert Ölçgen wrote: > > I think this is pretty cool. Instead of thinking it as functions on > steroids, I'd prefer looking at it as a powerful callable abstraction. > > How does macroexpand-time validation play with apply (the function)? What > happens if I do (map some-outfn coll) ? > > Also implicits confused me a bit. At first I thought they were parameter > defaults. But it seems they're some sort of inheriance mechanism for > callables. > > BTW, thanks for taking the time to write a detailed readme. I know this is > a young project and it's probably in heavy development. It shows > professionalism (yes, professionalism in an open source context is a thing) > on your part. > > > On Thu, Oct 30, 2014 at 3:08 AM, Diogo Almeida <diog...@gmail.com > <javascript:>> wrote: > >> Hi everyone, >> >> A couple of coworkers and I were chatting about what some of our biggest >> problems with (our) Clojure code was, and came up with this: >> https://github.com/diogo149/outfn ! We just finished making it, so we >> haven't really battle-tested it, but we would love to hear feedback and >> general thoughts about the approach, and possibly have it evolve with the >> community. >> >> The readme has a bunch examples, so I won't copy-paste it all here, but >> here is a list of things that we are hoping to acheive: >> - bad/inconsistent variable naming >> - function call clarity >> - function dispatch based on inputs instead of arity and allowing the >> usage of a threading macro no matter the order of arguments with 0 overhead >> - static DRY verification >> - decomposing big let blocks easily >> - dependency passing without coupling (and anything that makes us want to >> use a :dynamic var) >> - automatic creation of glue code >> >> Some of our favorite examples: >> >> >> - keyword arguments for function call clarity >> (do-something :user-map x :password-list y) >> >> >> - decomplecting order from function arguments: >> (defoutfn map-v2.0 >> "Like map, but better" >> [f coll] >> (map f coll)) >> >> ;; threading in a collection >> (->> 5 >> range >> (map-v2.0 :f inc :coll)) ;; (1 2 3 4 5) >> >> ;; threading in a function >> (->> 5 >> (partial +) >> (map-v2.0 :coll (range 5) :f)) ;; (5 6 7 8 9) >> >> >> - macroexpand-time validation >> (defoutfn outfn >> "what's up doc" >> [foo] >> :foo) >> >> (when nil >> ;; this doesn't get run >> (outfn :fo 2)) >> ;; Error! Invalid set of keys #{:fo} for #'outfn.core/outfn >> >> >> - declarative function calls without glue code >> (defoutfn foo-fn {:output :foo} >> "Docstring" >> ([a] 3) >> ([b] 4) >> ([c d] 5)) >> >> (defoutfn bar-fn {:implicits #{#'foo-fn}} >> "what's up doc" >> [foo] foo) >> >> ;; Look ma, no glue code >> (bar-fn :foo 2) ;; 2 >> (bar-fn :a nil) ;; 3 >> (bar-fn :b 42) ;; 4 >> (bar-fn :c 11 :d 22) ;; 5 >> >> ;; I don't need to know what bar-fn needs - decoupling >> (bar-fn :foo 2 :a 3 :b 4 :c 5 :d 6 :q 72) ;; 2 >> >> ;; Laziness is a virtue >> (bar-fn :foo 42 :a (throw Exception.)) ;; 42 >> >> -- >> 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 >> <javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kind Regards, > Atamert Ölçgen > > -+- > --+ > +++ > > www.muhuk.com > -- 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.
