www.digitalmars.com         C & C++   DMDScript  

D - A Suggestion: Negative array subscripts

reply James Fox <James_member pathlink.com> writes:
Here's a minor suggestion: While D and many languages are 0-indexed with respect
to arrays, a language I know of called Icon also has *negative subscripting*,
namely, indexing backwards from the end of the array. Therefore, the last
element could be given the index -1, the next to last -2, and so on. It's just a
bit of synactic sugar, but I think a[-1] is slightly cleaner and neather than
a[a.length-1]. Similarly, the index 0 could also stand for beyond the end of the
array if used as the second value in a slice (but not the first), so a[0..0] is
a slice of the entire array, a[1..0] is everything except the first element, and
so on.

I have to admit, however, that I think things would be neater if the second
value in a slice was inclusive, thus making a[0..-1] a slice of the entire
array, and a[0..0] just a[0].

I hope this might be of interest.

James Fox
Feb 17 2004
next sibling parent reply Carlos Santander B. <Carlos_member pathlink.com> writes:
In article <c0u0pc$1tka$1 digitaldaemon.com>, James Fox says...

Here's a minor suggestion: While D and many languages are 0-indexed with respect
to arrays, a language I know of called Icon also has *negative subscripting*,
namely, indexing backwards from the end of the array. Therefore, the last
element could be given the index -1, the next to last -2, and so on. It's just a
bit of synactic sugar, but I think a[-1] is slightly cleaner and neather than
a[a.length-1]. Similarly, the index 0 could also stand for beyond the end of the
array if used as the second value in a slice (but not the first), so a[0..0] is
a slice of the entire array, a[1..0] is everything except the first element, and
so on.

I have to admit, however, that I think things would be neater if the second
value in a slice was inclusive, thus making a[0..-1] a slice of the entire
array, and a[0..0] just a[0].

I hope this might be of interest.

James Fox


I can't test it while at work, but I believe that's doable with this:
char [] [int] foo;
foo[-1] = "hi";
Sure, it's a hash table, but at least you have your negative indexes ;)
Or, you could write a class with opIndex(int).

-------------------
Carlos Santander B.
Feb 17 2004
parent Sam McCall <tunah.d tunah.net> writes:
 I can't test it while at work, but I believe that's doable with this:
 char [] [int] foo;
 foo[-1] = "hi";
 Sure, it's a hash table, but at least you have your negative indexes ;)


Er, but how does that make foo[-1] reference the same index as 
foo[foo.length-1]?
It's interesting, but I don't think it would work for D.
Sam
Feb 17 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Sorry, that's a bad idea.

The reason is that we're all far too used to using -ve indexes in their
"correct" mathematical context, i.e. a[-1] means get the element 1 before
a[0]

This comes about from the equivalence between subscripting syntax and
pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, then the
arithmetic is no less valid.

FYI, I once wrote a string class that committed this and many other crimes
against good sense. It had a short and miserable life, and only remains as a
reminder of how crap I once was. (This is actually featured as one of the
little horrors in Appendix B in my new book "Imperfect C++".)



"James Fox" <James_member pathlink.com> wrote in message
news:c0u0pc$1tka$1 digitaldaemon.com...

 Here's a minor suggestion: While D and many languages are 0-indexed with


respect

 to arrays, a language I know of called Icon also has *negative


subscripting*,

 namely, indexing backwards from the end of the array. Therefore, the last
 element could be given the index -1, the next to last -2, and so on. It's


just a

 bit of synactic sugar, but I think a[-1] is slightly cleaner and neather


than

 a[a.length-1]. Similarly, the index 0 could also stand for beyond the end


of the

 array if used as the second value in a slice (but not the first), so


a[0..0] is

 a slice of the entire array, a[1..0] is everything except the first


element, and

 so on.

 I have to admit, however, that I think things would be neater if the


second

 value in a slice was inclusive, thus making a[0..-1] a slice of the entire
 array, and a[0..0] just a[0].

 I hope this might be of interest.

 James Fox
Feb 17 2004
parent reply Derek Parnell <Derek.Parnell No.Spam> writes:
On Wed, 18 Feb 2004 11:44:13 +1100 (02/18/04 11:44:13)
, Matthew <matthew.hat stlsoft.dot.org> wrote:


 Sorry, that's a bad idea.

 The reason is that we're all far too used to using -ve indexes in their
 "correct" mathematical context, i.e. a[-1] means get the element 1 before
 a[0]

 This comes about from the equivalence between subscripting syntax and
 pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, then the
 arithmetic is no less valid.

 FYI, I once wrote a string class that committed this and many other 
 crimes
 against good sense. It had a short and miserable life, and only remains 
 as a
 reminder of how crap I once was. (This is actually featured as one of the
 little horrors in Appendix B in my new book "Imperfect C++".)


I tend to agree with you on this Matthew. However the concept of a token 
that signifies a reference to the last element is still a useful idea. Off 
the top of my head, I suggest the Regular Expression symbol '$', such that 
a[$] refers to the last element. Thus things like a[4..$] and a[$-4..$-2], 
and a[$-var] would all be valid.

-- 
Derek
Feb 17 2004
next sibling parent Oskar <Oskar_member pathlink.com> writes:
In article <opr3jv1uo3yj5swd news.digitalmars.com>, Derek Parnell says...


I tend to agree with you on this Matthew. However the concept of a token 
that signifies a reference to the last element is still a useful idea. Off 
the top of my head, I suggest the Regular Expression symbol '$', such that 
a[$] refers to the last element. Thus things like a[4..$] and a[$-4..$-2], 
and a[$-var] would all be valid.


Another programming language (lpc dialect) uses the < to symbolize indexing from
the end:
a[<1] == last entry
a[<2..<1] == last two entries
a[0..<1] == all entries

And also, omitting the limits of a slice means the beginning or the end:
a[1..] == all but the first
a[..<2] == all but the last
a[..2] == the first three
Feb 18 2004
prev sibling next sibling parent reply C <dont respond.com> writes:
I like the $, as its common to many languages that use regualr =

expressions.  If this gets adopted the $ gets my vote.

C

