5 hours ago, Vincent St-Amour wrote:
> At Mon, 27 Feb 2012 16:39:33 -0500, Eli Barzilay wrote:
> > Is there really a need for an N+1 way to do this?
>
> This is a common idiom, and there was no way to make it as
> convenient as it should be. Yes, it's easily implementable in terms
> of `build-list' or `in-range' but having to roll your own every time
> doesn't feel right to me. srfi/1's `iota' comes close, but its name
> and argument order being different than `in-lists''s make it less
> nice IMO.
I don't have a strong opinion either way, but for such changes at
least a warning should be sent, especially given that it's a common
name which means that it can break code. (I've learned this from
`identity' and `thunk', which lead to several such problems.)
> > If it stays, then I'd prefer a version that is more directly
> > implemented in terms of `in-range' (let it determine defaults),
>
> I can fix that. I didn't write it that way to avoid duplication of
> the error handling logic. If you have a solution to that, I'm
> interested.
If it's presented as a convenient & trivial shorthand for `in-range'
then I don't think that there's a big problem with just passing the
arguments as is straight on. I like the idea of a thin wrapper which
by default will inherit any possible future changes and extensions to
`in-range', which is why I think that it's fine to implement and
document it as such.
> > and a description that similarly builds directly on `in-range' (as
> > the comment in the code says).
>
> I can add a note at the end. I still want the entry to be
> understandable independently of `in-range'.
See above for why I'd like having such a note. (And I think that in
all other cases the common style is to first say "like foo except
blah" and then go on into more explanations.)
--
((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
