www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - First class lazy Interval

reply bearophile <bearophileHUGS lycos.com> writes:
D2 supports the interval syntax in the foreach:
foreach (i; 1..1000) {...}

Such intervals are useful in a very large number of situations. So, with the
new Range support, it may be useful to allow the interval syntax to be used in
other contexts as well.
So x..y may become a first-class lazy interval from x to y-1, that can be
passed to functions too, etc, and not just used into foreach (the compiler can
recognize it, and often optimize it away in many situations, replacing it with
a normal for() loop).

Optional possibilities:

1) x..y..s
where s is a step/stride, so you can define odd numbers, etc.
1..10..3 ==> 1 4 7
10..1..-2 ==> 10 8 6 4 2
1..5..1 ==> 1 2 3 4
I don't like this syntax much, but I think it's acceptable.

2) Such intervals may enjoy a fast opIn_r() method, for quick membership test:
if (a in 0..10) {...}
if (c in 'c'..'z'+1) {...} 
(Notice the +1 because all intervals are open on the right).
For the compiler that's syntax sugar of (a>0 && a<10).
For the user I think it's easy to remember such syntax.

Originally I have thought about the syntaxes [x..y] and [x..y..s] as eager,
that is arrays of the (integer?) numbers of the interval. But they are just
sugar for the (future?) function of std.algorithm that produces an array from a
lazy iterable, so it may not be useful enough.

Bye,
bearophile
Feb 27 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
bearophile:
 For the compiler that's syntax sugar of (a>0 && a<10).

I meant: (a >= 0 && a < 10)
Feb 27 2009
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-27 04:43:46 -0500, bearophile <bearophileHUGS lycos.com> said:

 D2 supports the interval syntax in the foreach:
 foreach (i; 1..1000) {...}
 
 Such intervals are useful in a very large number of situations. So, 
 with the new Range support, it may be useful to allow the interval 
 syntax to be used in other contexts as well.
 So x..y may become a first-class lazy interval from x to y-1, that can 
 be passed to functions too, etc, and not just used into foreach (the 
 compiler can recognize it, and often optimize it away in many 
 situations, replacing it with a normal for() loop).

I agree that having first-class intervals in the language would make it better, especially when you want to pass intervals as function arguments. In the D/Objective-C bridge, I've defined the NSRange struct (a Cocoa type representing an integer interval) so it can be created by typing NSRange[start..end] in adition to the traditional NSMakeRange(start, length). It's better than nothing, but even better would be the ability to omit NSRange[] entirely.
 1) x..y..s
 where s is a step/stride, so you can define odd numbers, etc.
 1..10..3 ==> 1 4 7
 10..1..-2 ==> 10 8 6 4 2
 1..5..1 ==> 1 2 3 4
 I don't like this syntax much, but I think it's acceptable.

May I propose that strides not be part of the interval syntax. Keep the interval simple (x..y) then define operators to transform them. Perhaps the modulus operator could create a steped interval (x..y % s), although this operator doesn't seem to fit exactly right. Perhaps just step(x..y, s) would be enough. It'd return a special struct for iterating the interval in bigger steps. As for strides, why not just (a..b ~ c..d) for joining two ranges and ~(x..y) for everything outside x..y ?
 2) Such intervals may enjoy a fast opIn_r() method, for quick membership test:
 if (a in 0..10) {...}
 if (c in 'c'..'z'+1) {...}

That'd be great if you could use them in the switch statement too: switch (a) { case 0..10: break; } The only downside is that it may confuse people who are accustomed to the GCC extension with define an inclusive interval this way: switch (a) { case 0...10: break; } Perhaps we could make 3 dots mean an inclusive interval (including the second value in the interval), and 2 dots an exclusive one (excluding the second value). -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 27 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin:
 In the D/Objective-C bridge, I've defined the NSRange struct (a Cocoa 
 type representing an integer interval) so it can be created by typing 
 NSRange[start..end] in adition to the traditional NSMakeRange(start, 
 length). It's better than nothing, but even better would be the ability 
 to omit NSRange[] entirely.

