Digital Mars - D - array slicing ranges

↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:

From The D Programming Language, arrays section:  Is this last bit about  b
= a[0 .. a.length]  true, or should it actually be  b = a[0 .. a.length-1]
?   In other words, are ranges inclusive, or not?

Sean


Slicing
Slicing an array means to specify a subarray of it. For example:
	int a[10];	declare array of 10 ints
	int b[];

	b = a[1..3];	a[1..3] is a 3 element array consisting of
			a[1], a[2], and a[3]

The [] is shorthand for a slice of the entire array. For example, the
assignments to b:
	int a[10];
	int b[]

	b = a;
	b = a[];
	b = a[0 .. a.length];

are all semantically equivalent.

Nov 19 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9tai22$1fok$1 digitaldaemon.com...
 From The D Programming Language, arrays section:  Is this last bit about


 = a[0 .. a.length]  true, or should it actually be  b = a[0 .. a.length-1]
 ?   In other words, are ranges inclusive, or not?


    "s[0..4] = ...  // error, only 3 elements in s"

So ranges are inclusive, and you get an exception if
you write s[0..s.length].

Nov 19 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9tbc2a$1vm1$1 digitaldaemon.com...
 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:9tai22$1fok$1 digitaldaemon.com...
 From The D Programming Language, arrays section:  Is this last bit about


 = a[0 .. a.length]  true, or should it actually be  b = a[0 ..




 ?   In other words, are ranges inclusive, or not?


     "s[0..4] = ...  // error, only 3 elements in s"

 So ranges are inclusive, and you get an exception if
 you write s[0..s.length].


s[0..4] has 4 elements: s[0], s[1], s[2], s[3]

Nov 19 2001

↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:

Walter wrote:
 
 s[0..4] has 4 elements: s[0], s[1], s[2], s[3]


So array-slice ranges are half-open, yes? Your first slice example 
in the spec says:

	b = a[1..3];	a[1..3] is a 3 element array consisting of
			a[1], a[2], and a[3]
    

Should this read "a 2 element array consisting of a[1] and a[2]"?

This kind of ranging is going to piss off C programmers; this 
thread being case in point.

-RB

Nov 19 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BF9CD48.E638FD8 estarcion.com...
 Walter wrote:
 s[0..4] has 4 elements: s[0], s[1], s[2], s[3]


 So array-slice ranges are half-open, yes? Your first slice example
 in the spec says:

 b = a[1..3]; a[1..3] is a 3 element array consisting of
 a[1], a[2], and a[3]


Looks like the spec is wrong <g>.

 This kind of ranging is going to piss off C programmers; this
 thread being case in point.


First I have to get the documentation right.

Nov 19 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9tai22$1fok$1 digitaldaemon.com...
 From The D Programming Language, arrays section:  Is this last bit about


 = a[0 .. a.length]  true, or should it actually be  b = a[0 .. a.length-1]


a[0..a.length] is it.

Nov 19 2001

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

8-0

This is a Bad Thing, IMHO.  The .length property should give the *length* of the
array, not the maximum index!  You could add a maximum index property, though:

b = a[0..a.length-1];  // ok
b = a[0..a.length];  // ArrayOutOfBoundsException
b = a[0..a.maxIndex]; // ok

Or, perhaps better yet, you could just allow unbounded slicing, which goes to
the edges:

b = a[0..];
b = a[..a.maxIndex];
b = a[..]; // all 3 of these are identical



Walter wrote:

 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:9tai22$1fok$1 digitaldaemon.com...
 From The D Programming Language, arrays section:  Is this last bit about


 = a[0 .. a.length]  true, or should it actually be  b = a[0 .. a.length-1]


 a[0..a.length] is it.


--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Nov 19 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

But the length is not the maximum index.

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BF94B93.6D0C72FF deming-os.org...
 8-0

 This is a Bad Thing, IMHO.  The .length property should give the *length*


 array, not the maximum index!  You could add a maximum index property,


 b = a[0..a.length-1];  // ok
 b = a[0..a.length];  // ArrayOutOfBoundsException
 b = a[0..a.maxIndex]; // ok

 Or, perhaps better yet, you could just allow unbounded slicing, which goes


 the edges:

 b = a[0..];
 b = a[..a.maxIndex];
 b = a[..]; // all 3 of these are identical



 Walter wrote:

 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:9tai22$1fok$1 digitaldaemon.com...
 From The D Programming Language, arrays section:  Is this last bit






 b
 = a[0 .. a.length]  true, or should it actually be  b = a[0 ..






 a[0..a.length] is it.


 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Nov 19 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9tcv3f$2vca$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9tche0$2n2v$3 digitaldaemon.com...

 But the length is not the maximum index.


 Then [0..length] is not legal.


I don't understand what you're driving at, then.

Nov 20 2001

↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:

The point is that we need to know if array slice indices are both inclusive,
or if the 'end' index is exclusive.

Do you write:

a[0 .. a.length] // exclusive

or

a[0 .. a.length-1] // inclusive

?

The second makes a lot more intuitive sense.  For a 1-element array thus:

int a[1];

would you want people doing this:?

int b[1] = a[0 .. 1]?

or this:

int b[1] = a[0 .. 0]?

Sean


"Walter" <walter digitalmars.com> wrote in message
news:9td77n$4fc$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9tcv3f$2vca$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9tche0$2n2v$3 digitaldaemon.com...

 But the length is not the maximum index.


 Then [0..length] is not legal.


 I don't understand what you're driving at, then.

Nov 20 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

Ok, the first index is inclusive, the second is exclusive. Making them both
inclusive would make it impossible to write a 0 length array. -Walter

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9tdarf$6mq$1 digitaldaemon.com...
 The point is that we need to know if array slice indices are both


 or if the 'end' index is exclusive.

 Do you write:

 a[0 .. a.length] // exclusive

 or

 a[0 .. a.length-1] // inclusive

 ?

 The second makes a lot more intuitive sense.  For a 1-element array thus:

 int a[1];

 would you want people doing this:?

 int b[1] = a[0 .. 1]?

 or this:

 int b[1] = a[0 .. 0]?

 Sean


 "Walter" <walter digitalmars.com> wrote in message
 news:9td77n$4fc$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9tcv3f$2vca$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9tche0$2n2v$3 digitaldaemon.com...

 But the length is not the maximum index.


 Then [0..length] is not legal.


 I don't understand what you're driving at, then.

Nov 20 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BFA97A0.66C04CBE deming-os.org...

 But we're talking about slicing....if you want a 0 length array, then just
 declare one!

 int[0] a;

 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.


Agreed!

And if you need zero-length array, just use the
following form:

    int a[];
    a[x..x-1];    // no elements

Nov 20 2001

↑ ↓ ← → nancyetroland <nancyetroland free.fr> writes:

Pavel Minayev a �crit :

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BFA97A0.66C04CBE deming-os.org...

 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.


 Agreed!


Agree too.
Perhaps this inclusive/exclusive is more practical than it looks, but it is
difficult to sell.

What about inclusive/exclusive be determined by the choice of '[' or ']' ?:

int[index1..index2]    array;    //index1 and index2 are both inclusive
int[index1..index2[    array;    //index1 is inclusive, index2 is exclusive
int]index1..index2]    array;    //index1 is exclusive, index2 is inclusive
int]index1..index2[    array;    //index1 and index2 are both exclusive

just an idea, i don't study the side effects.

int]char[][    array;    //how readeable is it ?

Roland

Dec 01 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"nancyetroland" <nancyetroland free.fr> wrote in message
news:3C096EEF.A664A722 free.fr...
 Pavel Minayev a �crit :
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BFA97A0.66C04CBE deming-os.org...
 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.




 Perhaps this inclusive/exclusive is more practical than it looks, but it


 difficult to sell.


Think about it this way. We declare an array as:

    int array[max];

loop through it as:

    for (i = 0; i < array.length; i++)

wouldn't it make sense to slice it as [0 .. array.length]?

Dec 01 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9uc9lb$24ng$1 digitaldaemon.com...

 Think about it this way. We declare an array as:

     int array[max];

 loop through it as:

     for (i = 0; i < array.length; i++)

 wouldn't it make sense to slice it as [0 .. array.length]?


On other hand, we could loop through it as:

    for (i = 0; i <= array.length - 1; i++)

IMHO this actually is a proper way to scan through an
array (but nobody actually uses it, including me =)).

So woudln't it make sence to slice it as [0 .. array.length-1]?

Your arguments are all based on the fact that D arrays are
zero-based. I believe this is not really related to the way
slicing operator should work, which is common to many languages.
In fact, I've never seen exclusive slice ranges before (don't
tell about C++ iterator-defined ranges - the thing is, iterators
serve for many purposes other than defining a range)...

