Bill Baxter wrote:
On Wed, Jul 8, 2009 at 8:26 PM, Walter Bright<newshou...@digitalmars.com> wrote:
Bill Baxter wrote:
I think what Jerome is getting at is that we could be getting more
mileage out of the xpr1..xpr2 syntax. It would be useful syntax for
more than just integral, dense ranges in foreach and slices. The
equivalents I've used or seen in Ruby, Python and Matlab are more
versatile than D's. Perhaps that can't be translated in any useful
way to a static language like D, I dunno. But it leaves one with the
feeling that D's slice literals are underpowered and that the case
range thing is just plugging a hole in a dilapidated boat rather than
building us a nice new sleek yacht.
How are python's so much better?
1. python's ranges are exclusive of the endpoint
2. python doesn't have a switch statement, so case ranges being better in
python makes no sense
Not every one of those has every feature you could imagine. But nice
things about Python's slices include:
* optional step size,
* step size can be negative.
* nice compact notation
* And the a:b syntax maps to a slice object so that you can manipulate
them and pass them around.
Ruby is the only one I mentioned that has both inclusive and exclusive
ranges (using two dots for inclusive, three dots for exclusive).
Matlab's are always inclusive. But they all have an optional step
size. Python's are a little annoying in that, like D, you can't use
them outside of indexing expressions. Can't even use them in loops.
In NumPy, the numerical library for Python, they've invented some
quirky objects like numpy.r_ which you index to create a range
literal. Like
>>> numpy.r_[0:4:0.5]
array([ 0. , 0.5, 1. , 1.5, 2. , 2.5, 3. , 3.5])
You could do the same in D, but I don't think anyone in NumPy thinks
of it as a particularly elegant way to make ranges (compared to matlab
where just plain 0:4:0.5 gets you the same thing). Also you'd most
often like to have that 4.0 in there, so you have to tweak the range
to be [0:4.5:0.5] to get that inclusivity, because python doesn't have
inclusive ranges. Not ideal. So they also have
Anyway, you seem pretty satisfied with what you've got, so don't mind
me. You've got to draw the line somewhere.
Nevertheless, I think these all are great ideas for additions to std.range.
Andrei