In my dlibs I have xrange/range, but I am also looking for something that the compiler can recognize and optimize away better.
 As for strides, why not just (a..b ~ c..d) for joining two ranges and 
 ~(x..y) for everything outside x..y ?

Weeks ago I have strongly suggested Alex to add support for ~ to join any kind of lazy/eager iterable to any other lazy/eager iterable (if the types of the items they yield are equal or castable). I have defined xchain and the Chainable mixin in dlibs for this very useful purpose.
 The only downside is that it may confuse people who are accustomed to 
 the GCC extension with define an inclusive interval this way:

Too bad for them.
 Perhaps we could make 3 dots mean an inclusive interval (including the 
 second value in the interval), and 2 dots an exclusive one (excluding 
 the second value).

Ruby follows your idea, but for the eye it's easy to miss the extra dot, so I don't like this much (but I think an optional stride syntax may be useful, especially if such stride can be negative too. You can also perform a little optimization if the stride is known at compile time, as it often happens). Bye, bearophile
Feb 27 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

 Michel Fortin:

 Perhaps we could make 3 dots mean an inclusive interval (including the 
 second value in the interval), and 2 dots an exclusive one (excluding 
 the second value).

Ruby follows your idea, but for the eye it's easy to miss the extra dot,

useful, especially if such stride can be negative too. You can also perform a little optimization if the stride is known at compile time, as it often happens).
 
 Bye,
 bearophile

Except in Ruby the meaning is reversed (.. is inclusive and ... is exclusive). About the stride, in ruby this is done as (0..10).step(2), which is very readable imho. With extension methods if these ever get in D, will the same syntax be possible with std.range? I do like the stride in std.range (and step in ruby) because it's straightforward and readable: stride( a, 2 ) could become: stride( 0..10, 2 ) or: (0..10).stride(2)
Feb 27 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2009-02-27 04:43:46 -0500, bearophile <bearophileHUGS lycos.com> said:
 
 D2 supports the interval syntax in the foreach:
 foreach (i; 1..1000) {...}

 Such intervals are useful in a very large number of situations. So, 
 with the new Range support, it may be useful to allow the interval 
 syntax to be used in other contexts as well.
 So x..y may become a first-class lazy interval from x to y-1, that can 
 be passed to functions too, etc, and not just used into foreach (the 
 compiler can recognize it, and often optimize it away in many 
 situations, replacing it with a normal for() loop).

I agree that having first-class intervals in the language would make it better, especially when you want to pass intervals as function arguments.

I'm having trouble understanding what's wrong with the good old data types and functions. Andrei
Feb 27 2009
next sibling parent Don <nospam nospam.com> writes:
Denis Koroskin wrote:
 On Fri, 27 Feb 2009 16:44:31 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Michel Fortin wrote:
 On 2009-02-27 04:43:46 -0500, bearophile <bearophileHUGS lycos.com> 
 said:

 D2 supports the interval syntax in the foreach:
 foreach (i; 1..1000) {...}

 Such intervals are useful in a very large number of situations. So, 
 with the new Range support, it may be useful to allow the interval 
 syntax to be used in other contexts as well.
 So x..y may become a first-class lazy interval from x to y-1, that 
 can be passed to functions too, etc, and not just used into foreach 
 (the compiler can recognize it, and often optimize it away in many 
 situations, replacing it with a normal for() loop).

it better, especially when you want to pass intervals as function arguments.

I'm having trouble understanding what's wrong with the good old data types and functions. Andrei

The syntax. One may want to reuse 0..100 syntax to generate random number: auto x = random(0..100); // gimme a random value in [0, 100) or check if a value belongs to an interval: T opIndex(size_t index) { assert(index in 0.._size); // ... }

Particularly, multi-dimensional slices. We have opSlice as a hacky special case of opIndex. So desirable syntax like auto y = x[2..$, 4, 3..8]; is impossible. You can only do something like: auto y = x[Range(2,$), 4, Range(3,8)]; or perhaps auto y = x[Range[2..$], 4, Range[3..8]];
Feb 27 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Denis Koroskin wrote:
 On Fri, 27 Feb 2009 16:44:31 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 I'm having trouble understanding what's wrong with the good old data
 types and functions.

 Andrei

