[racket] Where Are List/Container Operations Headed?

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