On Mon, 31 Mar 2008 00:26:10 +0200, Scott S. McCoy <tag@cpan.org> wrote:

> You also could if array[5 .. -3] implied length -3.
>
> Similarly. array[-3] could imply array[array.length -3]...
>
> But someone suggested against that, atleast for non-compile time
> checking.  I would agree, for the non-literal instance that a negative
> integer of -5 shouldn't result in magical figuring out if the element
> needs to be pulled from the front or the back.  But the literal case
> adds expressiveness, I think.

T[int] foo;

What is foo[-3]?

And user-defined types with overloaded opIndex and opSlice.
Should [-X] work differently for them?

-- Simen

bearophile, el 30 de marzo a las 16:03 me escribiste:
> Leandro Lucarella:
> > In python this is array[5:-1], which seems a lot nicer to me...
> 
> I know many languages, and in many situations I think Python has a good syntax (like Python list comprehensions and generators, two things that I think D may enjoy a LOT). But in this case I think D has chosen a better solution: if you allow a syntax like [5:-1], then in every access to an array you have to compute a modulus, or a sum, for the wrap around. ShedSkin does this, but in tight loops on arrays this slows down the code (in ShedSkin there is a compilation option to disable that, to increase running speed). For Python that's not a big problem, because Python is designed to be the best for the programmer first, and for the CPU then, but D is supposed to be fast almost as C, and just adding a single $ character it avoids that slowdown, so I think this is a really good compromise (that future languages will probably copy from D).

I really can't see any overhead in array[5..-1] being syntax sugar for
array[5..$-1]. I'm not talking about array[5..-1] returning an empty array
if the array.lenght is 3 for example (which is really nice too, but I
agree that the overhead could be ... polemic, so it might better suite
in the standard library).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Una mujer en bicicleta, con sombrero de paja, es la más flagrante
violación a las leyes de la aerodinamia.
	-- Ricardo Vaporeso. 21 de Septiembre de 1917.

Leandro Lucarella wrote:
> bearophile, el 30 de marzo a las 16:03 me escribiste:
>> Leandro Lucarella:
>>> In python this is array[5:-1], which seems a lot nicer to me...
>> I know many languages, and in many situations I think Python has a good syntax (like Python list comprehensions and generators, two things that I think D may enjoy a LOT). But in this case I think D has chosen a better solution: if you allow a syntax like [5:-1], then in every access to an array you have to compute a modulus, or a sum, for the wrap around. ShedSkin does this, but in tight loops on arrays this slows down the code (in ShedSkin there is a compilation option to disable that, to increase running speed). For Python that's not a big problem, because Python is designed to be the best for the programmer first, and for the CPU then, but D is supposed to be fast almost as C, and just adding a single $ character it avoids that slowdown, so I think this is a really good compromise (that future languages will probably copy from D).
> 
> I really can't see any overhead in array[5..-1] being syntax sugar for
> array[5..$-1]. I'm not talking about array[5..-1] returning an empty array
> if the array.lenght is 3 for example (which is really nice too, but I
> agree that the overhead could be ... polemic, so it might better suite
> in the standard library).

Yeh, array[5..-1] wouldn't necessarily have any overhead, but how about array[5..a]?

--bb

Leandro Lucarella wrote:
> bearophile, el 30 de marzo a las 16:03 me escribiste:
>> Leandro Lucarella:
>>> In python this is array[5:-1], which seems a lot nicer to me...
>> I know many languages, and in many situations I think Python has a good syntax (like Python list comprehensions and generators, two things that I think D may enjoy a LOT). But in this case I think D has chosen a better solution: if you allow a syntax like [5:-1], then in every access to an array you have to compute a modulus, or a sum, for the wrap around. ShedSkin does this, but in tight loops on arrays this slows down the code (in ShedSkin there is a compilation option to disable that, to increase running speed). For Python that's not a big problem, because Python is designed to be the best for the programmer first, and for the CPU then, but D is supposed to be fast almost as C, and just adding a single $ character it avoids that slowdown, so I think this is a really good compromise (that future languages will probably copy from D).
> 
> I really can't see any overhead in array[5..-1] being syntax sugar for
> array[5..$-1]. I'm not talking about array[5..-1] returning an empty array
> if the array.lenght is 3 for example (which is really nice too, but I
> agree that the overhead could be ... polemic, so it might better suite
> in the standard library).
> 

