• Zev Griner (10/10) Feb 02 2003 Can someone point me to a discussion that explains why slicing [m..n] wa...
• Daniel Yokomiso (33/43) Feb 02 2003 to be
• Antti Sykari (14/28) Feb 02 2003 True :) A very religious issue.
• Daniel Yokomiso (15/43) Feb 03 2003 was
• xyzzy (13/43) Feb 04 2003 It really is too hard, isn't it.
• Ilya Minkov (3/64) Feb 04 2003 If slicing is made inclusive (Delphi!), you could use [..] to express an...
• Ilya Minkov (3/86) Feb 04 2003 Oh, sorry. Now i was reading more carefully. Sure, D makes it the right

Zev Griner <Zev_member pathlink.com> writes:

Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

Talk about bug-prone!!

Here I am looking at two numbers and I am supposed to remember that 'n' is to be
ignored. It's bad enough that C arrays, defined as [n], are accessed as 0 <= i <
n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements within the
boundaries, inclusively.

Thanx
Zev Griner

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n] was
 defined as m <= i < n as opposed m <= i <= n?

 Talk about bug-prone!!

 Here I am looking at two numbers and I am supposed to remember that 'n' is

to be
 ignored. It's bad enough that C arrays, defined as [n], are accessed as 0

<= i <
 n. I don't see why that concept has to be promulgated to slicing. The ..
 operator should be the clue that slicing gives you the elements within the
 boundaries, inclusively.

 Thanx
 Zev Griner

Hi,

    The discussion about slices and ranges never dies around here ;-)
    There's are a couple of simple answers to this. First is that D has its
origins on C, and in C every loop on arrays goes from 0 <= i < n, as you
said, so in D a code to manually slice an array would use this notation. If
the notation for slices were different people would always remember that
slicing is inclusive in both ends, while common array loop is
inclusive/exclusive. But the most important reason is that using this
notation we can express empty slices without trouble. Writing "someArray[0
.. 0]" is always right, giving a empty array. When you write functions that
slice arrays you usually have to deal with this problem, and if the default
slicing is inclusive/exclusive you don't need to write tests to check for
the empty slice case. The only language I know that use both ends inclusive
notation and is useable is Icon, but their array indices are different (they
happen between array slots, so 1..3 means before first and before third
elements). The inclusive/exclusive notation is common in other languages
(Java and Python use it).
    I agree that some people will be surprised by this, but they'll get used
to this start/after end definition. If I defined this, I would prefer a
start/length notation instead, because most of the time I write "someArray[n
.. n + x]" instead of "someArray[n .. m]".

    Best regards,
    Daniel Yokomiso.

"Being right too soon is socially unacceptable."
- Robert A. Heinlein


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

Antti Sykari <jsykari gamma.hut.fi> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n] was
 defined as m <= i < n as opposed m <= i <= n?


     The discussion about slices and ranges never dies around here ;-)

True :)  A very religious issue.

It seems that the notation x..y will cause bugs either way, if half of
the people assume it means inclusive, and half of the people assume
it's exclusive.

     There's are a couple of simple answers to this. First is that D
 has its origins on C, and in C every loop on arrays goes from 0 <= i
 < n, as you said, so in D a code to manually slice an array would
 use this notation.

One might ask:

why not ditch the C(++) practice and use 0 <= i <= n, because, after
all, that would be symmetric? Low-level efficiency concerns?

 the empty slice case. The only language I know that use both ends inclusive
 notation and is useable is Icon, but their array indices are different (they
 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).

I don't know what you consider a *useable* language :) However, of the
languages of I know, perl, zsh and ruby have x..y in the meaning of "x
through y inclusive"

Non-inclusive ranges are needed, too, so ruby has solved the problem
by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

-Antti

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Antti Sykari" <jsykari gamma.hut.fi> escreveu na mensagem
news:86bs1tj3vm.fsf hoastest1-8c.hoasnet.inet.fi...
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n]



was
 defined as m <= i < n as opposed m <= i <= n?


     The discussion about slices and ranges never dies around here ;-)

 True :)  A very religious issue.

 It seems that the notation x..y will cause bugs either way, if half of
 the people assume it means inclusive, and half of the people assume
 it's exclusive.

     There's are a couple of simple answers to this. First is that D
 has its origins on C, and in C every loop on arrays goes from 0 <= i
 < n, as you said, so in D a code to manually slice an array would
 use this notation.

 One might ask:

 why not ditch the C(++) practice and use 0 <= i <= n, because, after
 all, that would be symmetric? Low-level efficiency concerns?

 the empty slice case. The only language I know that use both ends


inclusive
 notation and is useable is Icon, but their array indices are different


(they
 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).

 I don't know what you consider a *useable* language :) However, of the
 languages of I know, perl, zsh and ruby have x..y in the meaning of "x
 through y inclusive"

    The range notation for slicing isn't perfect, I think that using ":" a
la Python would be better. But the rationale for the idiom is clear, and if
we need one IMHO this is the best. Ruby has three forms of slicing IIRC
"someArray[start, count]", "someArray[start .. end]" and "someArray[start
... afterEnd]", so they don't have this problem, but also don't have an
unique notation.


 Non-inclusive ranges are needed, too, so ruby has solved the problem
 by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

 -Antti


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

xyzzy <xyzzy adventure.com> writes:

On Mon, 03 Feb 2003 08:05:17 +0200, Antti Sykari <jsykari gamma.hut.fi> 
wrote:

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n] 
 was
 defined as m <= i < n as opposed m <= i <= n?


 The discussion about slices and ranges never dies around here ;-)

 True :)  A very religious issue.

 It seems that the notation x..y will cause bugs either way, if half of
 the people assume it means inclusive, and half of the people assume
 it's exclusive.

It really is too hard, isn't it.

If a language has inclusive slices, to get a non-inclusive you do...
   [x..y-1]

If a language has non-inclusive slices, to get an inclusive you do ...
   [x..y+1]

 There's are a couple of simple answers to this. First is that D
 has its origins on C, and in C every loop on arrays goes from 0 <= i
 < n, as you said, so in D a code to manually slice an array would
 use this notation.

 One might ask:

 why not ditch the C(++) practice and use 0 <= i <= n, because, after
 all, that would be symmetric? Low-level efficiency concerns?

Or even 1 <= i <= n, if you want to get away from techo-thinking,

 the empty slice case. The only language I know that use both ends 
 inclusive
 notation and is useable is Icon, but their array indices are different 
 (they
 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).


hmmm... "usable" ?
 I don't know what you consider a *useable* language :) However, of the
 languages of I know, perl, zsh and ruby have x..y in the meaning of "x
 through y inclusive"

 Non-inclusive ranges are needed, too, so ruby has solved the problem
 by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

And of course, no-one would accidently misread or miscode an extra '.', 
would they?


-- 
xyzzy

Ilya Minkov <midiclub 8ung.at> writes:

If slicing is made inclusive (Delphi!), you could use [..] to express an 
empty slice ;)


Daniel Yokomiso wrote:
 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 
Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

Talk about bug-prone!!

Here I am looking at two numbers and I am supposed to remember that 'n' is

 
 to be
 
ignored. It's bad enough that C arrays, defined as [n], are accessed as 0

 
 <= i <
 
n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements within the
boundaries, inclusively.

Thanx
Zev Griner

 
 
 Hi,
 
     The discussion about slices and ranges never dies around here ;-)
     There's are a couple of simple answers to this. First is that D has its
 origins on C, and in C every loop on arrays goes from 0 <= i < n, as you
 said, so in D a code to manually slice an array would use this notation. If
 the notation for slices were different people would always remember that
 slicing is inclusive in both ends, while common array loop is
 inclusive/exclusive. But the most important reason is that using this
 notation we can express empty slices without trouble. Writing "someArray[0
 .. 0]" is always right, giving a empty array. When you write functions that
 slice arrays you usually have to deal with this problem, and if the default
 slicing is inclusive/exclusive you don't need to write tests to check for
 the empty slice case. The only language I know that use both ends inclusive
 notation and is useable is Icon, but their array indices are different (they
 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).
     I agree that some people will be surprised by this, but they'll get used
 to this start/after end definition. If I defined this, I would prefer a
 start/length notation instead, because most of the time I write "someArray[n
 .. n + x]" instead of "someArray[n .. m]".
 
     Best regards,
     Daniel Yokomiso.
 
 "Being right too soon is socially unacceptable."
 - Robert A. Heinlein
 
 
 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
 
 

Ilya Minkov <midiclub 8ung.at> writes:

Oh, sorry. Now i was reading more carefully. Sure, D makes it the right 
way, i beleve...

Ilya Minkov wrote:
 If slicing is made inclusive (Delphi!), you could use [..] to express an 
 empty slice ;)
 
 
 Daniel Yokomiso wrote:
 
 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...

 Can someone point me to a discussion that explains why slicing [m..n] 
 was
 defined as m <= i < n as opposed m <= i <= n?

 Talk about bug-prone!!

 Here I am looking at two numbers and I am supposed to remember that 
 'n' is


 to be

 ignored. It's bad enough that C arrays, defined as [n], are accessed 
 as 0


 <= i <

 n. I don't see why that concept has to be promulgated to slicing. The ..
 operator should be the clue that slicing gives you the elements 
 within the
 boundaries, inclusively.

 Thanx
 Zev Griner


 Hi,

     The discussion about slices and ranges never dies around here ;-)
     There's are a couple of simple answers to this. First is that D 
 has its
 origins on C, and in C every loop on arrays goes from 0 <= i < n, as you
 said, so in D a code to manually slice an array would use this 
 notation. If
 the notation for slices were different people would always remember that
 slicing is inclusive in both ends, while common array loop is
 inclusive/exclusive. But the most important reason is that using this
 notation we can express empty slices without trouble. Writing 
 "someArray[0
 .. 0]" is always right, giving a empty array. When you write functions 
 that
 slice arrays you usually have to deal with this problem, and if the 
 default
 slicing is inclusive/exclusive you don't need to write tests to check for
 the empty slice case. The only language I know that use both ends 
 inclusive
 notation and is useable is Icon, but their array indices are different 
 (they
 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).
     I agree that some people will be surprised by this, but they'll 
 get used
 to this start/after end definition. If I defined this, I would prefer a
 start/length notation instead, because most of the time I write 
 "someArray[n
 .. n + x]" instead of "someArray[n .. m]".

     Best regards,
     Daniel Yokomiso.

 "Being right too soon is socially unacceptable."
 - Robert A. Heinlein


 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003