D - Slicing notation
- Robert Medeiros (11/11) Jan 18 2003 Hi,
- Sean L. Palmer (7/18) Jan 19 2003 This has been suggested many times already. It's very difficult to pars...
- Robert Medeiros (10/12) Jan 19 2003 Thanks. Ironically, I spent a fair number of hours browsing the newsgrou...
- Paul Conway (20/20) Jan 19 2003 I once browsed through what I thought was a dumb book on robust programm...
- Robert Medeiros (12/16) Jan 20 2003 example
- Russell Lewis (4/30) Jan 21 2003 I think that
- Burton Radons (2/13) Jan 21 2003 DLI only.
Hi, I'm brand new to D (having heard about it via the recent Slashdot article) and am very impressed with the language. I look forward to seeing how it develops, using it, and possibly contributing. A minor suggestion: the array slicing notation might be more intuitive if it were asymmetric, i.e. the range [x .. y] is "[x,y)" in set notation so it seems that it might be a good idea to make the notation itself reflect this fact, e.g. [x..y), [x:.y], [x;..y] etc. IMO this enhances program readability and can help combat off-by-one errors. Just a thought. Rob
Jan 18 2003
This has been suggested many times already. It's very difficult to parse properly, was the decision, I think. Sean "Robert Medeiros" <robert.medeiros utoronto.ca> wrote in message news:b0dcgh$2ber$1 digitaldaemon.com...Hi, I'm brand new to D (having heard about it via the recent Slashdot article) and am very impressed with the language. I look forward to seeing how it develops, using it, and possibly contributing. A minor suggestion: the array slicing notation might be more intuitive ifitwere asymmetric, i.e. the range [x .. y] is "[x,y)" in set notation so it seems that it might be a good idea to make the notation itself reflectthisfact, e.g. [x..y), [x:.y], [x;..y] etc. IMO this enhances program readability and can help combat off-by-one errors. Just a thought. Rob
Jan 19 2003
"Robert Medeiros" <robert.medeiros utoronto.ca> This has been suggested many times already. It's very difficult to parse properly, was the decision, I think.Thanks. Ironically, I spent a fair number of hours browsing the newsgroup archives in an attempt to find a feature I could suggest that hadn't already been requested... Newsgroup: 1, Rob: 0. :) Maybe this is a novel: A rewrite of dmdalpha as a front-end for the SUIF project, located at http://suif.stanford.edu/suif/suif2/index.html. The principal benefit is the ease with which optimizations written by others can be applied to D programs. Rob
Jan 19 2003
I once browsed through what I thought was a dumb book on robust programming, written by someone at Microsoft. A lot of what it suggested was stuff that is pretty obvious to a regular C or C++ programmer. However there was this: When you specify a range as [i..j), your j value may have to be one higher than the highest legitimate value that a variable of its type can take. For example for the range [0..255] you would have to specify [0..256] where 256 might be illegal if the index is a 1-byte char. The compile might not promote the char value 255+1 to an unsigned short, so it might wrap it round to 0, and then you are in trouble. Or you might have an enum with valid values a,b,c,d as 0..3 and you would need to specify [a..d+1) to get the whole range. Yet d+1 would be illegal. Similarly if you want [0xFFFFFE00..0xFFFFFFFF] then you would need to specify [0xFFFFFE00..0x100000000) and your compiler might get upset or generate 0. I don't know if these problems can occur in D, under any circumstances. But the idea of explicitly specifying a value that might be 1 greater than the maximum permitted surely is a bit worrisome? "A mechanism of world inter-communication will be devised, embracing the whole planet, freed from national hindrances and restrictions, and functioning with marvellous swiftness...." -- Shoghi Effendi -- The Unfoldment of World Civilisation -- 11 Mar 1936
Jan 19 2003
Hi Paul,When you specify a range as [i..j), your j value may have to be one higherthanthe highest legitimate value that a variable of its type can take. Forexamplefor the range [0..255] you would have to specify [0..256] where 256 mightbeillegal if the index is a 1-byte char.http://www.python.org/doc/current/ref/slicings.html I think python slicing is instructive; the notation [x:] with the second index absent means to slice until the end of the "array", be it list or string, etc. Given the properties of D arrays (the size of the array is stored) I think something similar might work with them as well, but some more thought on the matter is definitely warranted -- or not, as the case may be. :) Rob
Jan 20 2003
Robert Medeiros wrote:Hi Paul,I think that array[x..] already works!When you specify a range as [i..j), your j value may have to be one higherthanthe highest legitimate value that a variable of its type can take. Forexamplefor the range [0..255] you would have to specify [0..256] where 256 mightbeillegal if the index is a 1-byte char.http://www.python.org/doc/current/ref/slicings.html I think python slicing is instructive; the notation [x:] with the second index absent means to slice until the end of the "array", be it list or string, etc. Given the properties of D arrays (the size of the array is stored) I think something similar might work with them as well, but some more thought on the matter is definitely warranted -- or not, as the case may be. :)
Jan 21 2003
Russell Lewis wrote:Robert Medeiros wrote:DLI only.I think python slicing is instructive; the notation [x:] with the second index absent means to slice until the end of the "array", be it list or string, etc. Given the properties of D arrays (the size of the array is stored) I think something similar might work with them as well, but some more thought on the matter is definitely warranted -- or not, as the case may be. :)I think that array[x..] already works!
Jan 21 2003