[racket-dev] take/drop argument order

From: Eli Barzilay (eli at barzilay.org)
Date: Thu Apr 11 11:10:39 EDT 2013

About two weeks ago, Asumu Takikawa wrote:
> Late reply, but better than never.
> 
> On 2013-03-10 16:20:14 -0400, Eli Barzilay wrote:
> > Assuming this, here's a suggestion that I made in the past for
> > resolving this:
> >
> > * Make the existing `take', `drop', `split-at' accept their arguments
> >   in *either* order.
> 
> I'm fine with this.

I think that there was one objection -- so additional opinions will be
good at this point, before a release with the new functions.




> > * Change the required types for lists to be a null-or-pair, or
> >   even require a `list?', or require a `list?' but throw an error
> >   only if scanning gets to a non-null-terminator.  Any of these
> >   would make sure that the arguments are distinguishable.  (You
> >   can currently write something like (take 0 1) -- it's not an
> >   error.)
> 
> I would much prefer a `list?` if backwards compatibility for this
> isn't a concern. Has anyone *ever* used the "feature" that `take`
> can operate on non-lists?

Probably not intentionally -- just code that isn't supposed to check
the list?-ness up-front.  (But I still prefer forbidding it.)


> > * And another thing that can be done to reduce the name clutter is
> >   to have only the plain names, but make them accept either an
> >   index or a predicate.
> 
> I'm less sure about this change, since the `f` suffix isn't
> particularly verbose and the integer case is likely more common, but
> I'm not opposed to it either.

(It's not the verbosity that bothers me -- the short `f' practically
eliminates that.  It's the fact that there are so many functions to
make the interface symmetric.)

Again -- more opinions at this point would be good.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Posted on the dev mailing list.