The syntax. One may want to reuse 0..100 syntax to generate random number: auto x = random(0..100); // gimme a random value in [0, 100) or check if a value belongs to an interval: T opIndex(size_t index) { assert(index in 0.._size); // ... }

I don't think this should be in the language... it just feels like there isn't enough use for it. Especially not when you can implement it as a library. As proof, I've attached an implementation of an integral interval. Here's a sample of usage (the program prints this if you run it):
 inter[0, 10] = inter[0, 10]
 inter[0..10] = inter[0, 9]
 inter(0, 10) = inter[1, 9]

[a,b] is inclusive, (a,b) is exclusive and [a..b] is lower inclusive, upper exclusive (to match slicing syntax).
 inter[0..10] % 2 = inter[0, 8] / 2
 inter[1..10] % 2 = inter[2, 8] / 2
 inter[1..10] / 2 = inter[1, 9] / 2
 6 in inter[0..10] % 2 = true
 7 in inter[0..10] % 2 = false

I % a produces an interval of all values n in I which satisfy: n % a == 0. I / a produces an interval containing every a'th element of I (including the first).
 inter[0, 30] / 2 = inter[0, 30] / 2
 (inter[0, 30] / 2).length = 16
 (inter[0, 30] / 2) / 3 = inter[0, 30] / 6
 ((inter[0, 30] / 2) / 3).length = 6
 ((inter[0, 30] / 2) / 3).toArray = [0 6 12 18 24 30]