Except the mental overhead of interpreting -1 as array.length - 1.

Scott S. McCoy wrote:
> You also could if array[5 .. -3] implied length -3.

How would I do:

	array[5 .. foo($)]

?

Reply to Scott,

> You also could if array[5 .. -3] implied length -3.
> 
> Similarly. array[-3] could imply array[array.length -3]...
> 

what about  "array[$/2]" or  "Fn(array[0..$/2]) + Fn(array[$/2..$])"

On 31/03/2008, Leandro Lucarella <llucax@gmail.com> wrote:
> I really can't see any overhead in array[5..-1] being syntax sugar for
>  array[5..$-1].

You can't? Well, I can. Let me show you.

    struct MyArray
    {
        MyArray opSlice(int lower, int upper)
        {
            ...
        }
    }

    MyArray array;
    auto slice = array[5..-1];

This calls MyArray.opSlice(5, -1). Are you suggesting it should
instead call MyArray.opSlice(5, __dollar-1)? Can you not just see the
bug reports flying in?

And here's a second problem

    int[] array;
    int n = -1;

    slice1 = array[5..-1];
    slice2 = array[5..n];

You'd expect slice1 and slice2 to be the same, but in fact array[5..n] will throw in a debug build, and cause a segfault in a release build. Not good.

Scott S. McCoy wrote:
> You also could if array[5 .. -3] implied length -3.
> 
> Similarly. array[-3] could imply array[array.length -3]...

I guess the problem you (and I guess quite a lot of people) ultimately have is, the $ looks like a after-thought, sticks in the eye in a language that otherwise doesn't use the $ too much, and if one is also used to some interpreted language it looks clumsy in this context.

Before $ got this role in D, there were months of (lively) discussion about the alternatives. Ultimately, this is short to type, has expressive power, is totally obvious as to the intent, and it is easy to spot a typo within the brackets.

So, it's not pretty, but to figure out a better alternative would need both hard work and luck. :-) And even then, one would have a hard sell in demonstrating the advantages, which would have to be significant. It's not like the $ issue is the easiest one to get really reopened.

I don't think that's any fair, partially because I would have never assumed that would even work.

you would say:

array[ 5 .. foo(array.length) ] naturally, and at the office in a code
review if I saw someone doing foo($) I would explicitly ask them to
change it to foo(array.length) anyway.

On Sun, 2008-03-30 at 19:04 -0700, Walter Bright wrote:
> Scott S. McCoy wrote:
> > You also could if array[5 .. -3] implied length -3.
> 
> How would I do:
> 
> 	array[5 .. foo($)]
> 
> ?

The same thing foo[$-3] is now.

Whatever the heck that is.

:-)


On Mon, 2008-03-31 at 01:55 +0200, Simen Kjaeraas wrote:
> On Mon, 31 Mar 2008 00:26:10 +0200, Scott S. McCoy <tag@cpan.org> wrote:
> 
> > You also could if array[5 .. -3] implied length -3.
> >
> > Similarly. array[-3] could imply array[array.length -3]...
> >
> > But someone suggested against that, atleast for non-compile time checking.  I would agree, for the non-literal instance that a negative integer of -5 shouldn't result in magical figuring out if the element needs to be pulled from the front or the back.  But the literal case adds expressiveness, I think.
> 
> T[int] foo;
> 
> What is foo[-3]?
> 
> And user-defined types with overloaded opIndex and opSlice. Should [-X] work differently for them?
> 
> -- Simen