It would be interesting if D borrowed the negative indexes of ruby.

Such as an array of number starts from 0 to 6 and the end of the array starts at -1.   So a[1, -1] would be able to iterate over the array without length.

In article <ccbtcr$2ft6$1@digitaldaemon.com>, Gowron says...
>
>It would be interesting if D borrowed the negative indexes of ruby.
>
>Such as an array of number starts from 0 to 6 and the end of the array starts at -1.   So a[1, -1] would be able to iterate over the array without length.
>

This was suggested before.
I don't remember Walter showing any interest at all.

build an Array template, I can use it

Ant

Gowron wrote:

> It would be interesting if D borrowed the negative indexes of ruby.
> 
> Such as an array of number starts from 0 to 6 and the end of the array starts at -1.

Been talked to death already.

http://www.digitalmars.com/drn-bin/wwwnews?D/24082

> So a[1, -1] would be able to iterate over the array without length.

What do you mean by this?  By your suggestion, that would simply mean a without the first and last elements.

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.

Gowron wrote:

> It would be interesting if D borrowed the negative indexes of ruby.
> 
> Such as an array of number starts from 0 to 6 and the end of the array
> starts at
> -1.   So a[1, -1] would be able to iterate over the array without length.


That idea has been discussed a little while ago without clear resolution. I think the original idea (the same that you are stating) was discarded rather quickly:

* for one, negative indices do have a certain meaning when used on pointers (just counting backwards) so it would be rather confusing to give them a different meaning for arrays.

* for the other, checking for the sign would have to happen at runtime which would be costly at every array access. Currently, there is only bounds-checking happening, which can be switched off after the debugging phase of a program.

The improved idea that was discussed lateron did appear in different variations. The version I liked most, was to introduce the symbol $ as a special symbol only within indexing expressions, meaning: the range of this dimension.

This would allow you to write:
        a[1..$-1]
instead of your suggestion.

It looks nice and - as I think - rather intuitive. The drawback that I see, though, is that it uses up the character $ which could actually be used much better for some other, more important language extensions in the future.

Alternative suggestions were similar, just using a keyword instead of the $

Nice thing would be, that you can also easily pick the middle of an array
(at least for even ranges)

Anyhow: Walter did not seem to show much interest and the matter is not really pressing.

It would be neat to have, especially for people doing extensive string handling, but it should not be a problem to add at some later point of time.

It's an interesting idea, but we'd lose the ability to catch some accidental out-of-bounds accesses, which is IMHO enough reason not to do it.

Norbert Nemec wrote:
> Gowron wrote:
> The improved idea that was discussed lateron did appear in different
> variations. The version I liked most, was to introduce the symbol $ as a
> special symbol only within indexing expressions, meaning: the range of this
> dimension.
> 
> This would allow you to write:
>         a[1..$-1]
> instead of your suggestion.
Hmm, for normal arrays have array.length, for multidimensional arrays, we're going to need a nice way to get the nth dimension anyway.
Sam

Sam McCall wrote:

> It's an interesting idea, but we'd lose the ability to catch some accidental out-of-bounds accesses, which is IMHO enough reason not to do it.
> 
> Norbert Nemec wrote:
>> Gowron wrote:
>> The improved idea that was discussed lateron did appear in different
>> variations. The version I liked most, was to introduce the symbol $ as a
>> special symbol only within indexing expressions, meaning: the range of
>> this dimension.
>> 
>> This would allow you to write:
>>         a[1..$-1]
>> instead of your suggestion.
> Hmm, for normal arrays have array.length, for multidimensional arrays,
> we're going to need a nice way to get the nth dimension anyway.
> Sam

