www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Datatypes I miss

reply Fredrik Olsson <peylow treyst.se> writes:
Ranges and sets :).

This is me more or less having a fantasy. Ranges and sets are without 
competition the two data types I use the most. They make writing solid 
code so much easy, helps finding range errors while debugging and 
reduces code size in general.

Both fits quite nicely into existing functionality in D, as well as into 
the paradigm of making usable functionality part of the core language 
(as for complex numbers and strings). Ranges are semi there when slicing 
arrays, and sets can be emulates with associative arrays with somewhat 
awkward syntax.

Anyway, if my x-mas wish comes true then :);

RangeDeclaration:
	range [Identifier] [: RangeBaseType] [RangeBody]
RangeBaseType:
	IntegerType
RangeBody:
	RangeMember
RangeMember:
	AssignExpression .. AssignExpression

For example:
	range minute 0..59;  // Static range
	minute = 61;  // Exception if compiling with range checks

	range slice: uint; // Dynamic range;
	int[12] foo;
	slice = 2..foo.length-2;
	int[] bar = foo[slice];

Range properties would be
.min, .max, .length and naturally .sizeof

Constant ranges are written with the .. operator just as one writes 
slices now. One minor hitch here, as slicing for arrays has the upper 
bound not including and having the upper bound not including for proper 
ranges would be awkward. But then again I have more often tried using 
foo[$] to get the last element of an array and failed, then I have ever 
used foo[2..$] to get the last elements.

Naturally the operator in should be able to work with ranges so that one 
could do for example:
	if (mychar in 'a'..'z') { ... }
	while (somenumber in 1..42) { ... }

And then sets:

SetDeclaration:
	set [Identifier] SetBody
SetBaseType:
	IntegerType
SetBody:
	IntegerType
	EnumType
	RangeType
	{ SetMembers }
SetMembers
	SetMember [, SetMembers]
SetMember:
	AssignExpression
	RangeMember
	SetType		// To expand existing sets

For example:
	set alfa {'A'..'Z', 'a'..'z'};
	set alfanum { alfa, '0'-'9' };

	enum weekday { MON, TUE, WED, THU, FRI, SAT, SUN };
	set weekdays weekday;
	weekdays freedays = [TUE..THU, SAT];
	if (selectedday in freedays) { ... }

I mean how many of us have not written:
	if (tolower(ch) >= 'a' && tolower(ch) <= 'z' &&
	    ch >= '0' && ch <= '9') { ... }
And even longer when writing for non English. This is much nicer:
	if (toupper(ch) in ['A'..'Z', '0'..'9']) { ... }
And a compiler can optimize easy to just test bits.
Dec 07 2005
next sibling parent Tom <Tom_member pathlink.com> writes:
I don't know about set or about the syntax but the range idea is also something
I had wished for so long. It's very common to use integers just in a specified
range, it'd make code much more nicer. Also the string enum would be very nice
(or maybe something more general). I don't think all this could be implemented
from a day to another but who knows in some future :D

In article <dn6re3$ckq$1 digitaldaemon.com>, Fredrik Olsson says...
Ranges and sets :).

This is me more or less having a fantasy. Ranges and sets are without 
competition the two data types I use the most. They make writing solid 
code so much easy, helps finding range errors while debugging and 
reduces code size in general.

Both fits quite nicely into existing functionality in D, as well as into 
the paradigm of making usable functionality part of the core language 
(as for complex numbers and strings). Ranges are semi there when slicing 
arrays, and sets can be emulates with associative arrays with somewhat 
awkward syntax.

Anyway, if my x-mas wish comes true then :);

RangeDeclaration:
	range [Identifier] [: RangeBaseType] [RangeBody]
RangeBaseType:
	IntegerType
RangeBody:
	RangeMember
RangeMember:
	AssignExpression .. AssignExpression

For example:
	range minute 0..59;  // Static range
	minute = 61;  // Exception if compiling with range checks

	range slice: uint; // Dynamic range;
	int[12] foo;
	slice = 2..foo.length-2;
	int[] bar = foo[slice];

Range properties would be
.min, .max, .length and naturally .sizeof