Dec 02 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9ucpd3$2nc8$1 digitaldaemon.com...
 Your arguments are all based on the fact that D arrays are
 zero-based.


Yes, and the routine way the length of an array is expressed.

 I believe this is not really related to the way
 slicing operator should work, which is common to many languages.


I think it's important to be able to specify a 0 length slice without
resorting to kludges like a negative difference is really 0 length. (Which
also entails extra runtime overhead.)

Dec 02 2001

↑ ↓ ← → "Sean L. Palmer" <spalmer iname.com> writes:

Inclusive:   a[0..a.length-1]   It's intuitive, but difficult to express a
zero length slice.  Plus the user has to specify length-1 and the compiler
has to increment it back again.  Should be optimizable away but still a
minor drawback.  Runtime range checking in debug builds will prevent bugs
where the user thought it was exclusive and accidentally specified
a[0..a.length].

Exclusive:  a[0..a.length]   Easy to express a zero length slice.  No
additional runtime overhead.  Not very intuitive however.  Sure to be a
major source of bugs, which will not be able to be caught by the debug
runtime range checking.

In that case, since there seems to be no winner in the debate between
inclusive and exclusive ranges, I'd like to suggest going with the
start/length approach instead.  It doesn't go well with the [0..x] syntax
however, that would be misleading.  So we'd want a new syntax to denote a
start/length array slice.  I don't have any ideas except maybe a[0  
a.length]

Start/Length:  a[0   a.length]   It's intuitive, easy to express zero length
slice, easy to tell it's not a range (C programmers will say "what the hell
is that ' ' for?" and look it up in the docs)

Sometimes I hate the C comma operator... Prevents using syntax that alot of
other languages use.  I hardly ever need the comma operator, really.  Just
for wierd tricks, but those could be done another way.  ;)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:9uctpj$2rvp$2 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9ucpd3$2nc8$1 digitaldaemon.com...
 Your arguments are all based on the fact that D arrays are
 zero-based.


 Yes, and the routine way the length of an array is expressed.

 I believe this is not really related to the way
 slicing operator should work, which is common to many languages.


 I think it's important to be able to specify a 0 length slice without
 resorting to kludges like a negative difference is really 0 length. (Which
 also entails extra runtime overhead.)

Dec 02 2001

↑ ↓ ← → a <a b.c> writes:

	With all the bad vibes Walter is getting over this I felt I had to pipe
