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: http://lists.racket-lang.org/listinfo/users