Constant ranges are written with the .. operator just as one writes 
slices now. One minor hitch here, as slicing for arrays has the upper 
bound not including and having the upper bound not including for proper 
ranges would be awkward. But then again I have more often tried using 
foo[$] to get the last element of an array and failed, then I have ever 
used foo[2..$] to get the last elements.

Naturally the operator in should be able to work with ranges so that one 
could do for example:
	if (mychar in 'a'..'z') { ... }
	while (somenumber in 1..42) { ... }

And then sets:

SetDeclaration:
	set [Identifier] SetBody
SetBaseType:
	IntegerType
SetBody:
	IntegerType
	EnumType
	RangeType
	{ SetMembers }
SetMembers
	SetMember [, SetMembers]
SetMember:
	AssignExpression
	RangeMember
	SetType		// To expand existing sets

For example:
	set alfa {'A'..'Z', 'a'..'z'};
	set alfanum { alfa, '0'-'9' };

	enum weekday { MON, TUE, WED, THU, FRI, SAT, SUN };
	set weekdays weekday;
	weekdays freedays = [TUE..THU, SAT];
	if (selectedday in freedays) { ... }

I mean how many of us have not written:
	if (tolower(ch) >= 'a' && tolower(ch) <= 'z' &&
	    ch >= '0' && ch <= '9') { ... }
And even longer when writing for non English. This is much nicer:
	if (toupper(ch) in ['A'..'Z', '0'..'9']) { ... }
And a compiler can optimize easy to just test bits.

Tom
Dec 07 2005
prev sibling next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Fredrik Olsson wrote:
 Ranges and sets :).
 
 This is me more or less having a fantasy. Ranges and sets are without 
 competition the two data types I use the most. They make writing solid 
 code so much easy, helps finding range errors while debugging and 
 reduces code size in general.
 
 Both fits quite nicely into existing functionality in D, as well as into 
 the paradigm of making usable functionality part of the core language 
 (as for complex numbers and strings). Ranges are semi there when slicing 
 arrays, and sets can be emulates with associative arrays with somewhat 
 awkward syntax.
 
 Anyway, if my x-mas wish comes true then :);
 
 RangeDeclaration:
     range [Identifier] [: RangeBaseType] [RangeBody]
 RangeBaseType:
     IntegerType
 RangeBody:
     RangeMember
 RangeMember:
     AssignExpression .. AssignExpression
 
 For example:
     range minute 0..59;  // Static range
     minute = 61;  // Exception if compiling with range checks
 
     range slice: uint; // Dynamic range;
     int[12] foo;
     slice = 2..foo.length-2;
     int[] bar = foo[slice];
 
 Range properties would be
 .min, .max, .length and naturally .sizeof
 
 Constant ranges are written with the .. operator just as one writes 
 slices now. One minor hitch here, as slicing for arrays has the upper 
 bound not including and having the upper bound not including for proper 
 ranges would be awkward. But then again I have more often tried using 
 foo[$] to get the last element of an array and failed, then I have ever 
 used foo[2..$] to get the last elements.
 
 Naturally the operator in should be able to work with ranges so that one 
 could do for example:
     if (mychar in 'a'..'z') { ... }
     while (somenumber in 1..42) { ... }
 

Very nice. Well thought out.
 And then sets:
 
 SetDeclaration:
     set [Identifier] SetBody
 SetBaseType:
     IntegerType
 SetBody:
     IntegerType
     EnumType
     RangeType
     { SetMembers }
 SetMembers
     SetMember [, SetMembers]
 SetMember:
     AssignExpression
     RangeMember
     SetType        // To expand existing sets
 
 For example:
     set alfa {'A'..'Z', 'a'..'z'};
     set alfanum { alfa, '0'-'9' };
 
     enum weekday { MON, TUE, WED, THU, FRI, SAT, SUN };
     set weekdays weekday;
     weekdays freedays = [TUE..THU, SAT];
     if (selectedday in freedays) { ... }
 
 I mean how many of us have not written:
     if (tolower(ch) >= 'a' && tolower(ch) <= 'z' &&
         ch >= '0' && ch <= '9') { ... }
 And even longer when writing for non English. This is much nicer:
     if (toupper(ch) in ['A'..'Z', '0'..'9']) { ... }
 And a compiler can optimize easy to just test bits.