in with a word of support.  I can really provide a better argument than
Walter except to say I don't find it all that confusing.  When I first
saw the syntax in the spec I was afraid it was going to be inclusive and
was pleasantly surprised to fine it wasn't.  You simply give the index
of the first element you wish to include and the index of the first
element you want to exclude.  I guess I also like how it mirror the for
loop expression of traversing and array slice.  I liked it in C++ and I
like it better in D since it is the language that supports it directly.
	I will say I like the idea of the start and length syntax for slicing
too, but the syntax will need some work if it is not to be an eye/mind
sore.

Dan

Walter wrote:
 
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9ucpd3$2nc8$1 digitaldaemon.com...
 Your arguments are all based on the fact that D arrays are
 zero-based.


 Yes, and the routine way the length of an array is expressed.
 
 I believe this is not really related to the way
 slicing operator should work, which is common to many languages.


 I think it's important to be able to specify a 0 length slice without
 resorting to kludges like a negative difference is really 0 length. (Which
 also entails extra runtime overhead.)

Dec 02 2001

↑ ↓ ← → la7y6nvo shamko.com writes:

Some thoughts on array slicing ranges -

There are two points to consider, namely semantics and syntax.  The
semantics chosen (including the first element and excluding the last
element) fits in with how C arrays are specified, how for loops are
usually written, etc.  So I think these semantics make pretty good
sense.  (This is assuming that only one semantic for slicing ranges
is included - there could be more than one.)

Syntax is another issue.  The problem with using []'s is that it
"looks like" both ends are included.  The Mesa programming language
had an interesting notation for Integer subranges, which was, IIRC,
one of the following - all the following ranges are identical -

    INTEGER [ 1 .. 10 ]
    INTEGER [ 1 .. 11 )
    INTEGER ( 0 .. 10 ]
    INTEGER ( 0 .. 11 )

I'm sure you can see what's going on - the ()'s are used for "open"
endpoints, the []'s are used for "closed" endpoints.  The resulting
syntax was, I thought, pretty intuitive (perhaps because of background
in mathematics).

Maybe a syntax something along these lines could be adopted in D.



a <a b.c> writes:

 	With all the bad vibes Walter is getting over this I felt I had to pipe
 in with a word of support.  I can really provide a better argument than
 Walter except to say I don't find it all that confusing.  When I first
 saw the syntax in the spec I was afraid it was going to be inclusive and
 was pleasantly surprised to fine it wasn't.  You simply give the index
 of the first element you wish to include and the index of the first
 element you want to exclude.  I guess I also like how it mirror the for
 loop expression of traversing and array slice.  I liked it in C++ and I
 like it better in D since it is the language that supports it directly.
 	I will say I like the idea of the start and length syntax for slicing
 too, but the syntax will need some work if it is not to be an eye/mind
 sore.
 
 Dan
 
 Walter wrote:
 
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9ucpd3$2nc8$1 digitaldaemon.com...
 Your arguments are all based on the fact that D arrays are
 zero-based.


 Yes, and the routine way the length of an array is expressed.
 
 I believe this is not really related to the way
 slicing operator should work, which is common to many languages.


 I think it's important to be able to specify a 0 length slice without
 resorting to kludges like a negative difference is really 0 length. (Which
 also entails extra runtime overhead.)

Dec 03 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

<la7y6nvo shamko.com> wrote in message
news:s7citbotd5u.fsf michael.shamko.com...
     INTEGER [ 1 .. 10 ]
     INTEGER [ 1 .. 11 )
     INTEGER ( 0 .. 10 ]
     INTEGER ( 0 .. 11 )

 I'm sure you can see what's going on - the ()'s are used for "open"
 endpoints, the []'s are used for "closed" endpoints.  The resulting
 syntax was, I thought, pretty intuitive (perhaps because of background
 in mathematics).

 Maybe a syntax something along these lines could be adopted in D.


While that can be done, I'm a little uncomfortable with:
1. the non-matching ( and ] <g>.
2. ] and ) look pretty similar on the screen.

Dec 03 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9uhjh8$1fhs$2 digitaldaemon.com...
 <la7y6nvo shamko.com> wrote in message
 news:s7citbotd5u.fsf michael.shamko.com...
     INTEGER [ 1 .. 10 ]
     INTEGER [ 1 .. 11 )
     INTEGER ( 0 .. 10 ]
     INTEGER ( 0 .. 11 )

 I'm sure you can see what's going on - the ()'s are used for "open"
 endpoints, the []'s are used for "closed" endpoints.  The resulting
 syntax was, I thought, pretty intuitive (perhaps because of background
 in mathematics).

 Maybe a syntax something along these lines could be adopted in D.


 While that can be done, I'm a little uncomfortable with:
 1. the non-matching ( and ] <g>.
 2. ] and ) look pretty similar on the screen.


Still... I really like the idea. The syntax is quite intuitive
to everybody who knows math a little bit. And you can choose
what you want to include and what you don't. IMHO the best syntax
proposal on the topic so far. I vote for!

Dec 03 2001

↑ ↓ ← → Roland <rv ronetech.com> writes:

Pavel Minayev a �crit :

 "Walter" <walter digitalmars.com> wrote in message
 news:9uhjh8$1fhs$2 digitaldaemon.com...
 <la7y6nvo shamko.com> wrote in message
 news:s7citbotd5u.fsf michael.shamko.com...
     INTEGER [ 1 .. 10 ]
     INTEGER [ 1 .. 11 )
     INTEGER ( 0 .. 10 ]
     INTEGER ( 0 .. 11 )

 I'm sure you can see what's going on - the ()'s are used for "open"
 endpoints, the []'s are used for "closed" endpoints.  The resulting
 syntax was, I thought, pretty intuitive (perhaps because of background
 in mathematics).

 Maybe a syntax something along these lines could be adopted in D.


 While that can be done, I'm a little uncomfortable with:
 1. the non-matching ( and ] <g>.
 2. ] and ) look pretty similar on the screen.


 Still... I really like the idea. The syntax is quite intuitive
 to everybody who knows math a little bit. And you can choose
 what you want to include and what you don't. IMHO the best syntax
 proposal on the topic so far. I vote for!


why not just

int a[0..a.lenght[;        //note there is two '['

i already proposed something similar that does not thow entousiasm, but it
would be just fine
for me.

Roland

Dec 05 2001

↑ ↓ ← → la7y6nvo shamko.com writes:

Responding to Walter's comments -


    >     INTEGER [ 1 .. 10 ]
    >     INTEGER [ 1 .. 11 )
    >     INTEGER ( 0 .. 10 ]
    >     INTEGER ( 0 .. 11 )
    >
    > I'm sure you can see what's going on - the ()'s are used for "open"
    > endpoints, the []'s are used for "closed" endpoints.  The resulting
    > syntax was, I thought, pretty intuitive (perhaps because of background
    > in mathematics).
    >
    > Maybe a syntax something along these lines could be adopted in D.
    
    While that can be done, I'm a little uncomfortable with:
    1. the non-matching ( and ] <g>.

Agreed, the opening side and the closing side are not symmetric.
But then the endpoints aren't symmetric either.  It would be nice
if the syntax reflected this.


    2. ] and ) look pretty similar on the screen.

Without meaning to be flip, perhaps people with that problem
should get a better screen (or better fonts).  If it's hard
to tell parentheses and square brackets apart, how can one
see the difference between an array index and a function call?


Additional remark:  Even if all of the different forms above aren't
adopted in D, the inclusive/exclusive semantics that D seems to favor
could use the [ .. ) form rather than the [ .. ] form.

Dec 06 2001

↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:

la7y6nvo shamko.com wrote:
 
 Responding to Walter's comments -
 
     2. ] and ) look pretty similar on the screen.
 
 Without meaning to be flip, perhaps people with that problem
 should get a better screen (or better fonts). 


Or work shorter hours. 

 If it's hard
 to tell parentheses and square brackets apart, how can one
 see the difference between an array index and a function call?


Easy -- the compiler tells me I can't function-call an array, or
index a function name. Having both ) and ] be legal in a given 
context, and mean similar but not exactly identical things, is a 
recipe for hard-to-find bugs. 

-RB

Dec 06 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C10025B.55DB0D91 estarcion.com...

 Without meaning to be flip, perhaps people with that problem
 should get a better screen (or better fonts).


 Or work shorter hours.


Yeah, right! =)

 Easy -- the compiler tells me I can't function-call an array, or
 index a function name. Having both ) and ] be legal in a given
 context, and mean similar but not exactly identical things, is a
 recipe for hard-to-find bugs.


Well you can't call a function with square braces, right?
As for arrays... the syntax for slicing would be (a..b). The
syntax for function call is (a, b). So:

    int A();
    int[] a;

    A(3..7);    // ".." is not legal here, so an error is displayed
                // immediately, maybe even with a tip ("slicing a function")

    a(3, 7);    // (3, 7) is treated as a comma operator, and thus, as
                // a starting point for a slice. Since there's no ending
one,
                // an error is given ("ending point expected")

So where are those "hard-to-find" bugs?

Dec 07 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9upv5c$23gg$1 digitaldaemon.com...
 "Russell Borogove" <kaleja estarcion.com> wrote in message
 news:3C10025B.55DB0D91 estarcion.com...
 Having both ) and ] be legal in a given
 context, and mean similar but not exactly identical things, is a
 recipe for hard-to-find bugs.




I remember the first time I came across a mathematical expression:

    A[0..foo)

I just assumed it was a typo. I'd guess that having both A[0..foo) and
A[0..foo] supported but meaning different things will result in bugs like
not seeing the ; in:

    while (expression);
        statement;

Dec 07 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9uq413$26dn$2 digitaldaemon.com...

 I remember the first time I came across a mathematical expression:

     A[0..foo)

 I just assumed it was a typo. I'd guess that having both A[0..foo) and
 A[0..foo] supported but meaning different things will result in bugs like
 not seeing the ; in:

     while (expression);
         statement;


Although I don't usually have such problems myself, I understand
the drawbacks of such approach. Okay, so let's have a compromise
version:

    A[0..foo];    // both ends inclusive
    A(0..foo);    // first inclusive, last exclusive

And no other ways. In fact, it's not very frequently when you
want first or both ends to be exclusive, so not much need in them...
On other hand, this syntax is more error-proof and all. Anybody
sees any drawbacks now?

Dec 07 2001

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

One of the neatest things about the Icon (now Unicon) string processing language
is the definition of character positions between characters.  It is just amazing
how this simple alteration makes string processing so much simpler.

I read some of the debate on syntax like (0,4] and [5,10).  Let me suggest
consideration of the Icon approach for arrays and by extension, strings.  Then a
slice is always inclusive and unambiguous.  Icon also has negative positions
which work from the back of the array.

Mark

Sep 08 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:algfjb$2r1k$1 digitaldaemon.com...
 I read some of the debate on syntax like (0,4] and [5,10).  Let me suggest
 consideration of the Icon approach for arrays and by extension, strings.


 slice is always inclusive and unambiguous.  Icon also has negative


 which work from the back of the array.


