"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4r4bf$2072$1@digitaldaemon.com...
> "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a4qetl$1nbv$1@digitaldaemon.com...
>
> > No, he's right.
> >
> > v1[] = v2['A'..'Z'+1]
> >
> > Looks weird. Looks wrong. What a mess...
>
> Just how frequently you index array with chars?
> Also v2[0 .. v2.length] looks nice and suites
> for(int i = 0; i < v2.length; i++) syntax.
>
>

Clearly both ways have some advantages and disadvantages.
The end-inclusive way works more natural for arrays and ranges
of fixed sizes. [0,10] looks like 10 is included. But when size
variables are used [0, array.size] end-exclusive looks more
natural than having to subtract one element manually. I still
agree with the notation suggested in another thread, where
the programmer can choose:

[0,9]
[0,10)
(-1,0]
(-1,10)

Would all denote elements 0 up to and including 9, but not 10.
The last two would probably hardly be used, but the whole idea
has a very nice feeling of consistency around it. Especially the
fact that [0,10) uses two different characters to denote that
it uses two different ways of 'inclusiveness' to me looks very
natural and I think that notation is also used in math.
There is something about this consistency that makes it very
powerfull, even when at first sight it might look 'funny'. I would
vote for this option, also because you are never forced to
add or subtract one manually to correct for the inclusiveness,
which is going to end up wrong for some situations whichever
one you choose.

These two examples both look unnatural, when in fact, depending on the inclusiveness, one might be forced to write that way:

[0, array.size-1]
['A', 'Z' + 1]

A good idea, but unfortunately not mine. It was somewehere back in the newsgroup, but I can't remember who posted it.


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

Comma doesn't do a good job of denoting a range... that's what dotdot is for.

Damn... no I just fell into the same trap as you did.  <grin>

Anyway if this route ends up being taken I think "thru" would be a better
keyword than "to" (maybe)

case (1, 3 thru 5, 7)

Yeah... still looks funny, would take some getting used to.

Sean



"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C711D06.A4EABA23@deming-os.org...
> Pavel Minayev wrote:
>
> > Another idea is to use different syntax:
> >
> >     case (1, 3 to 5, 7) ...
>
> Personal opinion:
>
> To my eye, the comma has "higher precedence" than "to".  That is, when I
> looked at it, my eyes saw it as
>         case ((1,3) to (5,7)) ...
> which was confusing to say the least.
>
> I'm not (very much) opposed to forking off a new syntax, I just would
> opine that that syntax isn't the one. :)

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a4tcpn$2vn3$1@digitaldaemon.com...
> Comma doesn't do a good job of denoting a range... that's what dotdot is for.
>
> Damn... no I just fell into the same trap as you did.  <grin>
>
> Anyway if this route ends up being taken I think "thru" would be a better
> keyword than "to" (maybe)
>
> case (1, 3 thru 5, 7)
>
> Yeah... still looks funny, would take some getting used to.

Just a thought...
I wonder how loudly Walter does laugh while he reads all this... =)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4u1f8$8p1$1@digitaldaemon.com...
> Just a thought...
> I wonder how loudly Walter does laugh while he reads all this... =)

If anyone can find the humor in all this, I hope it's Walter.  ;)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4u1f8$8p1$1@digitaldaemon.com...
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a4tcpn$2vn3$1@digitaldaemon.com...
> > Comma doesn't do a good job of denoting a range... that's what dotdot is for.
> >
> > Damn... no I just fell into the same trap as you did.  <grin>
> >
> > Anyway if this route ends up being taken I think "thru" would be a
better
> > keyword than "to" (maybe)
> >
> > case (1, 3 thru 5, 7)
> >
> > Yeah... still looks funny, would take some getting used to.
>
> Just a thought...
> I wonder how loudly Walter does laugh while he reads all this... =)
>


:)


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

On Sat, 16 Feb 2002 12:12:59 -0700, Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:
> Pavel Minayev wrote:
> 
> > This is what I think it should look like. Yes, it might look somewhat
> > strange, but at least a D newbie won't get a headache trying to
> > understand why case(1 .. 5) works for all 1 <= n <= 5, while
> > array[1 .. 5] turns out to have length of 4 elements...
> >
> > ...but _personally_, I wouldn't mind if there was such syntax. Simply because I will be aware of it either way. =)
> 
> (twitch)
> 
> You just made the best argument yet for end-INclusive array slicing syntax.
> 
> --
 It's such a shame.  All these problems disappear once you realize
that an array (of objects or case values) is an ordered set
which is therefore  naturally denoted with ordinals.

Karl Bochert

Karl Bochert wrote:
>  It's such a shame.  All these problems disappear once you realize
> that an array (of objects or case values) is an ordered set
> which is therefore  naturally denoted with ordinals.

Thus, arrays should be 1-based?

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C747A1C.5090300@estarcion.com...

> Thus, arrays should be 1-based?

So what?
I don't see how it'd affect slicing syntax.

Pavel Minayev wrote:
> "Russell Borogove" <kaleja@estarcion.com> wrote in message
> news:3C747A1C.5090300@estarcion.com...
> 
> 
>>Thus, arrays should be 1-based?
>>
> 
> So what?
> I don't see how it'd affect slicing syntax.

Well, if you were 1-based, it would be natural to be
both-ends-inclusive in all cases, because array.length
would be the index of the last element as well as its
size. I am not sure if this was what Mr. Bochert was
getting at or not.

You'd have to get used to starting from one, and you'd
want to use <= instead of < in the idiomatic for-loop:

for (i = 1; i <= array.length; i++)
{
   ...
}

-RB

This would be bad from a performance standpoint, as the compiler would have to sneak in a hidden "minus one" when indexing into an array.  Admittedly sometimes it could do this offset at compile time, if the array address is known at compile time.  Or the BASIC approach could be used, and the language allocate one extra entry in each array to humor those careless C programmers who think 0 is a valid index.  ;)

Sean

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C747CC4.1020100@estarcion.com...
> Pavel Minayev wrote:
> > "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C747A1C.5090300@estarcion.com...
> >
> >
> >>Thus, arrays should be 1-based?
> >>
> >
> > So what?
> > I don't see how it'd affect slicing syntax.
>
> Well, if you were 1-based, it would be natural to be
> both-ends-inclusive in all cases, because array.length
> would be the index of the last element as well as its
> size. I am not sure if this was what Mr. Bochert was
> getting at or not.
>
> You'd have to get used to starting from one, and you'd
> want to use <= instead of < in the idiomatic for-loop:
>
> for (i = 1; i <= array.length; i++)
> {
>     ...
> }