The only potential problem I can see in this is a conflict with static array literal syntax. Most notably your last line there: if (toupper(ch) in ['A'..'Z', '0'..'9']) { ... } You and I both know that you meant a set type for ['A'..'Z', '0'..'9'], but the compiler might think that ['A'..'Z', '0'..'9'] is a static array literal and will get confused on your use of ranges there. And then what would happen if your ['A'..'Z', '0'..'9'] looked like a real array literal with no ranges in it, but you meant it as a set? Silent bug. Something like ['I', 'V', 'X', 'C', 'L', 'M']? Is that a char[6] or a set? Hope that wasn't too obtuse. I do like your idea though!
Dec 07 2005
parent Fredrik Olsson <peylow treyst.se> writes:
James Dunne skrev:
 Fredrik Olsson wrote:
 Ranges and sets :).


 The only potential problem I can see in this is a conflict with static 
 array literal syntax.  Most notably your last line there:
 
 if (toupper(ch) in ['A'..'Z', '0'..'9']) { ... }
 
 You and I both know that you meant a set type for ['A'..'Z', '0'..'9'], 
 but the compiler might think that ['A'..'Z', '0'..'9'] is a static array 
 literal and will get confused on your use of ranges there.  And then 
 what would happen if your ['A'..'Z', '0'..'9'] looked like a real array 
 literal with no ranges in it, but you meant it as a set?  Silent bug. 
 Something like ['I', 'V', 'X', 'C', 'L', 'M']?  Is that a char[6] or a set?
 
 Hope that wasn't too obtuse.  I do like your idea though!

Yes, it is a quite huge problem I guess as well. I remember reading in several places Walter stating that static arrays have been on for "v2.0", simply because of the problem of getting the type bottom up. I think the same problem applies here. And then using [] for both static arrays and static sets is a problem as well, as you say. Both for the programmer and definitely for the compiler. Unfortunately {} is already set aside for static structs, using () is not an option, and then we sort of ran out of parenthesis like character pairs :/. Perhaps <> can work. if (ch in <'a'..'z'>) { ... } Not too bad. But then again I think the syntax is the smallest obstacle :).
Dec 08 2005
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Fredrik Olsson wrote:
 Ranges and sets :).
 For example:
     range minute 0..59;  // Static range
     minute = 61;  // Exception if compiling with range checks
 
     range slice: uint; // Dynamic range;
     int[12] foo;
     slice = 2..foo.length-2;
     int[] bar = foo[slice];
 
 Range properties would be
 .min, .max, .length and naturally .sizeof

I think there are TWO things going on here. (1) syntactic sugar for a built-in pair structure. struct range { int max; int min; }; This could be passed to opSlice. I don't see any need for it to be restricted to integral types; real numbers would make sense, too. Actually, this type would be almost identical to auto myrange = [1, 5]; except that the syntax is auto myrange = 1..5; (2) ability to apply a class invariant to a built-in type. This could be allowing a contracts to be applied to a typedef.
     range minute 0..59;  // Static range
     minute = 61;  // Exception if compiling with range checks

is the same as something like: typedef int invariant { assert(this>=0 && this<=59); } Minute; // this assertion is checked every time there's // an assignment to a Minute variable. Minute minute; minute = 61; But you could also have more complex invariants, such typedef int invariant{ assert(this&1==0); } OddInt; to create an integer which must be odd. Except for the redefinition of 'this', it seems to be a natural extension of class invariants.
Dec 08 2005
next sibling parent BCS <BCS_member pathlink.com> writes:
In article <dn8vjc$17fo$1 digitaldaemon.com>, Don Clugston says...

..
(2) ability to apply a class invariant to a built-in type. This could be 
allowing a contracts to be applied to a typedef.

     range minute 0..59;  // Static range
     minute = 61;  // Exception if compiling with range checks

is the same as something like: typedef int invariant { assert(this>=0 && this<=59); } Minute; // this assertion is checked every time there's // an assignment to a Minute variable. Minute minute; minute = 61; But you could also have more complex invariants, such typedef int invariant{ assert(this&1==0); } OddInt; to create an integer which must be odd. Except for the redefinition of 'this', it seems to be a natural extension of class invariants.