Can you summarize it for us?

Sep 11 2002

↑ ↓ ← → Mark Evans <Mark_member pathlink.com> writes:

Can you summarize it for us?


Short summaries here:

http://www.nmt.edu/tcc/help/lang/icon/positions.html
http://www.nmt.edu/tcc/help/lang/icon/substring.html
http://www.cs.arizona.edu/icon/docs/ipd266.htm
http://www.toolsofcomputing.com/IconHandbook/IconHandbook.pdf
Sections 6.2 and following.

Icon is simply unsurpassed in string processing and is for that reason famous
among linguists.  There is more to the string processing than just character
position indices.  Icon supports special clauses called "string scanning
environments" which work like file i/o in a vague analogy.  (See third link
above, section 3.)

Icon also has nice built-in structures like sets (*character sets* turn out to
be insanely useful), hash tables, and lists.  Somehow Icon never made it to the
Big Leagues and that is a shame.  It deserves to be up there with Perl.  Icon is
wicked fast when written correctly.

The Unicon project is the next-generation Icon, and has added objects and other
modern features to base Icon.  It is on SourceForge.

(There was only one project in which I recall desiring a new Icon built-in.  I
wanted a two-way hash table which could index off of either data column.  The
workaround was to implement two mutually mirroring one-way hash tables.)

Icon has a very interesting 'success/failure' paradigm which might also be
something to study, esp. in light of D's contract emphasis.  The unique
'goal-directed' paradigm is quite interesting but may have no application to D.

I have for a very long time desired Icon's string scanning capabilities in my
C/C++ programs.  Even with std::string or string classes from various class
libraries (I've used them all), there is just no comparison with Icon.  I would
become a total D convert if it could do strings like Icon.

Mark

http://www.cs.arizona.edu/icon/
http://unicon.sourceforge.net/index.html

Sep 13 2002

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

<la7y6nvo shamko.com> wrote in message
news:s7cg06ot2nc.fsf michael.shamko.com...
     2. ] and ) look pretty similar on the screen.
 Without meaning to be flip, perhaps people with that problem
 should get a better screen (or better fonts).  If it's hard
 to tell parentheses and square brackets apart, how can one
 see the difference between an array index and a function call?


Whenever I see the [ ) notation, it trips the "typo warning" in my brain. I
understand the arguments in favor of it, but at my age rewiring my sense of
what looks right and what looks wrong is risky <g>.

Dec 07 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9uq413$26dn$1 digitaldaemon.com...

 Whenever I see the [ ) notation, it trips the "typo warning" in my brain.


 understand the arguments in favor of it, but at my age rewiring my sense


 what looks right and what looks wrong is risky <g>.


Then, a questionnare to determine the age of all potential D
users is required =)

Dec 07 2001

↑ ↓ ← → "OddesE" <OddesE_XYZ hotmail.com> writes:

<la7y6nvo shamko.com> wrote in message
news:s7citbotd5u.fsf michael.shamko.com...
<SNIP>
 Syntax is another issue.  The problem with using []'s is that it
 "looks like" both ends are included.  The Mesa programming language
 had an interesting notation for Integer subranges, which was, IIRC,
 one of the following - all the following ranges are identical -

     INTEGER [ 1 .. 10 ]
     INTEGER [ 1 .. 11 )
     INTEGER ( 0 .. 10 ]
     INTEGER ( 0 .. 11 )


Assuming:

int[] a;
int[10] b;
And you want to copy all elements from b to a, without using the [] slice.

I definitely think the syntax above is the best and most intuitive.
- It follows mathematical standards
- It visually shows that the left and right 'parameter' to
   the slice work differently when you use incl .. excl
   indexes like this:   a = b[0..a.size);
- It allows the most flexibility without having to resort to
   strange or very unfamiliar syntax or operators such as ' '
- A rookie will not easily write a = b[0..a.size-1); to copy
   the first ten elements, because the different braces will look
   unfamiliar, so he will check the documentation to see what
   it means. However, I think a rookie might very easily write
   a = b[0..a.size] or a = b[0..a.size-1] depending on his
   personal thought processes. Either one could mean an error
   depending on the way you choose to implement slicing for D.
- The mistake rookies might tend to make, using
   a = b[0..a.size]; could very easily be cought.

Whatever way you choose, I think slicing is a very neat feature
for D, and I really love the idea.


--
Stijn
OddesE_XYZ hotmail.com
http://www.OddesE.f2s.com
__________________________________________
Remove _XYZ from my address when replying by mail

Jan 17 2002

↑ ↓ ← → Charles Hixson <charleshixsn earthlink.net> writes:

Pavel Minayev wrote:

 Subject:

 Re: array slicing ranges
 From:

 "Pavel Minayev" <evilone omen.ru>
 Date:

 Sun, 2 Dec 2001 11:39:55 +0300

 Newsgroups:

 D

 "Walter" <walter digitalmars.com> wrote in message
 news:9uc9lb$24ng$1 digitaldaemon.com...

 Think about it this way. We declare an array as:

     int array[max];

 loop through it as:

     for (i = 0; i < array.length; i++)

 wouldn't it make sense to slice it as [0 .. array.length]?

 On other hand, we could loop through it as:

     for (i = 0; i <= array.length - 1; i++)

 IMHO this actually is a proper way to scan through an
 array (but nobody actually uses it, including me =)).

 So woudln't it make sence to slice it as [0 .. array.length-1]?

