[racket-dev] take/drop argument order

From: Eli Barzilay (eli at barzilay.org)
Date: Thu Apr 11 12:05:59 EDT 2013

Revised suggestion which I think can address both reducing the number
of functions and the argument order:

  Remove the `*f' functions from the interface, and change the
  non-`*f' functions to accept keywords as follows:

      (take #:num N L)
      (take #:while P L)
      (take #:until P L)
      etc

  while keeping the current arguments as a compatibility feature.

  Another possibility is adding a `#:from-end' keyword for the
  `*-right' variants (and keep the existing ones for compatibility).



50 minutes ago, Eli Barzilay wrote:
> 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.