It should support indexing, slicing and length-ing. It should also support ranges (can't test it, of course :P). -- Daniel
Feb 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Daniel Keep wrote:
 I don't think this should be in the language... it just feels like there
 isn't enough use for it.  Especially not when you can implement it as a
 library.
 
 As proof, I've attached an implementation of an integral interval.
 Here's a sample of usage (the program prints this if you run it):

This is pretty darn cool! Andrei
Feb 27 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 Daniel Keep wrote:
 I don't think this should be in the language... it just feels like there
 isn't enough use for it.  Especially not when you can implement it as a
 library.

 As proof, I've attached an implementation of an integral interval.
 Here's a sample of usage (the program prints this if you run it):

This is pretty darn cool! Andrei

Thanks. On the off chance anyone wants to actually use it, I hereby release the interval module attached to my previous post into the public domain. Anyway, it's 2:30 am here, so I'm off to bed. :P -- Daniel
Feb 27 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

How do you specify a uint range that includes uint.max?<

The interval I was talking about may generate integers only (it may be possible to generate longs and chars too if you give it long/char extrema, but I am not sure this is a good idea).
This is a perfect example of what Andrei recently posted: proposal of a
language change for a pathetically limited special case. Your stride is not
powerful enough to be worthwhile.<

It's limited on purpose, but such intervals are useful in many situations. And note such interval is less limited than the current syntax of D2, that allows such interval as foreach argument only. This post of mine was just an idea, surely most of it can be improved :-) --------------------- Daniel Keep:
[a,b] is inclusive, (a,b) is exclusive and [a..b] is lower inclusive, upper
exclusive (to match slicing syntax).<

I'll probably not be able to remember that. What I'm looking for is something simple that covers the most common cases, not all of them introducing excessive burden to the memory. In designing such things the 80/20 rule is good. --------------------- Don:
 So desirable syntax like auto y = x[2..$, 4, 3..8]; is impossible.<

I see. In Haskell you can use the syntax [x..] to denote the half interval of integers from x to infinite. So in D2 x..$ may be used to denote an interval infinte on the right... or (contextual-wise) one interval extended to the max possible value (max int, or max length of the iterable/data structure?). I am not sure such double meaning is a good thing. --------------------- Lutger:
About the stride, in ruby this is done as (0..10).step(2), which is very
readable imho.<

It's more readable than 0 .. 10 .. 2 but I think you can get used to 0..10..2 too, because you probably end using such syntax often in programs. --------------------- Sean Reque:
but Ruby also supports instantiating them using perl's syntax, which underneath
the hood is just creating a Regexp object. The advantage of the perl-like
syntax is that editors and IDEs can aid a user with syntax highlighting,
whereas when creating a regular expression with a string no such help can be
given.<

Languages are designed for different purposes and with different ideas in mind. Syntax-wise Python is simpler, less tricky (*) and more uniform than Ruby. This makes Python less complex to learn, but less able to create custom-purpose sub-languages, etc. (* = see functions called as foo 5)
Doing things similarly in D, one could implement intervals in a library form in
a similar manner as Daniel did, and then add support in the language for the
syntax bearophile described.<

Few weeks ago I have suggested to adopt a similar strategy in D too, for example to implement complex numbers, multi-precision numbers, and few other things. The compiler can implement just the syntax and a default "bridge" from such syntax and the logic that is contained into a normal D module of the std lib. So for example you can write: Bigint a = 123_456_789_123_456_789_123_456_789; Bigint b = 987_654_321_987_654_321_987_654_321; c = a * b; Where the compiler has a built-in support such natural syntax for Bigints literals (or complex number literals), but the operations like the multiplication among such Bigints are implemented in D into the std.bigints module and not into the compiler. I don't actually know if such idea can be implemented in a D compiler, no one has answered me about this so far :-) --------------------- A possible small problem: Floating-point linear ranges (as used in matlab and numPy, etc) are often useful, but the 0..10 and 0..10..2 syntax doesn't look much good if you want to re-use it for floats (or even for interval arithmetic) because all those points may be too much confusing, even if you add spaces: 0.0 .. 10.5 .. 0.5 0. .. 10. .. .5 So intervals may be kept for integral values only. As an alternative syntax may be: foreach (i; 1:10) {...} foreach (i; 10 : 1 : -1) {...} foreach (i; 0.0 : 10.5 : 0.5) {...} Bye, bearophile
Feb 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 As an alternative syntax may be:
 
 foreach (i; 1:10) {...}
 foreach (i; 10 : 1 : -1) {...}
 foreach (i; 0.0 : 10.5 : 0.5) {...}

I have an idea - we define a contextual keyword "iota" that helps us specify from, to, and stride. Then we can write: foreach (i; iota(0.0, 10.5, 0.5)) {...} Andrei
Feb 27 2009
parent downs <default_357-line yahoo.de> writes:
Andrei Alexandrescu wrote:
 bearophile wrote:
 As an alternative syntax may be:

 foreach (i; 1:10) {...}
 foreach (i; 10 : 1 : -1) {...}
 foreach (i; 0.0 : 10.5 : 0.5) {...}

I have an idea - we define a contextual keyword "iota" that helps us specify from, to, and stride. Then we can write: foreach (i; iota(0.0, 10.5, 0.5)) {...} Andrei

How about the more intuitive "foreach (i; 0 .. 10.5 stride 0.5)"? It doesn't always have to be a symbol. ^^
Feb 28 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-27 09:47:30 -0500, Daniel Keep <daniel.keep.lists gmail.com> said:

 assert(index in 0.._size);

I don't think this should be in the language... it just feels like there isn't enough use for it. Especially not when you can implement it as a library.

Well, if a..b simply maps to an interval type in the standard library (as I think it should) then you can implement the "in" operator in the standard library, outside of the language, if you want. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 27 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michel Fortin wrote:
 On 2009-02-27 09:47:30 -0500, Daniel Keep <daniel.keep.lists gmail.com>
 said:
 
 assert(index in 0.._size);

I don't think this should be in the language... it just feels like there isn't enough use for it. Especially not when you can implement it as a library.

Well, if a..b simply maps to an interval type in the standard library (as I think it should) then you can implement the "in" operator in the standard library, outside of the language, if you want.

I think a lot of my uneasiness with having intervals in the language is the syntax. Yes, a..b is very nice. It's also a bad syntax for intervals. As Don keeps pointing out, you can't have an interval that includes int.max with that syntax. Also, if you say to someone, "we have intervals, look: [a..b]!" I'd be surprised if a good proportion of people didn't assume that it was inclusive both sides. That's how it'd be interpreted by math people. Using ... to indicate an inclusive range doesn't solve the problem. How do you do (a,b]? Introduce yet another operator? What about (a, b)? The only syntax I've ever liked for ranges is the math syntax. Sadly, it's pretty horrible for a programming language, and I don't think it's even context free. a..b in slicing and foreach is OK because it's for a very specific, well-understood purpose. It's like how range(5) in Python generates the sequence [0, 1, 2, 3, 4] because 90% of the time, that's what you want in the circumstances where it's commonly used. The argument that you can now easily test to see if a number is in a range is also a little underwhelming. It's not THAT hard to write the test out manually. On the whole, I think the use cases for this sort of syntax are just far too few and specialised to warrant syntax for them, especially when the syntax proposed is very restrictive. Especially when you can do it in a library without too much effort. Hell, my first instinct was to alias inter to Z to make it even shorter. Then it's only 3 characters more than native syntax, and more flexible. I understand the desire to see something potentially useful in the language. I just don't want to see D become like Perl (or to an extent, C++) where every feature that's even a little useful gets added, and we end up with a language where everyone has to learn and program in "subsets" of it, because no normal person could possibly remember how the whole thing works. -- Daniel
Feb 27 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-27 23:02:30 -0500, Daniel Keep <daniel.keep.lists gmail.com> said:

 On the whole, I think the use cases for this sort of syntax are just far
 too few and specialised to warrant syntax for them, especially when the
 syntax proposed is very restrictive.
 
 Especially when you can do it in a library without too much effort.
 Hell, my first instinct was to alias inter to Z to make it even shorter.
  Then it's only 3 characters more than native syntax, and more flexible.

But what I'm proposing is that a..b just become a shortcut for inter[a..b], or whatever is the standard interval struct in the standard library. Isn't that exactly what you're trying to do (a shortcut) by shortening inter[a..b] to Z[a..b] ?
 Using ... to indicate an inclusive range doesn't solve the problem.  How
 do you do (a,b]?  Introduce yet another operator?  What about (a, b)?

Perhaps using "..." was a bit too much to ask. But there is no reason why the standard library interval cannot support all kinds of bounds just like inter does. The syntax just won't be as nice as a..b. Basically, all the compiler would do is map a..b to inter[a..b] and leave everything else to the standard library. So it's not removing any option, it just consistently allow you to write a..b whatever the place. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 27 2009
prev sibling next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Bill Baxter wrote:
 4..$
 4u..$
 etc?

Aside from the inconsistent meaning of $, you still can't have an inclusive range [a, b], where 'a' and 'b' are not only known at runtime, without treating 'b == int.max' as a special case. -- Rainer Deyke - rainerd eldwood.com
Feb 27 2009
prev sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
Daniel Keep wrote:
 Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don
 keeps pointing out, you can't have an interval that includes int.max
 with that syntax.

4 .. int.$ —Joel Salomon
Mar 02 2009
parent Don <nospam nospam.com> writes:
Joel C. Salomon wrote:
 Daniel Keep wrote:
 Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don
 keeps pointing out, you can't have an interval that includes int.max
 with that syntax.

4 .. int.$ —Joel Salomon

I love that real.$ is the number that's even bigger than infinity <g>. What if the range is stored in variables? x[a..b]; How can you set b so that it includes x[int.max]? BTW, I'm not merely being negative, I'd love for one of these schemes to work.
Mar 03 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-02-27 08:44:31 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:
 Michel Fortin wrote:
 On 2009-02-27 04:43:46 -0500, bearophile <bearophileHUGS lycos.com> said:
 
 D2 supports the interval syntax in the foreach:
 foreach (i; 1..1000) {...}
 
 Such intervals are useful in a very large number of situations. So, 
 with the new Range support, it may be useful to allow the interval 
 syntax to be used in other contexts as well.
 So x..y may become a first-class lazy interval from x to y-1, that can 
 be passed to functions too, etc, and not just used into foreach (the 
 compiler can recognize it, and often optimize it away in many 
 situations, replacing it with a normal for() loop).

I agree that having first-class intervals in the language would make it better, especially when you want to pass intervals as function arguments.

I'm having trouble understanding what's wrong with the good old data types and functions.

Nothing, really. Specifying intervals as two separate function arguments as in f(a, b) is perfectly acceptable. Having a struct Interval { int a, b } is also a nice way to define and pass an interval arround. And defining intervals as a..b in foreach and when slicing array is a pretty neat syntax. But while all these solutions for passing intervals are nice, having an incoherent mix of all these isn't. I think intervals should be uniformized, and that probably goes by openning the a..b syntax to other uses. That could be done easily by mapping a..b to a struct in the standard library. That said, as others have pointed out, it also opens some new possibilities: It makes it easier to support multidimentional arrays. For instance, marray[1..3, 3, 3..4] could translate to a call to marray.opSliceIndex(interval!(int), int, interval!(int)). Making intervals a type generalizes them as ranges. For instance you could create a "random" template function that chooses a random element in a random-access range: random(range), then use that same function with an integer interval: random(1..10). That's an improvement over having two arguments: random(1, 10), because a two-arguments tuple can't be treated as a range (with front, back, popFront, popBack, etc.). And while having random(interval(1, 10)) is technically the same, it also is a lot more cluttered. If the language can avoid the clutter in foreach and array slices, then why can't we avoid it elsewhere? Why does an interval when inside a language construct looks better than elsewhere? That's the oddities mapping a..b to a standard type usable everywhere would avoid. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 27 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Michel Fortin wrote:
...
 If the language can avoid the clutter in foreach and array slices, then 
 why can't we avoid it elsewhere? Why does an interval when inside a 
 language construct looks better than elsewhere? That's the oddities 
 mapping a..b to a standard type usable everywhere would avoid.

It would be more consistent and nice if a..b would work everywhere without problems, but imho inter(a,b) is not that much clutter. Especially when strides come into play, I think stride(range, x) is much more readable than adding even more operators. What would really make ranges more readable is extension methods to get rid of all the nesting. After two of three levels of nesting it's starts to get quite annoying. Reading from left to right is just more natural than from the inside out.
Feb 28 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Feb 2009 16:44:31 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Michel Fortin wrote:
 On 2009-02-27 04:43:46 -0500, bearophile <bearophileHUGS lycos.com>  
 said:

 D2 supports the interval syntax in the foreach:
 foreach (i; 1..1000) {...}

 Such intervals are useful in a very large number of situations. So,  
 with the new Range support, it may be useful to allow the interval  
 syntax to be used in other contexts as well.
 So x..y may become a first-class lazy interval from x to y-1, that can  
 be passed to functions too, etc, and not just used into foreach (the  
 compiler can recognize it, and often optimize it away in many  
 situations, replacing it with a normal for() loop).

it better, especially when you want to pass intervals as function arguments.

I'm having trouble understanding what's wrong with the good old data types and functions. Andrei

The syntax. One may want to reuse 0..100 syntax to generate random number: auto x = random(0..100); // gimme a random value in [0, 100) or check if a value belongs to an interval: T opIndex(size_t index) { assert(index in 0.._size); // ... }
Feb 27 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sat, 28 Feb 2009 02:33:15 +1100, Daniel Keep wrote:

 Andrei Alexandrescu wrote:
 Daniel Keep wrote:
 I don't think this should be in the language... it just feels like
 there isn't enough use for it.  Especially not when you can implement
 it as a library.

 As proof, I've attached an implementation of an integral interval.
 Here's a sample of usage (the program prints this if you run it):

This is pretty darn cool! Andrei

Thanks. On the off chance anyone wants to actually use it, I hereby release the interval module attached to my previous post into the public domain. Anyway, it's 2:30 am here, so I'm off to bed. :P -- Daniel

Are you even allowed to release code to public domain that late at night? :D
Feb 27 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
--0016364585e8b36ed80463f50e03
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Sat, Feb 28, 2009 at 1:02 PM, Daniel Keep <daniel.keep.lists gmail.com>wrote:

 Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don
 keeps pointing out, you can't have an interval that includes int.max
 with that syntax.

4..$ 4u..$ etc? --bb --0016364585e8b36ed80463f50e03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Feb 28, 2009 at 1:02 PM, Daniel Keep <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:daniel.keep.lists gmail.com">daniel.ke= ep.lists gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot= e" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt = 0.8ex; padding-left: 1ex;"> <br> Yes, a..b is very nice. =A0It&#39;s also a bad syntax for intervals. =A0As = Don<br> keeps pointing out, you can&#39;t have an interval that includes int.max<br=

</blockquote><div><br><br>4..$<br>4u..$<br>etc?<br><br>--bb <br></div></div=
<br>

--0016364585e8b36ed80463f50e03--
Feb 27 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Tue, Mar 3, 2009 at 5:22 PM, Don <nospam nospam.com> wrote:
 Joel C. Salomon wrote:
 Daniel Keep wrote:
 Yes, a..b is very nice. =C2=A0It's also a bad syntax for intervals. =C2=



 keeps pointing out, you can't have an interval that includes int.max
 with that syntax.

4 .. int.$ =E2=80=94Joel Salomon

I love that real.$ is the number that's even bigger than infinity <g>. What if the range is stored in variables? x[a..b]; How can you set b so that it includes x[int.max]?

How about x[a..b] vs x[a..b+] ?
Mar 03 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 03 Mar 2009 19:37:13 +0300, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:

 On Tue, Mar 3, 2009 at 5:22 PM, Don <nospam nospam.com> wrote:
 Joel C. Salomon wrote:
 Daniel Keep wrote:
 Yes, a..b is very nice.  It's also a bad syntax for intervals.  As Don
 keeps pointing out, you can't have an interval that includes int.max
 with that syntax.

4 .. int.$ —Joel Salomon

I love that real.$ is the number that's even bigger than infinity <g>. What if the range is stored in variables? x[a..b]; How can you set b so that it includes x[int.max]?

How about x[a..b] vs x[a..b+] ?

What would the signature of opSlice be in both case? Or different methods invoked?
Mar 03 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
bearophile wrote:
 D2 supports the interval syntax in the foreach:
 foreach (i; 1..1000) {...}
 
 Such intervals are useful in a very large number of situations. So, with the
new Range support, it may be useful to allow the interval syntax to be used in
other contexts as well.
 So x..y may become a first-class lazy interval from x to y-1, that can be
passed to functions too, etc, and not just used into foreach (the compiler can
recognize it, and often optimize it away in many situations, replacing it with
a normal for() loop).

How do you specify a uint range that includes uint.max? (This is a general problem with "[)" ranges).
 Optional possibilities:
 
 1) x..y..s
 where s is a step/stride, so you can define odd numbers, etc.
 1..10..3 ==> 1 4 7
 10..1..-2 ==> 10 8 6 4 2
 1..5..1 ==> 1 2 3 4
 I don't like this syntax much, but I think it's acceptable.