Sweet! This would be great!
Dec 08 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Don Clugston wrote:
 Fredrik Olsson wrote:
 
 Ranges and sets :).
 For example:
     range minute 0..59;  // Static range
     minute = 61;  // Exception if compiling with range checks

     range slice: uint; // Dynamic range;
     int[12] foo;
     slice = 2..foo.length-2;
     int[] bar = foo[slice];

 Range properties would be
 .min, .max, .length and naturally .sizeof

I think there are TWO things going on here. (1) syntactic sugar for a built-in pair structure. struct range { int max; int min; }; This could be passed to opSlice. I don't see any need for it to be restricted to integral types; real numbers would make sense, too. Actually, this type would be almost identical to auto myrange = [1, 5]; except that the syntax is auto myrange = 1..5; (2) ability to apply a class invariant to a built-in type. This could be allowing a contracts to be applied to a typedef. > range minute 0..59; // Static range > minute = 61; // Exception if compiling with range checks is the same as something like: typedef int invariant { assert(this>=0 && this<=59); } Minute; // this assertion is checked every time there's // an assignment to a Minute variable. Minute minute; minute = 61; But you could also have more complex invariants, such typedef int invariant{ assert(this&1==0); } OddInt; to create an integer which must be odd. Except for the redefinition of 'this', it seems to be a natural extension of class invariants.

