Also can we consider that put some special argument in some special position.
The main problem data, which often be the criteria of function dispatch, similar to OO's method target object, can as first parameter or after the missing process parameter? So we can have a consistent parameter order model: missing-process-param*, main-problem-data-param, additional-param* With this model maybe we get better use of "->" to focus on & thread main problem: E.g. (-> main-problem-data concrete-func-1 (concrete-func-2 additional-param) ((partial abstract-func-1 missing-process-1 missing-process-2)) ((partial abstract-func-2 missing-process) additional-param)) 在 2008年4月17日星期四 UTC+8下午10:07:21，Rich Hickey写道： > > > > On Apr 15, 7:43 am, Rich Hickey <[email protected]> wrote: > > On Apr 14, 10:40 pm, Stuart Sierra <[email protected]> > > wrote: > > > > > > > > > Hello everyone. I thought I'd take advantage of a quiet couple of > > > days to ... stir up some trouble. This is just a thought I had. Take > > > it or leave it, flame it or flog it, whatever you like. > > > > > I have trouble remembering the order of arguments in the Clojure > built- > > > in functions. Things like cons/conj, assoc/find, etc. So I thought > > > about it a bit and came up with some "rules of thumb" that seem > > > natural: > > > > > 1. Variable arg lists have to go last; > > > 2. The "operand," i.e. the object primarily being "operated upon," > > > goes last, to make partial application easier and nested expressions > > > easier to read; > > > 3. If a function/macro takes a collection, the collection goes last. > > > > > Skimming through the API, it seems like most of the built-in functions > > > fit these rules, with a few exceptions: > > > conj contains? find get nth nthrest select-keys subs subvec with-meta > > > set/project > > > > > Maybe it's already too late to suggest breaking changes in the core > > > language, or maybe Clojure, unlike its data structures, is still > > > somewhat mutable. :) Whatever, it's just an idea. > > > > Hmmm... Good thing those weren't the rules or assoc/dissoc couldn't > > have become variadic. I know it might seem arbitrary, but it's > > (usually :) not. > > > > A better characterization (but not a rule, no promises) might be that > > the sequence functions take the seq last, and the collection functions > > take the collection first. > > > > I think with #() the partial application story is always easy - no > > matter what the argument order you often want to bind args other than > > the first. > > > > I seem to have quashed the dialog with my contribution :( > > Maybe this explanation will be more constructive. > > One way to think about sequences is that they are read from the left, > and fed from the right: > > <- [1 2 3 4] > > Most of the sequence functions consume and produce sequences. So one > way to visualize that is as a chain: > > map<- filter<-[1 2 3 4] > > and one way to think about many of the seq functions is that they are > parameterized in some way: > > (map f)<-(filter pred)<-[1 2 3 4] > > So, sequence functions take their source(s) last, and any other > parameters before them, and partial allows for direct parameterization > as above. There is a tradition of this in functional languages and > Lisps. > > Note that this is not the same as taking the primary operand last. > Some sequence functions have more than one source (concat, > interleave). When sequence functions are variadic, it is usually in > their sources. > > I don't think variable arg lists should be a criteria for where the > primary operand goes. Yes, they must come last, but as the evolution > of assoc/dissoc shows, sometimes variable args are added later. > > Ditto partial. Every library eventually ends up with a more order- > independent partial binding method. For Clojure, it's #(). > > What then is the general rule? > > Primary collection operands come first.That way one can write -> and > its ilk, and their position is independent of whether or not they have > variable arity parameters. There is a tradition of this in OO > languages and CL (CL's slot-value, aref, elt - in fact the one that > trips me up most often in CL is gethash, which is inconsistent with > those). > > So, in the end there are 2 rules, but it's not a free-for-all. > Sequence functions take their sources last and collection functions > take their primary operand (collection) first. Not that there aren't > are a few kinks here and there that I need to iron out (e.g. set/ > select). > > I hope that helps make it seem less spurious, > > Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