This is a perfect example of what Andrei recently posted: proposal of a language change for a pathetically limited special case. Your stride is not powerful enough to be worthwhile.
Feb 27 2009
prev sibling parent Sean Reque <seanthenewt yahoo.com> writes:
I think Ruby is a good example of a good way to implement intervals. Ruby
exposes them as a class object, so that you can instantiate them as
Range.new(min,max), and a Range object iterable and can easily be converted to
an array. It also supports inclusion testing. The only thing it doesn't do is
allow one to specify a step in the object itself, at least as of 1.8. (One CAN
step over a range with the step function, but this doesn't help for things like
inclusion testing). In addition to exposing a class interface that is
consistent with the rest of the language, the ruby language itself allows one
to define ranges using the .. notation as extra syntactic sugar.

I really like Ruby's combination of defining constructs in the language
consistently so that they looko the same as user-defined objects, and then
adding syntactic sugar on top to make the language more pleasant.  Regular
expressions are another example of how Ruby does this. Ruby allows one to
instantiate regular expressions the same way in as in python, as they are
implemented as a Regexp class, but Ruby also supports instantiating them using
perl's syntax, which underneath the hood is just creating a Regexp object. The
advantage of the perl-like syntax is that editors and IDEs can aid a user with
syntax highlighting, whereas when creating a regular expression with a string
no such help can be given.  

Doing things similarly in D, one could implement intervals in a library form in
a similar manner as Daniel did, and then add support in the language for the
syntax bearophile described. Of course, this would require that D would impose
that at least certain things got implemented in a standard library, whereas D
currently doesn't do if I understand correctly.. 
Feb 27 2009