For multi-dim arrays .length could return the total number of elements and another property (for argument's sake call it "dims") could return a static array of the size of each dimension. Then length = dims[0] * dims[1] * ... * dims[N-1].

There isn't any way around adding some property like "dims" since that information needs to be available outside of indexing expressions. Whether the "length" property returns the array or "dims" or something else it doesn't really matter.

Personally I'm not a huge fan of $ since the properties are more readable and general.

Ben Hinkle wrote:

> Sam McCall wrote:
> 
>> It's an interesting idea, but we'd lose the ability to catch some accidental out-of-bounds accesses, which is IMHO enough reason not to do it.
>> 
>> Norbert Nemec wrote:
>>> Gowron wrote:
>>> The improved idea that was discussed lateron did appear in different
>>> variations. The version I liked most, was to introduce the symbol $ as a
>>> special symbol only within indexing expressions, meaning: the range of
>>> this dimension.
>>> 
>>> This would allow you to write:
>>>         a[1..$-1]
>>> instead of your suggestion.
>> Hmm, for normal arrays have array.length, for multidimensional arrays,
>> we're going to need a nice way to get the nth dimension anyway.
>> Sam
> 
> For multi-dim arrays .length could return the total number of elements and another property (for argument's sake call it "dims") could return a static array of the size of each dimension. Then length = dims[0] * dims[1] * ... * dims[N-1].

In my proposal, .length only exists for 1D-arrays. Here it is assignable with the magic of reallocating and copying the data if necessary.

What you call "dims" is called .range in my proposal. It has itself the semantics of a fixed array of length N. Assigning to it is possible, but unsafe and without any magic (it boils down to assigning to the raw entries in the array-reference structure)

The product of all ranges is implemented as a new, read-only property .volume

The .size property equals .volume time the size of one entry.

> Personally I'm not a huge fan of $ since the properties are more readable and general.

You are sure about "readable"?

        S1.A[2..S1.A.range[0]-1,2..S1.A.range[1]-1] =
            S2.B[2..S2.B.range[0]-1,2..S2.B.range[1]-1];
vs.
        S1.A[2..$-1,2..$-1] = S2.B[2..$-1,2..$-1];

And don't tell me this is constructed. I'm working with Matlab, where I have code like this all over the place.

Of course, the $ is not very general, but be honest: the range of and array is used so often in indexing it, that it would really make sense to think about a reasonable shorthand.

My only concern about $ is, that it really uses up one character that is so far unused and might find some much more important role sometimes in the future. (Just like # which we should really preserve until we find some worthy application for it.)

In article <ccdd9k$1h4v$1@digitaldaemon.com>, Norbert Nemec says...

>My only concern about $ is, that it really uses up one character that is so far unused and might find some much more important role sometimes in the future. (Just like # which we should really preserve until we find some worthy application for it.)


Let's use the £ sign or the € sign then. (The dollar is not the only currency on this planet <g> ).

Arcane Jill

PS. The EURO SIGN character is U+20AC (not U+0080 as Windows would have us
believe).

Hmm, you do make a good point.
Norbert Nemec wrote:
> My only concern about $ is, that it really uses up one character that is so
> far unused and might find some much more important role sometimes in the
> future. (Just like # which we should really preserve until we find some
> worthy application for it.)
Exactly, we already have a "perfectly functional" Perl ;-)
A keyword sounds like the answer, three alternatives:
1) Make "range" a keyword, and something like foo[2,range-1] would know that foo[2,foo.range[1]-1] was intended.
In the case of nested array accesses, I would suggest that this gets the range of the inner one, and if you want the range of an outer one you must write it out in full as now. There are certainly ways of extending it, but I think they'd be complicated for little benefit.
2) Create a new keyword. Hard to find something short, descriptive, and where it won't be annoying that you can't use it as a variable name (in and out are bad enough). Maybe end?
3) Cleverly reuse an existing keyword in an unambiguous way, like "in" is used for assoc arrays and parameters[1]. The only one that is obvious is "final", and i'm not sure if that's good.

[1] could we have
  foreach(char a in str)
instead of/in addition to
  foreach(char a; str)?
It's not much longer, it's clearer, it doesn't seem to be ambiguous, and it makes it completely obvious that the variable goes first, and the container after.

Sam

Sam McCall wrote:

> Hmm, you do make a good point.
> Norbert Nemec wrote:
>> My only concern about $ is, that it really uses up one character that is so far unused and might find some much more important role sometimes in the future. (Just like # which we should really preserve until we find some worthy application for it.)
> Exactly, we already have a "perfectly functional" Perl ;-)
> A keyword sounds like the answer, three alternatives:
> 1) Make "range" a keyword, and something like foo[2,range-1] would know
> that foo[2,foo.range[1]-1] was intended.

That might be an idea. Of course, with "range" being handled specially here, this would really be a mess for the syntax, which Walter definitely will not like (and I don't, either)

What would "range" be?

* A keyword? That would make it impossible to use it as identifier any other context. Ugly!

* A argument-less function that is predefined only in this context? Maybe. It would not collide with the .range[] property, which always is used as qualifier for an array. And anybody using range as an unqualified identifier will have to live with the collision.

Can argument-less functions generally be called without the parenthesis? Or is this only true for member functions (acting as properties)?

> In the case of nested array accesses, I would suggest that this gets the range of the inner one, and if you want the range of an outer one you must write it out in full as now. There are certainly ways of extending it, but I think they'd be complicated for little benefit.

There is no problem. "range" would of course always refer to that dimension where it is used for indexing.