[racket] Where Are List/Container Operations Headed?

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.) 

-- Matthias






On May 15, 2011, at 3:47 PM, Deren Dohoda wrote:

> Please forgive my ignorance on this matter.
> 
> (cons value list)
> --- Well, makes intuitive sense to put the container second here.
> (map proc list)
> --- Reads like English.
> (foldl proc init list)
> --- Hmm, I guess the association with "map" makes this understandable.
> (take list 2)
> (drop list 2)
> --- OK, what? Why not (take 2 list)?
> 
> I am not a programmer by trade, but this kind of plurality of
> interface is slightly disturbing. When I am working on programs, I
> inevitably look to put containers first. I'm not sure it is always
> very pleasing, but it makes *-like procedures a bit friendly. E.g.,
> (define (push stack literal)
>  (cons literal stack))
> (define (push* stack . literals)
>  (foldl (lambda (lit st) (push st lit)) stack literals)) ;stupid lambda
> Additionally, it can help with syntactic sugar if argument placement
> has some consistency to it.
> 
> And there is the germ of it. A small issue, really, but composing
> container procedures becomes extremely ad hoc because the container
> constructors and disassemblers themselves seem a bit ad hoc. The
> example itself is a little trivial, I know, but what it means is that
> if I later decide to change my stack representation with some other
> container---hand-rolled or otherwise---the plumbing is not
> particularly extensible unless, from the outset, I roll my own
> container procedures and use them instead. (For larger programs, I
> have.)
> 
> In short, abstracting containers is not friendly, because built-ins
> seem to be a mix of ideas.
> 
> This is not a complaint, though, just a question. (If I complained
> about every oddity I'd never have programmed in any language!) Where
> might Racket be going in the future with this? Nowhere? Ideas still
> percolating? Has anyone roughly solved the issue? I know clojure
> attempted to (perhaps successfully) wrestle with this issue, but I
> never looked very far into it. Different containers are often
> different for a reason, and maybe this is not a problem that has a
> "solution."
> 
> Thanks for any insight, everyone,
> Deren
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users