Is there any chance we could amend the slice notation such that

  ar[2 .. ]   would be interpreted as ar[2 .. ar.length]
  ar[ .. 10]   would be interpreted as ar[0 .. 10]
  ar[ .. ]   would be interpreted as ar[0 .. ar.length]

(The last one would be pretty useless, of course).

It's just syntactic sugar, I grant you, but it would be nice nonetheless. If there's no serious parsing issue, can we add this to the list of nice features.

Of course, the form t[1 .. ] might cause some problems with the overloaded slice operator for UDTs, ...

"Matthew Wilson" <matthew@stlsoft.org> escreveu na mensagem news:bm836b$2pr4$1@digitaldaemon.com...
> Is there any chance we could amend the slice notation such that
>
>   ar[2 .. ]   would be interpreted as ar[2 .. ar.length]
>   ar[ .. 10]   would be interpreted as ar[0 .. 10]
>   ar[ .. ]   would be interpreted as ar[0 .. ar.length]
>
> (The last one would be pretty useless, of course).
>
> It's just syntactic sugar, I grant you, but it would be nice nonetheless.
If
> there's no serious parsing issue, can we add this to the list of nice features.
>
> Of course, the form t[1 .. ] might cause some problems with the overloaded slice operator for UDTs, ...

In Haskell they have a Enum type-class and the .. operator is a syntatic sugar for certain operations, so they can write:


[1 .. 10]   ->    enumFromTo 1 10
[1 .. ]   ->    enumFrom 1
[1, 3 .. 9]   ->    enumFromThenTo 1 3 9
[1, 3 .. ]   ->    enumFromThen 1 3


The "then" part is used to define steps. Anyway I think in D we could do similar things and have the .. operator create a templated Range construct:


1 .. 10    ->   new instance TRange(int).FromTo(1,10)
1 ..       ->   new instance TRange(int).From(1)
  .. 10    ->   new instance TRange(int).To(10)


and the array semantics would use this range definitions to know which indices it should iterate. So there are three possibilities:


FromTo  -> use the range bounds
From    -> use the range "from" bound and the array.length as upper bound
To      -> use the range "to" bound and 0 as lower bound


The nice thing about this notation is that someone can create a UDT that uses this notation, if it provides a pair of "successor"/"predecessor" methods (or succ/pred if you want to be economic ;) for the UDT.

struct MyValue {
    int x;
    MyValue succ() {
        return {x + 1};
    }
    MyValue pred() {
        return {x - 1};
    }
}

MyValue a = {1};
MyValue b = {2};

for(MyValue c; a .. b) {
    printf("%d\r\n", c.x);
}


The possibilities are endless, but I digress...

Best regards,
Daniel Yokomiso.

"I'll take the red pill, no, blue. AAAHHHHHHHHHHHHHHHH........"
 - The Matrix meets Monty Python's Holy Grail.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 8/10/2003

Sounds interesting. I think this would be worth exploring, when Walter has the time.

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bm9vh6$29u9$1@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> escreveu na mensagem news:bm836b$2pr4$1@digitaldaemon.com...
> > Is there any chance we could amend the slice notation such that
> >
> >   ar[2 .. ]   would be interpreted as ar[2 .. ar.length]
> >   ar[ .. 10]   would be interpreted as ar[0 .. 10]
> >   ar[ .. ]   would be interpreted as ar[0 .. ar.length]
> >
> > (The last one would be pretty useless, of course).
> >
> > It's just syntactic sugar, I grant you, but it would be nice
nonetheless.
> If
> > there's no serious parsing issue, can we add this to the list of nice features.
> >
> > Of course, the form t[1 .. ] might cause some problems with the
overloaded
> > slice operator for UDTs, ...
>
> In Haskell they have a Enum type-class and the .. operator is a syntatic sugar for certain operations, so they can write:
>
>
> [1 .. 10]   ->    enumFromTo 1 10
> [1 .. ]   ->    enumFrom 1
> [1, 3 .. 9]   ->    enumFromThenTo 1 3 9
> [1, 3 .. ]   ->    enumFromThen 1 3
>
>
> The "then" part is used to define steps. Anyway I think in D we could do similar things and have the .. operator create a templated Range
construct:
>
>
> 1 .. 10    ->   new instance TRange(int).FromTo(1,10)
> 1 ..       ->   new instance TRange(int).From(1)
>   .. 10    ->   new instance TRange(int).To(10)
>
>
> and the array semantics would use this range definitions to know which indices it should iterate. So there are three possibilities:
>
>
> FromTo  -> use the range bounds
> From    -> use the range "from" bound and the array.length as upper bound
> To      -> use the range "to" bound and 0 as lower bound
>
>
> The nice thing about this notation is that someone can create a UDT that uses this notation, if it provides a pair of "successor"/"predecessor" methods (or succ/pred if you want to be economic ;) for the UDT.
>
> struct MyValue {
>     int x;
>     MyValue succ() {
>         return {x + 1};
>     }
>     MyValue pred() {
>         return {x - 1};
>     }
> }
>
> MyValue a = {1};
> MyValue b = {2};
>
> for(MyValue c; a .. b) {
>     printf("%d\r\n", c.x);
> }
>
>
> The possibilities are endless, but I digress...
>
> Best regards,
> Daniel Yokomiso.
>
> "I'll take the red pill, no, blue. AAAHHHHHHHHHHHHHHHH........"
>  - The Matrix meets Monty Python's Holy Grail.
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.524 / Virus Database: 321 - Release Date: 8/10/2003
>
>

MATLAB uses the keyword "end" for this. Some example translated to D array
syntax:
 ar[2 .. end] = 0;
 ar[2 .. end-1] = 0;
 ar[end+1] = 0;

The last example grows the array by one element and sets it to zero.

Since slicing in MATLAB is inclusive "end" would evaluate to ar.length+1.

-Ben

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm836b$2pr4$1@digitaldaemon.com...
> Is there any chance we could amend the slice notation such that
>
>   ar[2 .. ]   would be interpreted as ar[2 .. ar.length]
>   ar[ .. 10]   would be interpreted as ar[0 .. 10]
>   ar[ .. ]   would be interpreted as ar[0 .. ar.length]
>
> (The last one would be pretty useless, of course).
>
> It's just syntactic sugar, I grant you, but it would be nice nonetheless.
If
> there's no serious parsing issue, can we add this to the list of nice features.
>
> Of course, the form t[1 .. ] might cause some problems with the overloaded slice operator for UDTs, ...
>
>
>
>

"Matthew Wilson" <matthew@stlsoft.org> wrote in message
news:bm836b$2pr4$1@digitaldaemon.com...
| Is there any chance we could amend the slice notation such that
|
|   ar[2 .. ]   would be interpreted as ar[2 .. ar.length]
|   ar[ .. 10]   would be interpreted as ar[0 .. 10]
|   ar[ .. ]   would be interpreted as ar[0 .. ar.length]
|
| (The last one would be pretty useless, of course).
|
| It's just syntactic sugar, I grant you, but it would be nice nonetheless.
If
| there's no serious parsing issue, can we add this to the list of nice
| features.
|
| Of course, the form t[1 .. ] might cause some problems with the overloaded
| slice operator for UDTs, ...
|
|
|
|

I second this.

————————————————————————— Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.525 / Virus Database: 322 - Release Date: 2003-10-09