Perhaps, as was suggested earlier, there should be an 
array.maxIndex value?  Length is reasonable for the number of 
elements, but doesn't really match the maximum index.  And a 
fully closed interval is easier to grasp.  So one would write:
a [0 .. a.maxIndex]
(which would be equal to a.length - 1, as long as we agree to 
use zero based indexing [and if someday it is generalized to 
n-based indexing, only a minIndex value would need to be added]).

Dec 03 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Charles Hixson" <charleshixsn earthlink.net> wrote in message
news:3C0C0732.6030108 earthlink.net...
 Perhaps, as was suggested earlier, there should be an
 array.maxIndex value?  Length is reasonable for the number of
 elements, but doesn't really match the maximum index.  And a
 fully closed interval is easier to grasp.  So one would write:
 a [0 .. a.maxIndex]
 (which would be equal to a.length - 1, as long as we agree to
 use zero based indexing [and if someday it is generalized to
 n-based indexing, only a minIndex value would need to be added]).


What would maxIndex be for a 0 length array?

Dec 03 2001

↑ ↓ ← → "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:

Walter wrote:

 "Charles Hixson" <charleshixsn earthlink.net> wrote in message
 news:3C0C0732.6030108 earthlink.net...
 Perhaps, as was suggested earlier, there should be an
 array.maxIndex value?  Length is reasonable for the number of
 elements, but doesn't really match the maximum index.  And a
 fully closed interval is easier to grasp.  So one would write:
 a [0 .. a.maxIndex]
 (which would be equal to a.length - 1, as long as we agree to
 use zero based indexing [and if someday it is generalized to
 n-based indexing, only a minIndex value would need to be added]).


 What would maxIndex be for a 0 length array?


NAN, of course!

-BobC

Dec 04 2001

↑ ↓ ← → "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:

Pavel Minayev wrote:

 "Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
 news:3C0D86B9.28E3F0C2 yahoo.com...

 What would maxIndex be for a 0 length array?


 NAN, of course!


 Actually, index is an integer...


Well, OK:  How about -0 instead?  ;^)

-BobC

Dec 05 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C0ED470.F388531F yahoo.com...

 Actually, index is an integer...


 Well, OK:  How about -0 instead?  ;^)


Actually, it's an unsigned integer... muhahahaha
Now what? =)

Dec 05 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

I wish there was a NAN for integer types. -Walter

"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C0D86B9.28E3F0C2 yahoo.com...
 Walter wrote:

 "Charles Hixson" <charleshixsn earthlink.net> wrote in message
 news:3C0C0732.6030108 earthlink.net...
 Perhaps, as was suggested earlier, there should be an
 array.maxIndex value?  Length is reasonable for the number of
 elements, but doesn't really match the maximum index.  And a
 fully closed interval is easier to grasp.  So one would write:
 a [0 .. a.maxIndex]
 (which would be equal to a.length - 1, as long as we agree to
 use zero based indexing [and if someday it is generalized to
 n-based indexing, only a minIndex value would need to be added]).


 What would maxIndex be for a 0 length array?


 NAN, of course!

 -BobC

Dec 04 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BFA97A0.66C04CBE deming-os.org...
 But we're talking about slicing....if you want a 0 length array, then just
 declare one!
 int[0] a;


A 0 length array should be a valid slice.


 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.


I see it from a different angle. I see arrays in C as being 0 based,
inclusive, and the number of elements is specified, exclusive. The slice
semantics fit right in with that.

Nov 20 2001

↑ ↓ ← → Russell Borogove <kaleja estarcion.com> writes:

Walter wrote:
 
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BFA97A0.66C04CBE deming-os.org...
 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.


 I see it from a different angle. I see arrays in C as being 0 based,
 inclusive, and the number of elements is specified, exclusive. The slice
 semantics fit right in with that.


Well, sort of. Your slice notation preserves the "one-past-last-index" 
semantic of C array counts, but it loses the "count of elements" 
semantic, which I feel is the more important one. If your slice 
notation used counts instead of off-the-end indices, I'd have more
support for it.

Hmm. How about [count offset]:

    int original[10];                // ten elements
    int slice[] = original[4 3];     // elements [3][4][5][6]

You'd read that as "four [elements, starting] at three".

Thus "normal" array notation [10] would be equivalent to [10 0], 
"ten elements starting at zero". 

There's some horrifying concept teasing the back of my brain 
about using this slice notation in a declaration to get N-based 
instead of zero-based arrays:

   int PascalRules[10 1];       // one-based array

   PascalRules[  1 ] = 77;        // initial element
   PascalRules[ 10 ] = 44;        // final element
   PascalRules[  0 ] = 99;        // array bounds exception

...but that's probably just asking for trouble.

-RB

Nov 20 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BFAF429.826B32D5 estarcion.com...
 Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BFA97A0.66C04CBE deming-os.org...
 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.


 I see it from a different angle. I see arrays in C as being 0 based,
 inclusive, and the number of elements is specified, exclusive. The slice
 semantics fit right in with that.


 Well, sort of. Your slice notation preserves the "one-past-last-index"
 semantic of C array counts, but it loses the "count of elements"
 semantic, which I feel is the more important one. If your slice
 notation used counts instead of off-the-end indices, I'd have more
 support for it.


I've tried some real code with it, and it works out well. All I can ask is
give it a chance!


 Hmm. How about [count offset]:

     int original[10];                // ten elements
     int slice[] = original[4 3];     // elements [3][4][5][6]

 You'd read that as "four [elements, starting] at three".

 Thus "normal" array notation [10] would be equivalent to [10 0],
 "ten elements starting at zero".

 There's some horrifying concept teasing the back of my brain
 about using this slice notation in a declaration to get N-based
 instead of zero-based arrays:

    int PascalRules[10 1];       // one-based array

    PascalRules[  1 ] = 77;        // initial element
    PascalRules[ 10 ] = 44;        // final element
    PascalRules[  0 ] = 99;        // array bounds exception

 ...but that's probably just asking for trouble.