On Wed, 18 Feb 2004 16:26:08 +1100, Derek Parnell <Derek.Parnell No.Spam=

 =


wrote:


 On Wed, 18 Feb 2004 11:44:13 +1100 (02/18/04 11:44:13)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 Sorry, that's a bad idea.

 The reason is that we're all far too used to using -ve indexes in the=




ir

 "correct" mathematical context, i.e. a[-1] means get the element 1 =





 before
 a[0]

 This comes about from the equivalence between subscripting syntax and=





 pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, then=




 =


 the
 arithmetic is no less valid.

 FYI, I once wrote a string class that committed this and many other =





 crimes
 against good sense. It had a short and miserable life, and only remai=




ns =


 as a
 reminder of how crap I once was. (This is actually featured as one of=




 =


 the
 little horrors in Appendix B in my new book "Imperfect C++".)


 I tend to agree with you on this Matthew. However the concept of a tok=


en =


 that signifies a reference to the last element is still a useful idea.=


 =


 Off the top of my head, I suggest the Regular Expression symbol '$', =



 such that a[$] refers to the last element. Thus things like a[4..$] an=


d =


 a[$-4..$-2], and a[$-var] would all be valid.




-- =

Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 18 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
i hate the $. it reminds me of $variables in php and friends.

ugly ugly ugly.

i'd suggest..the ..

° is never used yet, is it? ° all the way :D

"C" <dont respond.com> schrieb im Newsbeitrag
news:opr3lcnggdehmtou localhost...
I like the $, as its common to many languages that use regualr
expressions.  If this gets adopted the $ gets my vote.

C

On Wed, 18 Feb 2004 16:26:08 +1100, Derek Parnell <Derek.Parnell No.Spam>
wrote:


 On Wed, 18 Feb 2004 11:44:13 +1100 (02/18/04 11:44:13)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 Sorry, that's a bad idea.

 The reason is that we're all far too used to using -ve indexes in their
 "correct" mathematical context, i.e. a[-1] means get the element 1
 before
 a[0]

 This comes about from the equivalence between subscripting syntax and
 pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, then
 the
 arithmetic is no less valid.

 FYI, I once wrote a string class that committed this and many other
 crimes
 against good sense. It had a short and miserable life, and only remains
 as a
 reminder of how crap I once was. (This is actually featured as one of
 the
 little horrors in Appendix B in my new book "Imperfect C++".)


 I tend to agree with you on this Matthew. However the concept of a token
 that signifies a reference to the last element is still a useful idea.
 Off the top of my head, I suggest the Regular Expression symbol '$',
 such that a[$] refers to the last element. Thus things like a[4..$] and
 a[$-4..$-2], and a[$-var] would all be valid.




-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 18 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


i hate the $. it reminds me of $variables in php and friends.

ugly ugly ugly.

i'd suggest..the ..

° is never used yet, is it? ° all the way :D

  


How do you type ° efficiently with a standard 101 us keyboard?
Feb 19 2004
next sibling parent reply "davepermen" <davepermen hotmail.com> writes:
no clue, but with a standard swiss keyboard its the top left key, directly
under esc..  with shift.. (else its §).

the $ is rather bad placed for me (between backspace and enter..)..

"J Anderson" <REMOVEanderson badmama.com.au> schrieb im Newsbeitrag
news:c12eth$79s$1 digitaldaemon.com...

 davepermen wrote:


i hate the $. it reminds me of $variables in php and friends.

ugly ugly ugly.

i'd suggest..the ..

° is never used yet, is it? ° all the way :D


 How do you type ° efficiently with a standard 101 us keyboard?
Feb 19 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


no clue, but with a standard swiss keyboard its the top left key, directly
under esc..  with shift.. (else its §).

the $ is rather bad placed for me (between backspace and enter..)..
  


My point is that most languages are written (and should be written) with 
the us keyboard in mind, as it's the largest market.  ° isn't on these 
keyboards (well without the alt combination).

-- 
-Anderson: http://badmama.com.au/~anderson/
Feb 20 2004
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <c12eth$79s$1 digitaldaemon.com>, J Anderson says...


[...]

How do you type ° efficiently with a standard 101 us keyboard?


<irony>
Simply buy an european keyboard, keyboards nowadays are cheap.
</irony>

Ciao

P.S.: If you don't understand, look to the newsgroup archives, where I please to
not use Alt-126 (~) because it's not present in most european keyboards.



 Feb 19 2004



 next sibling parent  Juanjo Álvarez <juanjux yahoo.es>  writes:


In article <c12i6v$dl1$1 digitaldaemon.com>, Roberto Mariottini says... 
 

not


use Alt-126 (~) because it's not present in most european keyboards. 
 
Mmm,
it's present in mine (ES_es keyboard) althought somewhat hidden (AltGr+4). 
 



 Feb 19 2004



prev sibling next sibling parent  "davepermen" <davepermen hotmail.com>  writes:


i have it here.. it's altgr-^

"Roberto Mariottini" <Roberto_member pathlink.com> schrieb im Newsbeitrag
news:c12i6v$dl1$1 digitaldaemon.com...

 In article <c12eth$79s$1 digitaldaemon.com>, J Anderson says...


 [...]

How do you type ° efficiently with a standard 101 us keyboard?


 <irony>
 Simply buy an european keyboard, keyboards nowadays are cheap.
 </irony>

 Ciao

 P.S.: If you don't understand, look to the newsgroup archives, where I


please to

 not use Alt-126 (~) because it's not present in most european keyboards.





 Feb 19 2004



prev sibling next sibling parent  "davepermen" <davepermen hotmail.com>  writes:




i have



thats my set:D

(combinations with shift, and altgr, and with nothing else)

"Roberto Mariottini" <Roberto_member pathlink.com> schrieb im Newsbeitrag
news:c12i6v$dl1$1 digitaldaemon.com...

 In article <c12eth$79s$1 digitaldaemon.com>, J Anderson says...


 [...]

How do you type ° efficiently with a standard 101 us keyboard?


 <irony>
 Simply buy an european keyboard, keyboards nowadays are cheap.
 </irony>

 Ciao

 P.S.: If you don't understand, look to the newsgroup archives, where I


