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

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

 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

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

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

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

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

 so on.

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

 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=


 "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=


 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=

 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=

 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

  

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


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..)..
  

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

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

 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:
what about  ? or   or # ? or  or  or  .. wich ones are common?

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

 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-3(#) [ : 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-3(#) [ : 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=

 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=



 "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=



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



 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=



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



 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=


 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=


 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


 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


 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


 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 

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


 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


 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 

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


 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

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


 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


 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

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


 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



 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


 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.



 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. C# has some kind of context-sensitive keywords if I recall correctly. 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 Sykri 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'?
      

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. C# has some kind of context-sensitive keywords if I recall correctly. 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

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 Sykri 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 Sykri" <jsykari gamma.hut.fi> wrote in message
news:slrnc3iiqc.rqi.jsykari pulu.hut.fi...
 C# has some kind of context-sensitive keywords if I recall correctly.

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