I've been trying to avoid using ' ' <g>.

Nov 20 2001

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

I don't see that as a critical constraint...readability seems far more
important.  However, you mention programs where this syntax makes things
easy...I would really like to see some examples.  It might help me understand
what you're coming from.

BTW, I think that if we're not going to use inclusive ranges on BOTH sides, then
R. Borogoves idea ( a = b[3 4] ) or something like it would be far superior.

First/Last - intuitive
Start/Len - intuitive
First/Last+1 - might be easy to type, but not intuitive :(

Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BFA97A0.66C04CBE deming-os.org...
 But we're talking about slicing....if you want a 0 length array, then just
 declare one!
 int[0] a;


 A 0 length array should be a valid slice.

 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.




--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Nov 21 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

Check out:

    www.digitalmars.com/d/ctod.html


"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BFBCC60.2EB7049C deming-os.org...
 I don't see that as a critical constraint...readability seems far more
 important.  However, you mention programs where this syntax makes things
 easy...I would really like to see some examples.  It might help me


 what you're coming from.

 BTW, I think that if we're not going to use inclusive ranges on BOTH


 R. Borogoves idea ( a = b[3 4] ) or something like it would be far


 First/Last - intuitive
 Start/Len - intuitive
 First/Last+1 - might be easy to type, but not intuitive :(

 Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BFA97A0.66C04CBE deming-os.org...
 But we're talking about slicing....if you want a 0 length array, then






 declare one!
 int[0] a;


 A 0 length array should be a valid slice.

 This whole exclusive/inclusive thing is, IMHO, *very* non-intuitive.




 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Nov 21 2001

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

???????

I don't see anything there about array slicing.  Did I miss it?

Walter wrote:

 Check out:

     www.digitalmars.com/d/ctod.html


--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Nov 22 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BFCBF71.144F6E8F deming-os.org...
 ???????

 I don't see anything there about array slicing.  Did I miss it?


Sorry, I missed the context. Here's a rewrite of "wordcount" in D, showing
how to use slicing. It actually does compile & run, too <g>. It's a lot
shorter and faster than the equivalent C program. Note how slicing is used
to just map over the input buffer rather than copying and appending a 0.
Note the use of an associative array as a simple symbol table.

----------------------------------------------------------------------------
---
import stdio;
import file;

int main (char[][] args)
{
    int w_total;
    int l_total;
    int c_total;
    int[char[]] dictionary;

    printf("   lines   words   bytes file\n");
    for (int i = 1; i < args.length; ++i)
    {
         char[] input;
         int w_cnt, l_cnt, c_cnt;
         int inword;
         int wstart;

         input = File.read(args[i]);

         for (int j = 0; j < input.length; j++)
         {   char c;

             c = input[j];
             if (c == "\n")
                  ++l_cnt;
             if (c >= "0" && c <= "9")
             {
             }
             else if (c >= "a" && c <= "z" ||
                          c >= "A" && c <= "Z")
             {
                  if (!inword)
                  {
                      wstart = j;
                      inword = 1;
                      ++w_cnt;
                  }
             }
             else if (inword)
             {    char[] word = input[wstart .. j];

                  dictionary[word]++;
                  inword = 0;
             }
             ++c_cnt;
         }
         if (inword)
         {   char[] word = input[wstart .. input.length];
             dictionary[word]++;
         }
         printf("%8lu%8lu%8lu %s\n", l_cnt, w_cnt, c_cnt, (char *)args[i]);
         l_total += l_cnt;
         w_total += w_cnt;
         c_total += c_cnt;
    }

    if (args.length > 2)
    {
         printf("--------------------------------------\n%8lu%8lu%8lu
total",
             l_total, w_total, c_total);
    }

    printf("--------------------------------------\n");
    char[][] keys = dictionary.keys;
    for (int i = 0; i < keys.length; i++)
    {    char[] word;

         word = keys[i];
         printf("%3d %.*s\n", dictionary[word], word);
    }
    return 0;
}

Nov 22 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Walter" <walter digitalmars.com> wrote in message
news:9tihd9$1h76$1 digitaldaemon.com...

 Sorry, I missed the context. Here's a rewrite of "wordcount" in D, showing
 how to use slicing. It actually does compile & run, too <g>. It's a lot
 shorter and faster than the equivalent C program. Note how slicing is used
 to just map over the input buffer rather than copying and appending a 0.


In this context, slicing as you defined it is simpler, of course.
Still, there are many other cases where the inclusive range works
better. And I must also say that when I see [..], I tend to think
of it as of inclusive range, and I believe most people do so as well.

Nov 22 2001

↑ ↓ ← → "Rajiv Bhagwat" <dataflow vsnl.com> writes:

The entire STL is based on the first one being inclusive and the second one
being exclusive pointer (iterator), so a lot of people are familiar with
this concept.

- Rajiv Bhagwat


Pavel Minayev <evilone omen.ru> wrote in message
news:9tikn6$1k79$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9tihd9$1h76$1 digitaldaemon.com...

 Sorry, I missed the context. Here's a rewrite of "wordcount" in D,




 how to use slicing. It actually does compile & run, too <g>. It's a lot
 shorter and faster than the equivalent C program. Note how slicing is




 to just map over the input buffer rather than copying and appending a 0.


 In this context, slicing as you defined it is simpler, of course.
 Still, there are many other cases where the inclusive range works
 better. And I must also say that when I see [..], I tend to think
 of it as of inclusive range, and I believe most people do so as well.

Nov 22 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
news:9tisnr$1rtn$1 digitaldaemon.com...

 The entire STL is based on the first one being inclusive and the second


 being exclusive pointer (iterator), so a lot of people are familiar with
 this concept.


Iterators don't use ".." semantic.

Nov 22 2001

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

I don't know about you, but I use the STL.  I don't think that I'll EVER be
"familiar" with it.

It's exactly stuff like that that makes me want to write my own generic
libraries.  Plus the horridly complex template paramter names I get in the
debugger :(

Rajiv Bhagwat wrote:

 The entire STL is based on the first one being inclusive and the second one
 being exclusive pointer (iterator), so a lot of people are familiar with
 this concept.


--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Nov 22 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

The obtuseness of STL is a prime motivator for me to find another way to do
it in D.


"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BFD425B.D5CBAD1C deming-os.org...
 I don't know about you, but I use the STL.  I don't think that I'll EVER


 "familiar" with it.

 It's exactly stuff like that that makes me want to write my own generic
 libraries.  Plus the horridly complex template paramter names I get in the
 debugger :(

 Rajiv Bhagwat wrote:

 The entire STL is based on the first one being inclusive and the second




 being exclusive pointer (iterator), so a lot of people are familiar with
 this concept.


 --
 The Villagers are Online! http://villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Nov 22 2001

↑ ↓ ← → "Scott Egan" <scotte tpg.com.aux> writes:

Excellent, when I first saw the syntax, I was a bit supprised.  I soon
figured that you did it so you could express a 0 length array.

Nice to see the logic works all around the world.


"Walter" <walter digitalmars.com> wrote in message
news:9te4ga$njn$2 digitaldaemon.com...
 Ok, the first index is inclusive, the second is exclusive. Making them


 inclusive would make it impossible to write a 0 length array. -Walter

 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:9tdarf$6mq$1 digitaldaemon.com...
 The point is that we need to know if array slice indices are both


 or if the 'end' index is exclusive.

 Do you write:

 a[0 .. a.length] // exclusive

 or

 a[0 .. a.length-1] // inclusive

 ?

 The second makes a lot more intuitive sense.  For a 1-element array




 int a[1];

 would you want people doing this:?

 int b[1] = a[0 .. 1]?

 or this:

 int b[1] = a[0 .. 0]?

 Sean


 "Walter" <walter digitalmars.com> wrote in message
 news:9td77n$4fc$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:9tcv3f$2vca$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9tche0$2n2v$3 digitaldaemon.com...

 But the length is not the maximum index.


 Then [0..length] is not legal.


 I don't understand what you're driving at, then.

Apr 18 2004

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Ok, why don't we all give up and work together?  Maybe there can just be 3
equivalent array slice syntaxes:

start/length:  a[3 2]   or   a[3 at 2]   or ....
end exclusive: a(2 .. 5)
end inclusive: a[2 .. 4]

We can all argue over who gets the coveted [x..y] syntax...but can we all agree
that all 3 idioms have their place in the language?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Dec 05 2001

↑ ↓ ← → "Pavel Minayev" <evilone omen.ru> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C0F0B47.88B4A2C2 deming-os.org...

 Ok, why don't we all give up and work together?  Maybe there can just be 3
 equivalent array slice syntaxes:

 start/length:  a[3 2]   or   a[3 at 2]   or ....
 end exclusive: a(2 .. 5)
 end inclusive: a[2 .. 4]

 We can all argue over who gets the coveted [x..y] syntax...but can we all


 that all 3 idioms have their place in the language?


I agree.

Hey, don't forget about cases when one end is inclusive
and other isn't:

    a(2..5];    a[2..5);

Personally, I believe that this plus the   syntax covers the
widest possible range and is able to satisfy most programmers.
It'd be great to see these things in D.

Dec 06 2001

↑ ↓ ← → Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Pavel Minayev wrote:

 I agree.

 Hey, don't forget about cases when one end is inclusive
 and other isn't:

     a(2..5];    a[2..5);

 Personally, I believe that this plus the   syntax covers the
 widest possible range and is able to satisfy most programmers.
 It'd be great to see these things in D.


I haven't heard anybody really argue (practically) for the cases where the
starting index is exclusive...but I suppose if we're going to allow all of this
flexibility, there really isn't any reason not to include them, too...

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Dec 06 2001

↑ ↓ ← → Roland <rv ronetech.com> writes:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 Ok, why don't we all give up and work together?  Maybe there can just be 3
 equivalent array slice syntaxes:

 start/length:  a[3 2]   or   a[3 at 2]   or ....




or a[3 : 2) ?
it remind me something..oh yes: bit fields !

Pavel Minayev a �crit :

 I agree.

 Hey, don't forget about cases when one end is inclusive
 and other isn't:

     a(2..5];    a[2..5);


I agree too.

Roland

Dec 06 2001

↑ ↓ ← → Roland <rv ronetech.com> writes:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 Ok, why don't we all give up and work together?  Maybe there can just be 3
 equivalent array slice syntaxes:

 start/length:  a[3 2]   or   a[3 at 2]   or ....




or a[3 : 2] ? it remind me something.....oh yes: bit fields !

Pavel Minayev a �crit :

 I agree.

 Hey, don't forget about cases when one end is inclusive
 and other isn't:

     a(2..5];    a[2..5);


I agree too.

Roland

Dec 06 2001