The big argument last can make sense. My style may rely too much on 'rest' arguments... for the code I seem to write, sometimes big arguments are relatively fixed so I write fake monad-like macros to sweeten the code a bit. E.g., in a simple interpreter continuously using an environment a-list. Avoiding globals and set! means your procedures always end up with these kinds of accumulators which are syntactically noisy. Putting them last means you can't use 'rest' arguments, itself often very sweet. <div class="gmail_quote">On May 16, 2011 10:10 AM, "Hendrik Boom" <<a href="mailto:hendrik@topoi.pooq.com">hendrik@topoi.pooq.com</a>> wrote: > On Mon, May 16, 2011 at 10:00:20AM -0400, Matthias Felleisen wrote: >> >> Bottom line: you are correct. First, consistency >> matters and Racket is inconsistent in this regard. >> Second, placement of 'major' arguments matter (I >> dislike your use of 'container' here but I figure >> I know where you come from). >> >> re: consistency. Racket, like most languages, is >> a historically grown, organic artifact. As such >> various historical accidents have shaped the language. >> As the designers of artifacts, we should take the time >> to fix such inconsistencies on a regular basis, but we >> haven't -- partly because of legacy code and partly >> because these inconsistencies don't rank as high on >> our list as other problems we need to fix. >> >> re: major argument. In contrast to OOPLs, FPLs have >> wrestled with this issue for decades. Eli points out >> amusing little programming 'tricks' that shaped some >> interfaces -- and it is sad because it reveals that we >> lack(ed) a design philosophy. >> >> In my personal opinion, we should design interfaces >> like this: >> >> f1 : major-arg minor-arg1 ... -> result1 >> f2 : major-arg minor-arg2 ... -> result2 >> ... >> fn : major-arg minor-argn ... -> resultn >> >> where these things are types or contracts for many >> reasons. A side effect would be that readers would >> notice how close FP is to OOP and that programming >> well in either world takes reasonably similar design >> principles. >> >> (Plus, if you decide to switch to our classes, just >> eliminate major-arg and you have method definitions.) > > I've found it useful to make the argument that is most likely to be a > large amount of code the last argument. Often, this argument is a > function, coded as an inline lambda-expression. Ths tends to lead to > the least bracketcounting to figure out what's an argument to what. > > -- hendrik > _________________________________________________ > For list-related administrative tasks: > <a href="http://lists.racket-lang.org/listinfo/users">http://lists.racket-lang.org/listinfo/users</a> </div>