Hello,

In the array section of the D docs (http://www.digitalmars.com/d/arrays.html), there is no mention of the $ operator. Only the "a = a[2 .. a.length]" idiom is shown. I suppose that should be fixed.

My experience of array slicing comes from Python, so I found it a bit surprising that a "array[2..]" notation didn't exist ("array[2:]" in Python). I later found the $ operator in others' code, which mostly fixes that.

How about supporting, as in Python:

a[-1] == a[$];
a[0..] == a[0..$];

I personally dislike the $ operator, it seems a casual fix for a lack of better notation and someting you'd expect to find in Perl. I still prefer it to the more verbose "a[2 .. a.length]" notation, though. The verbose notation has the disadvantage of taking more whitespace; while most people read "a[2..3]" just fine it's a bit confusing to read "a[1..a.length]". Also, if you rename or use a different array you have two instances to correct, instead of one.

The Python syntax seems to me a better generalization of the concepts. It doesn't require an extra operator, the indexes and the slice notation have all the expressiveness required.

With omissive indexes (a[..7]) and wrapping indexes (a[-2]) the $ could go away.
Is it too late for that?

Luís Marques

Luís Marques wrote:
> My experience of array slicing comes from Python, so I found it a bit surprising that a "array[2..]" notation didn't exist ("array[2:]" in Python). I later found the $ operator in others' code, which mostly fixes that.

The omissive indices are not yet supported, but they could be added as an abbreviation without much trouble. It is just one character ("0" or "$" vs. "") difference. I don't have a strong opinion on that point.

> How about supporting, as in Python:
> 
> a[-1] == a[$];

That should be:
a[-1] == a[$-1]

> a[0..] == a[0..$];
> 
> I personally dislike the $ operator, it seems a casual fix for a lack of better notation and someting you'd expect to find in Perl.

I actually quite like the notation. At first, I didn't like the idea of "wasting" the precious ASCII character "$" for this profane purpose, but compared to all other proposed solutions, this is the cleanest.

Also, to me "$" does not seem too counterintuitive. The character has the long tradition of signifying the end of a line in regular expressions, which somehow feels related to the issue at hand, even though I have never seriously worked with Perl.

> I still prefer it to the more verbose "a[2 .. a.length]" notation, though.

That may be fine for "a", but it scales up very badly if you replace a by a more complex expression.

The advantage of "$" will become even more obvious once there are is better support for multidimensional arrays (yes, I'm still working on a refined proposal for those) and the integer property "length" is replaces by an integer array "shape":

consider adressing the interior (everything but the boundaries) of a 2D
array:
	somearray[1..somearray.shape[0]-1,1..somearray.shape[1]-1]
vs.
	somearray[1..$-1,1..$-1]

Or consider indexing via periodic boundary conditions on a 3D grid:

	mygrid[x%mygrid.shape[0],y%mygrid.shape[1],z%mygrid.shape[2]]
vs.
	mygrid[x%$,y%$,z%$]



> The verbose notation has the
> disadvantage of taking more whitespace; while most people read "a[2..3]" just
> fine it's a bit confusing to read "a[1..a.length]". Also, if you rename or use a
> different array you have two instances to correct, instead of one.
> 
> The Python syntax seems to me a better generalization of the concepts. It doesn't require an extra operator, the indexes and the slice notation have all the expressiveness required.
> 
> With omissive indexes (a[..7]) and wrapping indexes (a[-2]) the $ could go away.

These would be a bad replacement:
* omissive indexes are a nice abbreviation but have far less power than
the "$" symbol
* negative indices would have to be checked for at run time giving a
performace penalty that is unacceptable if D tries to aim for a position
in the league of high-performance computing languages.

In article <e0rrgk$1gko$1@digitaldaemon.com>, Norbert Nemec says...
>That may be fine for "a", but it scales up very badly if you replace a by a more complex expression.

Notice that I did say I still prefer $ to the verbose .length, not that I prefer
using .length
I just find it ugly.

>	somearray[1..$-1,1..$-1]

or somearray[1..-2,1..-2]

>* omissive indexes are a nice abbreviation but have far less power than the "$" symbol

Which cases are you thinking about?

>* negative indices would have to be checked for at run time giving a performace penalty that is unacceptable if D tries to aim for a position in the league of high-performance computing languages.

Kind of like array out of bounds exceptions, which is already implemented?

Thanks for you feedback,

Luís

In article <e0rmga$1bi6$1@digitaldaemon.com>, Luís Marques says...

>notation and someting you'd expect to find in Perl. I still prefer it to the more verbose "a[2 .. a.length]" notation, though. The verbose notation has the disadvantage of taking more whitespace; while most people read "a[2..3]" just fine it's a bit confusing to read "a[1..a.length]". Also, if you rename or use a different array you have two instances to correct, instead of one.
>

You can do a[1..length]. length always refer to the array length when it is used inside the indexing operator. So there is only 1 place to correct when you change the array name. length is more verbose but definitely more readable.

In article <e0rupf$1kbg$1@digitaldaemon.com>, Luís Marques says...
>or somearray[1..-2,1..-2]

somearray[1..-1,1..-1], of course. You are right about having missed the right
indexes, but otherwise my
opinion remain. I guess it's a matter of style, mostly.

Luís

In article <e0s0m0$1mp9$1@digitaldaemon.com>, Hong says...
>
>In article <e0rmga$1bi6$1@digitaldaemon.com>, Luís Marques says...
>
>>notation and someting you'd expect to find in Perl. I still prefer it to the more verbose "a[2 .. a.length]" notation, though. The verbose notation has the disadvantage of taking more whitespace; while most people read "a[2..3]" just fine it's a bit confusing to read "a[1..a.length]". Also, if you rename or use a different array you have two instances to correct, instead of one.
>>
>
>You can do a[1..length]. length always refer to the array length when it is used inside the indexing operator. So there is only 1 place to correct when you change the array name. length is more verbose but definitely more readable.

Oh yes, I was forgetting that variant. That's nice, thanks.
Perhaps one more reason against having $, though I guess several will disagree.

Luís

Obviously we both agree that "$" is nicer than nothing (i.e. better than
having to use ".length")

I also agree with you that Python syntax looks nicer than D syntax. However

a) Python syntax is not an option for D, because it would require runtime checks that result in an unnecessary performace penalty. This cannot be compared to array bounds checks, which can be turned off after debugging phase. The performance penalty would have to be payed by everyone using arrays, even if they are not even interested in negative indexing

b) The $ is even more powerful than Python-syntax in at least one very
interesting way:
	somearray[x%$,y%$,z%$]