please to

 not use Alt-126 (~) because it's not present in most european keyboards.





 Feb 19 2004



prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu>  writes:


Roberto Mariottini wrote:

 <irony>
 Simply buy an european keyboard, keyboards nowadays are cheap.
 </irony>


Yup, i find the european layout quite sane, except for Italian which 
doesn't hold to the more common european layout.


 P.S.: If you don't understand, look to the newsgroup archives, where I please
to
 not use Alt-126 (~) because it's not present in most european keyboards.


MOST??? I had seen German, French, and Finnish have it. Even the Israeli 
and the Russian keyboards do, IIRC.

-eye



 Feb 19 2004



  parent  "Serge K" <skarebo programmer.net>  writes:


 P.S.: If you don't understand, look to the newsgroup archives, where I please
to
 not use Alt-126 (~) because it's not present in most european keyboards.


 MOST??? I had seen German, French, and Finnish have it. Even the Israeli
 and the Russian keyboards do, IIRC.


The only european keyboard without (~) is Italian.
But there are TWO Italian keyboard layouts in Windows,
and the second one actually has (~) and (`).
You should try to switch to "Italian (142)" layout.

The differences are: < Character : Italian  /  Italian (142) >
  : AltGr-Ò(;)  /  AltGr-Q

[ : AltGr-È([) / AltGr-8
] : AltGr-+(]) / AltGr-9
{ : AltGr-Shift-È([)  /  AltGr-7
} : AltGr-Shift-+(])  /  AltGr-0
~ : ...  /  AltGr-+(])
` : ...  /  AltGr-Ù(\)



 Feb 19 2004



prev sibling  parent reply "Serge K" <skarebo programmer.net>  writes:


 P.S.: If you don't understand, look to the newsgroup archives, where I please
to
 not use Alt-126 (~) because it's not present in most european keyboards.


(ups, the first reply went one level down ...)

The only european keyboard without (~) is Italian.
But there are TWO Italian keyboard layouts in Windows,
and the second one actually has (~) and (`).
You should try to switch to "Italian (142)" layout.

The differences are: < Character : Italian  /  Italian (142) >
  : AltGr-Ò(;)  /  AltGr-Q

[ : AltGr-È([) / AltGr-8
] : AltGr-+(]) / AltGr-9
{ : AltGr-Shift-È([)  /  AltGr-7
} : AltGr-Shift-+(])  /  AltGr-0
~ : ...  /  AltGr-+(])
` : ...  /  AltGr-Ù(\)



 Feb 19 2004



  parent reply Roberto Mariottini <Roberto_member pathlink.com>  writes:


In article <c142c1$3vs$1 digitaldaemon.com>, Serge K says...

The only european keyboard without (~) is Italian.


So I am particularily lucky?
I know there are other without Alt-126, many are without Alt-123 and Alt-125
(which I have, even if "undocumented").


But there are TWO Italian keyboard layouts in Windows,
and the second one actually has (~) and (`).
You should try to switch to "Italian (142)" layout.


I know, I've already tried. 
It's simply not easy to change the position of []{} that are used very
frequently to have Alt-126 and Alt-96 handy. Moreover it doesn't have  .
I wonder why the parenthesis are put in this order: {[]}
Ok, [] are the same keys as (), but why '{' with '/' and '}' with '=' ?
AltGr-7 is not an easy combination to type.

This reminds me something: does anyone has any clue on how to change the Windows
keyboard mapping? I could add a bounch of AltGr combination...

I have to do a keyboard driver?

Ciao



 Feb 20 2004



 next sibling parent reply Ilya Minkov <minkov cs.tum.edu>  writes:


Roberto Mariottini wrote:

 This reminds me something: does anyone has any clue on how to change the
Windows
 keyboard mapping? I could add a bounch of AltGr combination...
 
 I have to do a keyboard driver?


This is vastly different for Windows9x and for Windows NT(/2k/XP). I 
think one uses something more like maps and the other something more 
like DLLs... or they were both DLLs but with different sets of features? 
I can't remember. Anyway, the keyboard drivers are not compatible.

So, you can use something like this to sort out your problems:

http://www.klm.freeservers.com/Medium/

It is shareware, but with  *un*limited (!) trial. :> The trial features 
limit it to personal use, i.e. you cannot create drivers to use elsewhere.

-eye



 Feb 20 2004



  parent  Manfred Nowak <svv1999 hotmail.com>  writes:


On Fri, 20 Feb 2004 20:30:43 +0100, Ilya Minkov wrote:


 with  *un*limited (!) trial.


How do you read the license? I only undertsand a limit of 30 days.

So long.



 Feb 21 2004



prev sibling  parent  "Serge K" <skarebo programmer.net>  writes:


The only european keyboard without (~) is Italian.


 So I am particularily lucky?
 I know there are other without Alt-126, many are without Alt-123 and Alt-125
 (which I have, even if "undocumented").


I cannot find european keyboard layout without (~),
and all of them do have "{ }" (=Alt-123 and Alt-125).
Unless you are talking about not Latin layouts - Russian, Greek and alike.
But they are unusable for programmers anyhow, and can be switched to Latin mode.


But there are TWO Italian keyboard layouts in Windows,
and the second one actually has (~) and (`).
You should try to switch to "Italian (142)" layout.


 I know, I've already tried.
 It's simply not easy to change the position of []{} that are used very
 frequently to have Alt-126 and Alt-96 handy. Moreover it doesn't have  .


It does. But the key is different :

 The differences are: < Character : Italian  /  Italian (142) >
   : AltGr-Ò(;)  /  AltGr-Q





 I wonder why the parenthesis are put in this order: {[]}
 Ok, [] are the same keys as (), but why '{' with '/' and '}' with '=' ?
 AltGr-7 is not an easy combination to type.


Who knows!
IMHO it is not a very smart choise. (btw, [] are not at the same keys as ()...)
But it is the standard for at least Danish, Finnish, German, Icelandic,
Norwegian, Portuguese, Swedish and Turkish.


 This reminds me something: does anyone has any clue on how to change the
Windows
 keyboard mapping? I could add a bounch of AltGr combination...

 I have to do a keyboard driver?


If you use Win2K or WinXP, try this one:
Microsoft Keyboard Layout Creator
http://www.microsoft.com/downloads/details.aspx?FamilyID=fb7b3dcd-d4c1-4943-9c74-d8df57ef19d7&displaylang=en



 Feb 20 2004



prev sibling  parent  C <dont respond.com>  writes:


What is that ? =B0 lol

C

On Thu, 19 Feb 2004 01:01:20 +0100, davepermen <davepermen hotmail.com> =

wrote:


 i hate the $. it reminds me of $variables in php and friends.

 ugly ugly ugly.

 i'd suggest..the ..

 =B0 is never used yet, is it? =B0 all the way :D

 "C" <dont respond.com> schrieb im Newsbeitrag
 news:opr3lcnggdehmtou localhost...
 I like the $, as its common to many languages that use regualr
 expressions.  If this gets adopted the $ gets my vote.

 C

 On Wed, 18 Feb 2004 16:26:08 +1100, Derek Parnell <Derek.Parnell No.Sp=


am>

 wrote:


 On Wed, 18 Feb 2004 11:44:13 +1100 (02/18/04 11:44:13)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 Sorry, that's a bad idea.

 The reason is that we're all far too used to using -ve indexes in th=






eir

 "correct" mathematical context, i.e. a[-1] means get the element 1
 before
 a[0]

 This comes about from the equivalence between subscripting syntax an=






d

 pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, the=






n

 the
 arithmetic is no less valid.

 FYI, I once wrote a string class that committed this and many other
 crimes
 against good sense. It had a short and miserable life, and only rema=






ins

 as a
 reminder of how crap I once was. (This is actually featured as one o=






f

 the
 little horrors in Appendix B in my new book "Imperfect C++".)


 I tend to agree with you on this Matthew. However the concept of a to=




ken

 that signifies a reference to the last element is still a useful idea=




.

 Off the top of my head, I suggest the Regular Expression symbol '$',
 such that a[$] refers to the last element. Thus things like a[4..$] a=




nd

 a[$-4..$-2], and a[$-var] would all be valid.






-- =

Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



 Feb 23 2004



prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


"Derek Parnell" <Derek.Parnell No.Spam> wrote in message
news:opr3jv1uo3yj5swd news.digitalmars.com...

 On Wed, 18 Feb 2004 11:44:13 +1100 (02/18/04 11:44:13)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 Sorry, that's a bad idea.

 The reason is that we're all far too used to using -ve indexes in their
 "correct" mathematical context, i.e. a[-1] means get the element 1




before

 a[0]

 This comes about from the equivalence between subscripting syntax and
 pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, then




the

 arithmetic is no less valid.

 FYI, I once wrote a string class that committed this and many other
 crimes
 against good sense. It had a short and miserable life, and only remains
 as a
 reminder of how crap I once was. (This is actually featured as one of




the

 little horrors in Appendix B in my new book "Imperfect C++".)


 I tend to agree with you on this Matthew. However the concept of a token
 that signifies a reference to the last element is still a useful idea. Off
 the top of my head, I suggest the Regular Expression symbol '$', such that
 a[$] refers to the last element. Thus things like a[4..$] and a[$-4..$-2],
 and a[$-var] would all be valid.


That seems attractive, but it's not really convincing when one can simply
use a.length. :(



 Feb 18 2004



  parent reply Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Thu, 19 Feb 2004 09:53:51 +1100 (02/19/04 09:53:51)
, Matthew <matthew.hat stlsoft.dot.org> wrote:


 "Derek Parnell" <Derek.Parnell No.Spam> wrote in message
 news:opr3jv1uo3yj5swd news.digitalmars.com...

 On Wed, 18 Feb 2004 11:44:13 +1100 (02/18/04 11:44:13)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 Sorry, that's a bad idea.

 The reason is that we're all far too used to using -ve indexes in 


 their

 "correct" mathematical context, i.e. a[-1] means get the element 1




 before

 a[0]

 This comes about from the equivalence between subscripting syntax and
 pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, then




 the

 arithmetic is no less valid.

 FYI, I once wrote a string class that committed this and many other
 crimes
 against good sense. It had a short and miserable life, and only 


 remains

 as a
 reminder of how crap I once was. (This is actually featured as one of




 the

 little horrors in Appendix B in my new book "Imperfect C++".)


 I tend to agree with you on this Matthew. However the concept of a token
 that signifies a reference to the last element is still a useful idea. 
 Off
 the top of my head, I suggest the Regular Expression symbol '$', such 
 that
 a[$] refers to the last element. Thus things like a[4..$] and 
 a[$-4..$-2],
 and a[$-var] would all be valid.


 That seems attractive, but it's not really convincing when one can simply
 use a.length. :(


Yes, its just a matter of style and/or taste. My take on it is that the 
'$' is just syntax-sugar to make writing code and reading code easier. The 
types of cases where this is most evident is when you have long(ish) 
identifier names.


  xyzzy = v_Customer_Hash_Table[lPosition .. v_Customer_Hash_Table.length]

instead of

  xyzzy = v_Customer_Hash_Table[lPosition .. $]

So yes, the '$' token is semantically equivalent to '<ARRAY>.length' when 
detected inside a slice expression; it is just a shorthand notation. But 
that is the whole point - it is a useful shorthand notation.

In my (biased) philosophy of programming, it is more important that a 
programming language makes life easier for the coder/maintainer/reader 
(aka. user) than for the compiler/hardware (aka. tool). Thus it could be 
seen as a responsibility of the language designers to ensure that their 
language has constructs, even redundant alternatives, that will be helpful 
to users of their lannguage.

I believe that this can be done without compromising the integrity of a 
language's base design guide or philosophy, and without unnecessary bloat.


-- 
Derek



 Feb 18 2004



  parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


 On Thu, 19 Feb 2004 09:53:51 +1100 (02/19/04 09:53:51)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 "Derek Parnell" <Derek.Parnell No.Spam> wrote in message
 news:opr3jv1uo3yj5swd news.digitalmars.com...

 On Wed, 18 Feb 2004 11:44:13 +1100 (02/18/04 11:44:13)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 Sorry, that's a bad idea.

 The reason is that we're all far too used to using -ve indexes in


 their

 "correct" mathematical context, i.e. a[-1] means get the element 1




 before

 a[0]

 This comes about from the equivalence between subscripting syntax and
 pointer arithmetic. a[i] is equivalent to *(a + i). If i is -ve, then




 the

 arithmetic is no less valid.

 FYI, I once wrote a string class that committed this and many other
 crimes
 against good sense. It had a short and miserable life, and only


 remains

 as a
 reminder of how crap I once was. (This is actually featured as one of




 the

 little horrors in Appendix B in my new book "Imperfect C++".)


 I tend to agree with you on this Matthew. However the concept of a






token

 that signifies a reference to the last element is still a useful idea.
 Off
 the top of my head, I suggest the Regular Expression symbol '$', such
 that
 a[$] refers to the last element. Thus things like a[4..$] and
 a[$-4..$-2],
 and a[$-var] would all be valid.


 That seems attractive, but it's not really convincing when one can




simply

 use a.length. :(


 Yes, its just a matter of style and/or taste. My take on it is that the
 '$' is just syntax-sugar to make writing code and reading code easier. The
 types of cases where this is most evident is when you have long(ish)
 identifier names.


   xyzzy = v_Customer_Hash_Table[lPosition .. v_Customer_Hash_Table.length]

 instead of

   xyzzy = v_Customer_Hash_Table[lPosition .. $]

 So yes, the '$' token is semantically equivalent to '<ARRAY>.length' when
 detected inside a slice expression; it is just a shorthand notation. But
 that is the whole point - it is a useful shorthand notation.


This specific case is covered by the implicit end, in syntax that was
proposed a long time ago

   xyzzy = v_Customer_Hash_Table[lPosition .. ]

In the same way, an implicit start would also be available

   xyzzy = v_Customer_Hash_Table[ .. 10]


 In my (biased) philosophy of programming, it is more important that a
 programming language makes life easier for the coder/maintainer/reader
 (aka. user) than for the compiler/hardware (aka. tool).


I'm not sure of the precise point on the spectrum, but I certainly believe
maintainability is more important than it is currently recognised to be in
the design of languages, including D.


 Thus it could be
 seen as a responsibility of the language designers to ensure that their
 language has constructs, even redundant alternatives, that will be helpful
 to users of their lannguage.


True


 I believe that this can be done without compromising the integrity of a
 language's base design guide or philosophy, and without unnecessary bloat.


Hopefully



 Feb 18 2004



 next sibling parent reply larry cowan <larry_member pathlink.com>  writes:


 So yes, the '$' token is semantically equivalent to '<ARRAY>.length' when
 detected inside a slice expression; it is just a shorthand notation. But
 that is the whole point - it is a useful shorthand notation.


This specific case is covered by the implicit end, in syntax that was
proposed a long time ago

   xyzzy = v_Customer_Hash_Table[lPosition .. ]

In the same way, an implicit start would also be available

   xyzzy = v_Customer_Hash_Table[ .. 10]


 In my (biased) philosophy of programming, it is more important that a
 programming language makes life easier for the coder/maintainer/reader
 (aka. user) than for the compiler/hardware (aka. tool).


I'm not sure of the precise point on the spectrum, but I certainly believe
maintainability is more important than it is currently recognised to be in
the design of languages, including D.


Implicit start and end have the very bad effect of allowing valid, but
syntactically incomplete expressions, which can be hard to find errors in if
used very much (as well as adding burden to parsers).

Also, we have very easy references off of the front of the array ( just a bare
index ), and asking for '$' or an equivalent allows offsetting there as well,
almost as easily (e.g., $-4).

This brings up another problem though - immediately, the slice context will be
compared to the array element reference, and people will ask for "element =
array[$-4];" to be a valid statement.  What about that folks?

It is the same in that the specific object is part of the reference to a subset
which is defined within following braces.  It's probably difficult to the
compiler to syntactically allow the slice form usage and not the element ref
usage.  Is a $ inside [] the same everywhere?



 Feb 19 2004



  parent reply Manfred Nowak <svv1999 hotmail.com>  writes:


larry cowan wrote:

[...]

 Is a $ inside [] the same everywhere?


Not to forget those who use overloading with opIndex and OpSlice. Now
overloading with opDollar is a must. But is tehre always sense in it?

So long.



 Feb 19 2004



  parent reply "davepermen" <davepermen hotmail.com>  writes:


no, opDollar is no must. if the object has a .length property, then opDollar
just returns that value. and thats it.

don't make it too generic when you don't want it to be..

"Manfred Nowak" <svv1999 hotmail.com> schrieb im Newsbeitrag
news:c12o1v$odi$1 digitaldaemon.com...

 larry cowan wrote:

 [...]

 Is a $ inside [] the same everywhere?


 Not to forget those who use overloading with opIndex and OpSlice. Now
 overloading with opDollar is a must. But is tehre always sense in it?

 So long.





 Feb 19 2004



  parent reply Manfred Nowak <svv1999 hotmail.com>  writes:


davepermen wrote:


 if the object has a .length property, then opDollar
 just returns that value. and thats it.


As the standard .length property can be redefined this approach might be
too simple.

So long.



 Feb 19 2004



  parent reply "davepermen" <davepermen hotmail.com>  writes:


why? that way, it is overloadable. but with automatic, and rather logical
behaviour.

just as opAdd overloads + += and all at the same time, too..

"Manfred Nowak" <svv1999 hotmail.com> schrieb im Newsbeitrag
news:c13gso$25v7$1 digitaldaemon.com...

 davepermen wrote:


 if the object has a .length property, then opDollar
 just returns that value. and thats it.


 As the standard .length property can be redefined this approach might be
 too simple.

 So long.





 Feb 20 2004



  parent  larry cowan <larry_member pathlink.com>  writes:


Just a few notes here before the original topic gets lost -

1. The original request for negative indices seems to have been spurned.

2. Usage as array[$] or array[last] conflicts with usage as slice[x..$] or
slice[x..length].  The slice usage seems better - don't like last+1 or $+1 to
indicate ".length".

3.  Also, don't think it is really an operator and in need of opDollar.  The
defined usage should be within array brackets only, as $ or length.

-larry

In article <c14hkt$13cr$1 digitaldaemon.com>, davepermen says...

why? that way, it is overloadable. but with automatic, and rather logical
behaviour.

just as opAdd overloads + += and all at the same time, too..

"Manfred Nowak" <svv1999 hotmail.com> schrieb im Newsbeitrag
news:c13gso$25v7$1 digitaldaemon.com...

 davepermen wrote:


 if the object has a .length property, then opDollar
 just returns that value. and thats it.


 As the standard .length property can be redefined this approach might be
 too simple.

 So long.







 Feb 20 2004



prev sibling  parent reply Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Thu, 19 Feb 2004 14:08:20 +1100 (02/19/04 14:08:20)
, Matthew <matthew.hat stlsoft.dot.org> wrote:


 On Thu, 19 Feb 2004 09:53:51 +1100 (02/19/04 09:53:51)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 "Derek Parnell" <Derek.Parnell No.Spam> wrote in message






[snip]

 So yes, the '$' token is semantically equivalent to '<ARRAY>.length' 
 when
 detected inside a slice expression; it is just a shorthand notation. But
 that is the whole point - it is a useful shorthand notation.


 This specific case is covered by the implicit end, in syntax that was
 proposed a long time ago

    xyzzy = v_Customer_Hash_Table[lPosition .. ]

 In the same way, an implicit start would also be available

    xyzzy = v_Customer_Hash_Table[ .. 10]


Yes, I remember this, and it is a common suggestion in other languages 
too. My issue with this idea is that it encourages mistakes to be made. An 
omitted token is ambiguous - it could be a mistake or not a mistake, and 
both are syntactically valid. I'm suggesting a compromise between brevity 
and easy-of-use.

Someone famous (Einstein?) once said "Things should be as simple as 
possible, but not too simple."

-- 
Derek



 Feb 19 2004



 next sibling parent  "Matthew" <matthew.hat stlsoft.dot.org>  writes:


"Derek Parnell" <Derek.Parnell Psyc.ward> wrote in message
news:opr3m4qie8deu3pf news.digitalmars.com...

 On Thu, 19 Feb 2004 14:08:20 +1100 (02/19/04 14:08:20)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 On Thu, 19 Feb 2004 09:53:51 +1100 (02/19/04 09:53:51)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:


 "Derek Parnell" <Derek.Parnell No.Spam> wrote in message






 [snip]

 So yes, the '$' token is semantically equivalent to '<ARRAY>.length'
 when
 detected inside a slice expression; it is just a shorthand notation.






But

 that is the whole point - it is a useful shorthand notation.


 This specific case is covered by the implicit end, in syntax that was
 proposed a long time ago

    xyzzy = v_Customer_Hash_Table[lPosition .. ]

 In the same way, an implicit start would also be available

    xyzzy = v_Customer_Hash_Table[ .. 10]


 Yes, I remember this, and it is a common suggestion in other languages
 too. My issue with this idea is that it encourages mistakes to be made. An
 omitted token is ambiguous - it could be a mistake or not a mistake, and
 both are syntactically valid. I'm suggesting a compromise between brevity
 and easy-of-use.


Good point


 Someone famous (Einstein?) once said "Things should be as simple as
 possible, but not too simple."


I think it was Einstein



 Feb 19 2004



prev sibling  parent reply Manfred Nowak <svv1999 hotmail.com>  writes:


Derek Parnell wrote:

[...]

 Someone famous (Einstein?) once said "Things should be as simple as 
 possible, but not too simple."


"Look, I made them as simple as possible, but no simpler." 
-- Albert Einstein after beeing accused to have too complex models
http://www.artima.com/intv/simplest2.html

Therefore this aphorism is not well suited in this case.

So long.



 Feb 19 2004



  parent  Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Fri, 20 Feb 2004 04:18:52 +0100 (02/20/04 14:18:52)
, Manfred Nowak <svv1999 hotmail.com> wrote:


 Derek Parnell wrote:

 [...]

 Someone famous (Einstein?) once said "Things should be as simple as
 possible, but not too simple."


 "Look, I made them as simple as possible, but no simpler."
 -- Albert Einstein after beeing accused to have too complex models
 http://www.artima.com/intv/simplest2.html

 Therefore this aphorism is not well suited in this case.

 So long.


Maybe you are right. I was thinking along the lines that a '$' is a short 
recognisable symbol and is thus is it a simple as possible (within the 
'helping others' constaint) but that an omitted token would be way too 
simple.

Whatever. I think we have all made our points understood. Now if only we 
could agree ;-D

-- 
Derek



 Feb 19 2004



prev sibling  parent reply Sean Kelly <sean ffwd.cx>  writes:


Derek Parnell wrote:

 
 I tend to agree with you on this Matthew. However the concept of a token 
 that signifies a reference to the last element is still a useful idea. 
 Off the top of my head, I suggest the Regular Expression symbol '$', 
 such that a[$] refers to the last element. Thus things like a[4..$] and 
 a[$-4..$-2], and a[$-var] would all be valid.


Why a token?  I'd prefer C++-style iterator semantics here, and possibly 
add properties begin, end, rbegin, and rend.  I was planning on doing 
something like this using standalone functions anyway.


Sean



 Feb 19 2004



  parent reply Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Thu, 19 Feb 2004 13:00:32 -0800 (02/20/04 08:00:32)
, Sean Kelly <sean ffwd.cx> wrote:


 Derek Parnell wrote:

 I tend to agree with you on this Matthew. However the concept of a 
 token that signifies a reference to the last element is still a useful 
 idea. Off the top of my head, I suggest the Regular Expression symbol 
 '$', such that a[$] refers to the last element. Thus things like 
 a[4..$] and a[$-4..$-2], and a[$-var] would all be valid.


 Why a token?  I'd prefer C++-style iterator semantics here, and possibly 
 add properties begin, end, rbegin, and rend.  I was planning on doing 
 something like this using standalone functions anyway.


I didn't literally mean a one-character-non-alphabetic thing. Anything 
that looks like a 'special' syntax element would surfice, and that could 
be a keyword or an operator-like character. I'm not wedded to the '$' 
symbol or anything else in particular.

However, if the worth of expending the energy in putting this idea in to a 
compiler is justified, whatever token is decided on, it should be as short 
as possible and very easily recognised by a human reader. We are trying to 
make life easier for coders, yes?

-- 
Derek



 Feb 19 2004



 next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


What about a new keyword, 'last'?


"Derek Parnell" <Derek.Parnell Psyc.ward> wrote in message
news:opr3m4cktxdeu3pf news.digitalmars.com...

 On Thu, 19 Feb 2004 13:00:32 -0800 (02/20/04 08:00:32)
 , Sean Kelly <sean ffwd.cx> wrote:


 Derek Parnell wrote:

 I tend to agree with you on this Matthew. However the concept of a
 token that signifies a reference to the last element is still a useful
 idea. Off the top of my head, I suggest the Regular Expression symbol
 '$', such that a[$] refers to the last element. Thus things like
 a[4..$] and a[$-4..$-2], and a[$-var] would all be valid.


 Why a token?  I'd prefer C++-style iterator semantics here, and possibly
 add properties begin, end, rbegin, and rend.  I was planning on doing
 something like this using standalone functions anyway.


 I didn't literally mean a one-character-non-alphabetic thing. Anything
 that looks like a 'special' syntax element would surfice, and that could
 be a keyword or an operator-like character. I'm not wedded to the '$'
 symbol or anything else in particular.

 However, if the worth of expending the energy in putting this idea in to a
 compiler is justified, whatever token is decided on, it should be as short
 as possible and very easily recognised by a human reader. We are trying to
 make life easier for coders, yes?

 -- 
 Derek





 Feb 19 2004



 next sibling parent reply Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Fri, 20 Feb 2004 10:56:38 +1100 (02/20/04 10:56:38)
, Matthew <matthew.hat stlsoft.dot.org> wrote:


 What about a new keyword, 'last'?


The issue I have with using things that look like identifiers (a.k.a. 
keywords) is that it takes away yet another 'word' away from our identifer 
namespace. We already have many keywords that are prevent an identically 
named identifier from being used in the same context - do we really need 
any more? Maybe - maybe not. If the loss of a word is worth the gain then 
fine.

Then there is the 'English' orientation of many of our programming 
languages. Sure, English maybe the new lingua franca, but it adds another 
hurdle to people who's first language is not English. Its too late to do 
anything about this of course, (and in anycase some human language would 
more than likely have to be used) but do we need another English keyword 
in D? As an exercise to demonstrate this, I like to get an experienced 
coder to 'translate' any program of her choice such that all keywords are 
turned in to gibberish and then get somebody else to review the translated 
code. Even with a 'dictionary' it is a frustrating and humourous exercise.

But I digress...I'm unable to form a judgement in this specific case, as 
to whether '$', 'last' or something else is the best alternative. However, 
the concept is still a good one, IMHO.

-- 
Derek



 Feb 19 2004



  parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi>  writes:


In article <opr3ngqey5deu3pf news.digitalmars.com>, Derek Parnell wrote:

 On Fri, 20 Feb 2004 10:56:38 +1100 (02/20/04 10:56:38)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:
 

 What about a new keyword, 'last'?


 
 The issue I have with using things that look like identifiers (a.k.a. 
 keywords) is that it takes away yet another 'word' away from our identifer 
 namespace.


This is quite true. Something more context-sensitive would be definitely
better, so that the word "last" wouldn't have to be sacrificed for mere
array indexing.



One alternative would be to extend the scope of identifier lookup, so
that something[0 .. last] would actually mean the same thing as
something[0 .. something.last]. Disclaimer: this one doesn't sound that
straightforward to define and implement. And it could result in
maintenance and readibility problems. Maybe. But it would be intriguing
indeed.

-Antti



 Feb 22 2004



 next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


Antti Sykäri wrote:


In article <opr3ngqey5deu3pf news.digitalmars.com>, Derek Parnell wrote:
  


On Fri, 20 Feb 2004 10:56:38 +1100 (02/20/04 10:56:38)
, Matthew <matthew.hat stlsoft.dot.org> wrote:

    


What about a new keyword, 'last'?
      


The issue I have with using things that look like identifiers (a.k.a. 
keywords) is that it takes away yet another 'word' away from our identifer 
namespace.
    


This is quite true. Something more context-sensitive would be definitely
better, so that the word "last" wouldn't have to be sacrificed for mere
array indexing.



One alternative would be to extend the scope of identifier lookup, so
that something[0 .. last] would actually mean the same thing as
something[0 .. something.last]. Disclaimer: this one doesn't sound that
straightforward to define and implement. And it could result in
maintenance and readibility problems. Maybe. But it would be intriguing
indeed.

-Antti
  


I think

something[0 .. ] 

is better.


-- 
-Anderson http://badmama.com.au/~anderson/



 Feb 22 2004



  parent  Derek Parnell <Derek.Parnell Psyc.ward>  writes:


On Mon, 23 Feb 2004 15:19:20 +0800 (02/23/04 18:19:20)
, J Anderson <REMOVEanderson badmama.com.au> wrote:


 Antti Sykäri wrote:


 In article <opr3ngqey5deu3pf news.digitalmars.com>, Derek Parnell wrote:


 On Fri, 20 Feb 2004 10:56:38 +1100 (02/20/04 10:56:38)
 , Matthew <matthew.hat stlsoft.dot.org> wrote:



 What about a new keyword, 'last'?








[snip]


 I think

 something[0 .. ] is better.


I'm sorry, did you omit something here or not. Who'd ever know what you 
were intending?

In this context, an omitted expression might lead to more problems than it 
would solve, IMHO.

-- 
Derek



 Feb 23 2004



prev sibling  parent  "Walter" <newshound digitalmars.com>  writes:


"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnc3iiqc.rqi.jsykari pulu.hut.fi...




Context sensitive keywords would impair separating the lexing pass from the
syntactic pass. While tempting, I think this would be a poor choice for the
future. It also smacks of a kludge.



 Jul 22 2004



prev sibling  parent reply Manfred Nowak <svv1999 hotmail.com>  writes:


Matthew wrote:


 What about a new keyword, 'last'?


I would vote for that. But not for the arguments that come up so far.

There is no other way to refer to the last element in anonymous slices and
therefore the use of this keyword should be restricted to those anonymous
slices.

So long.



 Feb 19 2004



  parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:c140u7$1em$1 digitaldaemon.com...

 Matthew wrote:


 What about a new keyword, 'last'?


 I would vote for that. But not for the arguments that come up so far.

 There is no other way to refer to the last element in anonymous slices and
 therefore the use of this keyword should be restricted to those anonymous
 slices.


Interesting point. :)



 Feb 19 2004



  parent  Manfred Nowak <svv1999 hotmail.com>  writes:


Matthew wrote:


 Interesting point. :)


I retreat from my vote: anonymous slices are too seldom. If reference to
the last element of such anonymous slices is needed, it should be made
named.

Do not inflate the language with keywords that are used rarely.

By the way: what is the proposed semantic of `a[1..a.length-1][2..last]'?

So long. 



 Feb 21 2004



prev sibling  parent reply Sean Kelly <sean ffwd.cx>  writes:


Derek Parnell wrote:

 
 I didn't literally mean a one-character-non-alphabetic thing. Anything 
 that looks like a 'special' syntax element would surfice, and that could 
 be a keyword or an operator-like character. I'm not wedded to the '$' 
 symbol or anything else in particular.
 
 However, if the worth of expending the energy in putting this idea in to 
 a compiler is justified, whatever token is decided on, it should be as 
 short as possible and very easily recognised by a human reader. We are 
 trying to make life easier for coders, yes?


True enough.  In that case I have a request.  Support for reverse 
copying (and perhaps slicing?).  Something along these lines:

char[] a = "abc";
char[3] b;
b[] = a[2..-1];

In this case, b should contain "cba."  Right now, D doesn't support this 
idea at all, and even if it did, there's no way to refer to the element 
before the first element (ie. rend).  Reverse-slicing could be neat too, 
but that sounds like it would have some technical issues to overcome.


Sean



 Feb 19 2004



  parent  Sean Kelly <sean ffwd.cx>  writes:


Just as a clarification, I thought this might be applicable because it 
would be easiest done using a new symbol, ie.

char[] a = "abc";
char[3] b;
b = a[!0..!3];

In this case, the '!' signifies that the string is to be indexed in reverse.


Sean



 Feb 19 2004



prev sibling next sibling parent  "BERO" <berobero users.sourceforge.net>  writes:


I think it's easy to make your own wrapper (template) class or struct using
opIndex() or opSlice()

bero



 Feb 18 2004



prev sibling  parent reply Stewart Gordon <smjg_1998 yahoo.com>  writes:


While it was 2/17/04 9:23 PM throughout the UK, James Fox sprinkled 
little black dots on a white screen, and they fell thus:


 Here's a minor suggestion: While D and many languages are 0-indexed with
respect
 to arrays, a language I know of called Icon also has *negative subscripting*,
 namely, indexing backwards from the end of the array. Therefore, the last
 element could be given the index -1, the next to last -2, and so on. It's just
a
 bit of synactic sugar, but I think a[-1] is slightly cleaner and neather than
 a[a.length-1].


There would be a slight performance hit if we had to check the sign of 
every array subscript at run time, in the cases where it can't be 
determined at compile time.

<snip>

 I have to admit, however, that I think things would be neater if the second
 value in a slice was inclusive, thus making a[0..-1] a slice of the entire
 array,


We already have this - a[].


 and a[0..0] just a[0].


A slice and an element aren't the same, even if it's a one-element slice.

It's too late to change it now without breaking existing programs.  And 
without reintroducing the fencepost errors that the semantics were 
presumably invented to cut out.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.



 Feb 18 2004



 next sibling parent  Matthias Becker <Matthias_member pathlink.com>  writes:


It's too late to change it now without breaking existing programs.


You realy did complete programs using D? You know that D still hasn't reached
1.0?



 Feb 18 2004



prev sibling  parent  larry cowan <larry_member pathlink.com>  writes:


I'm all in favor of leaving the slice syntax as [beginix..lastix+1], and not in
favor of adding the negative values as back from the end, BUT strongly in favor
of having a $ or other shorthand for the lastix+1 ( = x.length ) value - the
length is known, so the translation should be simple.  I have already coded a
painfully large number of those to clip off the front end of strings.

The use of [0..0] gives an empty slice, as does "y = 0; z = 0; str[y..z]", but
[4..4] causes an array bounds error.  WHY? 

--------------------------------------------
In article <c0vgfa$18h9$1 digitaldaemon.com>, Stewart Gordon says...

While it was 2/17/04 9:23 PM throughout the UK, James Fox sprinkled 
little black dots on a white screen, and they fell thus:


 Here's a minor suggestion: While D and many languages are 0-indexed with
respect
 to arrays, a language I know of called Icon also has *negative subscripting*,
 namely, indexing backwards from the end of the array. Therefore, the last
 element could be given the index -1, the next to last -2, and so on. It's just
a
 bit of synactic sugar, but I think a[-1] is slightly cleaner and neather than
 a[a.length-1].


There would be a slight performance hit if we had to check the sign of 
every array subscript at run time, in the cases where it can't be 
determined at compile time.

<snip>

 I have to admit, however, that I think things would be neater if the second
 value in a slice was inclusive, thus making a[0..-1] a slice of the entire
 array,


We already have this - a[].


 and a[0..0] just a[0].


A slice and an element aren't the same, even if it's a one-element slice.

It's too late to change it now without breaking existing programs.  And 
without reintroducing the fencepost errors that the semantics were 
presumably invented to cut out.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.





 Feb 18 2004