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! _________________________ Racket Developers list: http://lists.racket-lang.org/dev