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/

"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. :(

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/

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

> 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

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?

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?

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.

>> 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?

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