racket-collections
racket-collections copied to clipboard
lexi-lambda
`take` and `drop` have their arguments in reverse order from traditional
Perhaps intended, but I found it surprising, given that the rest of the API seems to adhere to racket/base conventions for homonymic functions
Yeah, this was semi-intentional at the time, but it was probably the wrong call. I don’t think it can be fixed now because the Racket package system provides no mechanism to safely break backwards compatibility.
In general, I prefer the Haskell-style argument order of usually taking the data structure last, but that is far more meaningful in a language where functions are curried. I think the argument order for take reads nicer with the index first, since you can read it as “take n elements from this list”, but that’s not a good enough reason to break convention. As a curiosity, the lazy language has the same argument order as this package, but it also predates take and drop from racket/list.
Anyway, I think we’re stuck with this now, unless you can think of a way to change it.
Yes: accept the arguments in either order. Unlike take in racket/base, yours insists on one exact-nonnegative-integer? and one sequence?, so there is no possible ambiguity
You’re technically right, but I find that to be a very odd API. I strongly prefer there be one correct way to do things, unless there is a meaningful difference between the different ways. Being able to specify the arguments in either order goes strongly against that philosophy.
It’s also worth pointing out that the differences in take and drop are not the only differences between their racket/base and racket/list equivalents, so fixing this one thing would not make data/collection a drop-in replacement. For example, foldl has slightly different ordering behavior as well, which would be far harder to fix. I think that, when I was writing the library, I did not want to be constrained by Racket’s design choices, since initial prototypes were wildly different from the Racket list API. The eventual result ended up being pretty close in most ways, so in retrospect, it would have been better to remain consistent.
If it were possible to change data/collection to be uniformly consistent with the standard library without backwards compatibility, I’d seriously consider it. Given that some of the differences seem impossible to correct now, though, I’m a little reluctant to make the API more ambiguous just to get some of the way there.
Another approach, also backward-compatible: publish the consistent API under a different collection name.
That‘s not a bad idea, nor is it out of the question. Something like data/collection/compat or data/collection/interop? I think I would accept a PR for such a feature.