That invariant in the middle of the typedef declaration seems a bit out of place. What if typedefs had a body, where you could put many invariants, unittests (not sure about the usefulness of this one) and even methods! Like: enum weekday_enum { MON, TUE, WED, THU, FRI, SAT, SUN }; typedef weekday_enum weekday { invariant { assert(this >= MON && this <= SUN); } bool isWeekDay() { return (this >= MON && this <= FRI); } char[] toString() { ... // returns "Monday", "Tuesday", etc. } } ... weekday wday; wday = weekday.MON; writefln( wday.toString() ); -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Dec 09 2005
next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Bruno Medeiros wrote:
 
 That invariant in the middle of the typedef declaration seems a bit out 
 of place. What if typedefs had a body, where you could put many 
 invariants, unittests (not sure about the usefulness of this one) and 
 even methods!
 Like:
 
   enum weekday_enum { MON, TUE, WED, THU, FRI, SAT, SUN };
   typedef weekday_enum weekday
   {
     invariant { assert(this >= MON && this <= SUN); }
     bool isWeekDay() { return (this >= MON && this <= FRI); }
     char[] toString() { ... // returns "Monday", "Tuesday", etc. }
   }
 

And yes, the similarity to structs is something worth to note. Hum.. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Dec 09 2005
parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Bruno Medeiros wrote:
 And yes, the similarity to structs is something worth to note. Hum..

Right, it's like a struct that inherits from a basic type, isn't it? struct weekday : weekday_enum { //... } or the same could be achieved by an anonimous member, or perhaps like with templates: member with the same name. struct weekday { weekday_enum weekday; } which would make a weekday implicitely castable to a weekday_enum? L.
Dec 12 2005
prev sibling parent BCS <BCS_member pathlink.com> writes:
In article <dnc9qi$23js$1 digitaldaemon.com>, Bruno Medeiros says...

That invariant in the middle of the typedef declaration seems a bit out 
of place. What if typedefs had a body, where you could put many 
invariants, unittests (not sure about the usefulness of this one) and 
even methods!
Like:

   enum weekday_enum { MON, TUE, WED, THU, FRI, SAT, SUN };
   typedef weekday_enum weekday
   {
     invariant { assert(this >= MON && this <= SUN); }
     bool isWeekDay() { return (this >= MON && this <= FRI); }
     char[] toString() { ... // returns "Monday", "Tuesday", etc. }
   }

   ...

   weekday wday;
   wday = weekday.MON;
   writefln( wday.toString() );


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."

I like the idea. It has my vote. For trivial types that need math ops it's lots better than structs.
Dec 09 2005
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
Fredrik Olsson wrote:

 Ranges and sets :).
 
 This is me more or less having a fantasy. Ranges and sets are without 
 competition the two data types I use the most. They make writing solid 
 code so much easy, helps finding range errors while debugging and 
 reduces code size in general.
 
 Both fits quite nicely into existing functionality in D, as well as into 
 the paradigm of making usable functionality part of the core language 
 (as for complex numbers and strings). Ranges are semi there when slicing 
 arrays, and sets can be emulates with associative arrays with somewhat 
 awkward syntax.
 
 Anyway, if my x-mas wish comes true then :);
 
 RangeDeclaration:
     range [Identifier] [: RangeBaseType] [RangeBody]
 RangeBaseType:
     IntegerType
 RangeBody:
     RangeMember
 RangeMember:
     AssignExpression .. AssignExpression
 
 For example:
     range minute 0..59;  // Static range
     minute = 61;  // Exception if compiling with range checks
 
     range slice: uint; // Dynamic range;
     int[12] foo;
     slice = 2..foo.length-2;
     int[] bar = foo[slice];
 
 Range properties would be
 .min, .max, .length and naturally .sizeof
 
 Constant ranges are written with the .. operator just as one writes 
 slices now. One minor hitch here, as slicing for arrays has the upper 
 bound not including and having the upper bound not including for proper 
 ranges would be awkward. But then again I have more often tried using 
 foo[$] to get the last element of an array and failed, then I have ever 
 used foo[2..$] to get the last elements.
 
 Naturally the operator in should be able to work with ranges so that one 
 could do for example:
     if (mychar in 'a'..'z') { ... }
     while (somenumber in 1..42) { ... }
 
 And then sets:
 
 SetDeclaration:
     set [Identifier] SetBody
 SetBaseType:
     IntegerType
 SetBody:
     IntegerType
     EnumType
     RangeType
     { SetMembers }
 SetMembers
     SetMember [, SetMembers]
 SetMember:
     AssignExpression
     RangeMember
     SetType        // To expand existing sets
 
 For example:
     set alfa {'A'..'Z', 'a'..'z'};
     set alfanum { alfa, '0'-'9' };
 
     enum weekday { MON, TUE, WED, THU, FRI, SAT, SUN };
     set weekdays weekday;
     weekdays freedays = [TUE..THU, SAT];
     if (selectedday in freedays) { ... }
 
 I mean how many of us have not written:
     if (tolower(ch) >= 'a' && tolower(ch) <= 'z' &&
         ch >= '0' && ch <= '9') { ... }
 And even longer when writing for non English. This is much nicer:
     if (toupper(ch) in ['A'..'Z', '0'..'9']) { ... }
 And a compiler can optimize easy to just test bits.

Do you mean you miss them from Pascal? Your examples match Pascal pretty closely: type Weekday = ( MON, TUE, WED, THU, FRI, SAT, SUN ); WeekdaySet = Set of Weekday; Charset = Set of Char; DayOfWeek : 1..7 ; var weekdays : WeekdaySet; characters : Charset; This is no slight on you, but its amusing to see programmers wish for features available on a language developed in 1970.. hee hee. (A Pascal fan) -DavidM
Dec 09 2005
parent reply Fredrik Olsson <peylow treyst.se> writes:
David Medlock skrev:
 Fredrik Olsson wrote:
 
 Ranges and sets :).


 This is no slight on you, but its amusing to see programmers wish for 
 features available on a language developed in 1970.. hee hee.
 
 (A Pascal fan)
 -DavidM
 

No coincident at all :). I am a Pascal fan as well, and Lisp fan, and Ruby fan and sql fan, and etc. I am simply choose what I feel is the best tool for the task at hand. For the general case Pascal tended to be it, before I found D. So naturally I want D to fill the few gaps I miss from my former #1. //Fredrik
Dec 09 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
Fredrik Olsson wrote:
 David Medlock skrev:
 
 Fredrik Olsson wrote:

 Ranges and sets :).


<snip>
 This is no slight on you, but its amusing to see programmers wish for 
 features available on a language developed in 1970.. hee hee.

 (A Pascal fan)
 -DavidM

No coincident at all :). I am a Pascal fan as well, and Lisp fan, and Ruby fan and sql fan, and etc. I am simply choose what I feel is the best tool for the task at hand. For the general case Pascal tended to be it, before I found D. So naturally I want D to fill the few gaps I miss from my former #1. //Fredrik

You actually /LIKE/ SQL? http://orlyowl.com/omg.jpg
Dec 09 2005
parent reply David Medlock <noone nowhere.com> writes:
James Dunne wrote:
 Fredrik Olsson wrote:
 
 David Medlock skrev:

 Fredrik Olsson wrote:

 Ranges and sets :).