is the most beautiful solution I ever saw for the common problem of
periodic boundaries!

B.t.w.: Be careful!

D syntax: somearray[1..$-1,1..$-1]
is equivalent to
Python syntax: somearray[1..-1,1..-1]

you mixed this up in your examples bringing in a -2 somewhere.


Finally you asked:
>>* omissive indexes are a nice abbreviation but have far less power than the "$" symbol
> 
> Which cases are you thinking about?

I call "omissive indices" only "[.." instead of "[0.." and "..]" instead of "..$]". Obviously these cover only the trivial corner cases and the syntax cannot naturally be extended to anything beyond these.

Greetings,
Norbert

The "length" variant will become problematic once we have multidimensional arrays, where the integer number "length" is replaced by an integer array "shape". "$" can be given a very special meaning by the compiler without problems for the parser, allowing

	somearray[1..$-1,1..$-1,1..$-1]

to mean the same thing as

	somearray[1..shape[0]-1,1..shape[1]-1,1..shape[2]-1]

to get the same effect with using "length" instead of "$", the word "length" would probably have to become a keyword, which would disallow its use as property. (Unless you really want to mess up the parser...)

Greetings,
Norbert



Hong wrote:
> In article <e0rmga$1bi6$1@digitaldaemon.com>, Lu疄 Marques says...
> 
> 
>>notation and someting you'd expect to find in Perl. I still prefer it to the more verbose "a[2 .. a.length]" notation, though. The verbose notation has the disadvantage of taking more whitespace; while most people read "a[2..3]" just fine it's a bit confusing to read "a[1..a.length]". Also, if you rename or use a different array you have two instances to correct, instead of one.
>>
> 
> 
> You can do a[1..length]. length always refer to the array length when it is used inside the indexing operator. So there is only 1 place to correct when you change the array name. length is more verbose but definitely more readable.
> 
> 

In article <e0s6a7$1sbs$1@digitaldaemon.com>, Norbert Nemec says...
>b) The $ is even more powerful than Python-syntax in at least one very
>interesting way:
>	somearray[x%$,y%$,z%$]
>is the most beautiful solution I ever saw for the common problem of
>periodic boundaries!

Yes, that one is very nice.

>you mixed this up in your examples bringing in a -2 somewhere.

Thanks, I noticed it later.

>I call "omissive indices" only "[.." instead of "[0.." and "..]" instead of "..$]". Obviously these cover only the trivial corner cases and the syntax cannot naturally be extended to anything beyond these.

How would you extend it with $?

That's a good review. Things like this should be noted somewhere..

So,
$ is better designed for multidimensional arrays
$ is shorter than .length

Still thinking, then, couldn't this work:

somearray[x%length,y%length,z%length]

length would evaluate differently for each dimension of the array.
The only advantage would be $ being shorter (somearray[0..] would work for the
simpler cases)

Luís Marques

On Mon, 3 Apr 2006 22:47:37 +0000 (UTC), Luís Marques wrote:

> $ is shorter than .length

One problem with 'length' is that is not a keyword in all contexts, and so an innocent coding mistake such as the one below can occur and is manifested at run time. And even then its not so easy to see if you're not focusing on 'length'.

import std.stdio;
void main()
{
    int length;
    char[] foo;

    foo = "derek parnell".dup;
    length = 4;
    while( foo[length] != 'a' )
        foo = foo[1..$];

    writefln("%s", foo);
}

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
4/04/2006 11:40:09 AM