<snip>
 This is no slight on you, but its amusing to see programmers wish for 
 features available on a language developed in 1970.. hee hee.

 (A Pascal fan)
 -DavidM

No coincident at all :). I am a Pascal fan as well, and Lisp fan, and Ruby fan and sql fan, and etc. I am simply choose what I feel is the best tool for the task at hand. For the general case Pascal tended to be it, before I found D. So naturally I want D to fill the few gaps I miss from my former #1. //Fredrik

You actually /LIKE/ SQL? http://orlyowl.com/omg.jpg

SQL is reasonably laid out, and can be readily optimized since it is a declarative language, but its predecessor I like quite a lot more: http://en.wikipedia.org/wiki/IBM_BS12 -DavidM
Dec 09 2005
parent Fredrik Olsson <peylow treyst.se> writes:
David Medlock skrev:
 James Dunne wrote:
 Fredrik Olsson wrote:

 David Medlock skrev:

 Fredrik Olsson wrote:

 Ranges and sets :).






You actually /LIKE/ SQL? http://orlyowl.com/omg.jpg

SQL is reasonably laid out, and can be readily optimized since it is a declarative language, but its predecessor I like quite a lot more: http://en.wikipedia.org/wiki/IBM_BS12

SQL appeals to me because of it's small set of functionally that allows for so much to be done. I can not help it, but sometimes I chuckle for minutes after completing a particularly ingenious query :). Combine with pl/SQL or PostgreSQL's pl/pgSQL and you pretty much have what you need. My company's current project is pretty much an server written in "PostgreSQL" with a dummy web GUI in PHP. // Fredrik
Dec 14 2005
prev sibling parent Glen Perkins <Glen_member pathlink.com> writes:
In article <dn6re3$ckq$1 digitaldaemon.com>, Fredrik Olsson says...
Ranges and sets :).

This is me more or less having a fantasy. Ranges and sets are without 
competition the two data types I use the most...

I find ranges and sets and tuples and other such Lispy datatypes extremely useful, too. Many popular recent languages include them and I'd like to see them in D to the extent possible.
For example:
	range minute 0..59;  // Static range
	minute = 61;  // Exception if compiling with range checks

	range slice: uint; // Dynamic range;
	int[12] foo;
	slice = 2..foo.length-2;
	int[] bar = foo[slice];

Naturally the operator in should be able to work with ranges so that one 
could do for example:
	if (mychar in 'a'..'z') { ... }
	while (somenumber in 1..42) { ... }

And let's not forget: for (int i: 0..9) { ... } I think that's a lot nicer than: for (int i=0; i<9; i++) { ... } and the compiler could easily generate the same code for both.
And then sets:

For example:
	set alfa {'A'..'Z', 'a'..'z'};
	set alfanum { alfa, '0'-'9' };

	enum weekday { MON, TUE, WED, THU, FRI, SAT, SUN };
	set weekdays weekday;
	weekdays freedays = [TUE..THU, SAT];
	if (selectedday in freedays) { ... }

I mean how many of us have not written:
	if (tolower(ch) >= 'a' && tolower(ch) <= 'z' &&
	    ch >= '0' && ch <= '9') { ... }
And even longer when writing for non English. This is much nicer:
	if (toupper(ch) in ['A'..'Z', '0'..'9']) { ... }
And a compiler can optimize easy to just test bits.

and again, something like: for ( Day day : [MON..THU, SAT] ) { ... } Python ran into some trouble with the concept of ranges because it was calculating all of the members first before using any of them. It then added the "xrange" feature, which is related to "generators" or "continuations". Each element in an xrange is calculated on a just-in-time basis rather than all up front. You can then use infinite sets (such as all prime numbers) the same way you use small finite sets. You could then have something roughly like: int generator primes = primeGenerator(); for (int i : primes) { ... } primeGenerator would be a "generator" function that acted like a set of int's but would stay active on the stack between calls generating successive values (not "returning" values and leaving the stack between calls like a regular function, but staying loaded and "yielding" the next value each time it was called). After writing the generator function "primeGenerator()", the programmer could then simply think of "primes" as the set of all prime numbers and use it like any other set.
Dec 10 2005