Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
June 02, 2012 opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Hi, I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of the array rather than the length (and perhaps rename opDollar to opEnd to reflect this interpretation), so that collection[someIndex .. $] would consistently refer to a slice from someIndex to the end of the collection (of course the keys must have a defined ordering for it to make sense). I'm just thinking, if we want to generalize slices for those cases, shouldn't we have a symmetrical operator for the first element of the array? Since the $ sign was evidently chosen to parallel the regexp syntax, why don't we add ^ to refer to the first element? This way, collection[^ .. $] would slice the entire collection, just like collection[]. Until now, ^ is only used as a binary operator, so this addition shouldn't lead to ambiguous syntax. It surely wouldn't be used as often as the opDollar, so I understand if you oppose the idea, but it would at least make the language a little more "complete". |
June 04, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dario Schiavon | On Sat, 02 Jun 2012 07:49:16 -0400, Dario Schiavon <dario.schiavon@gmail.com> wrote: > Hi, > > I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of the array rather than the length (and perhaps rename opDollar to opEnd to reflect this interpretation), so that collection[someIndex .. $] would consistently refer to a slice from someIndex to the end of the collection (of course the keys must have a defined ordering for it to make sense). > > I'm just thinking, if we want to generalize slices for those cases, shouldn't we have a symmetrical operator for the first element of the array? Since the $ sign was evidently chosen to parallel the regexp syntax, why don't we add ^ to refer to the first element? This way, collection[^ .. $] would slice the entire collection, just like collection[]. > > Until now, ^ is only used as a binary operator, so this addition shouldn't lead to ambiguous syntax. It surely wouldn't be used as often as the opDollar, so I understand if you oppose the idea, but it would at least make the language a little more "complete". I suggested this, and it was shot down rather pointedly by Walter (with not very convincing arguments I might add). Probably not much chance of success. http://forum.dlang.org/post/op.vco5zwhreav7ka@localhost.localdomain -Steve |
June 04, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Monday, 4 June 2012 at 19:55:49 UTC, Steven Schveighoffer wrote:
> On Sat, 02 Jun 2012 07:49:16 -0400, Dario Schiavon <dario.schiavon@gmail.com> wrote:
>
>> Hi,
>>
>> I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of the array rather than the length (and perhaps rename opDollar to opEnd to reflect this interpretation), so that collection[someIndex .. $] would consistently refer to a slice from someIndex to the end of the collection (of course the keys must have a defined ordering for it to make sense).
>>
>> I'm just thinking, if we want to generalize slices for those cases, shouldn't we have a symmetrical operator for the first element of the array? Since the $ sign was evidently chosen to parallel the regexp syntax, why don't we add ^ to refer to the first element? This way, collection[^ .. $] would slice the entire collection, just like collection[].
>>
>> Until now, ^ is only used as a binary operator, so this addition shouldn't lead to ambiguous syntax. It surely wouldn't be used as often as the opDollar, so I understand if you oppose the idea, but it would at least make the language a little more "complete".
>
> I suggested this, and it was shot down rather pointedly by Walter (with not very convincing arguments I might add). Probably not much chance of success.
>
> http://forum.dlang.org/post/op.vco5zwhreav7ka@localhost.localdomain
>
> -Steve
Can you use "null"?
|
June 04, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mehrdad | On Mon, 04 Jun 2012 16:13:49 -0400, Mehrdad <wfunction@hotmail.com> wrote:
> On Monday, 4 June 2012 at 19:55:49 UTC, Steven Schveighoffer wrote:
>> On Sat, 02 Jun 2012 07:49:16 -0400, Dario Schiavon <dario.schiavon@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of the array rather than the length (and perhaps rename opDollar to opEnd to reflect this interpretation), so that collection[someIndex .. $] would consistently refer to a slice from someIndex to the end of the collection (of course the keys must have a defined ordering for it to make sense).
>>>
>>> I'm just thinking, if we want to generalize slices for those cases, shouldn't we have a symmetrical operator for the first element of the array? Since the $ sign was evidently chosen to parallel the regexp syntax, why don't we add ^ to refer to the first element? This way, collection[^ .. $] would slice the entire collection, just like collection[].
>>>
>>> Until now, ^ is only used as a binary operator, so this addition shouldn't lead to ambiguous syntax. It surely wouldn't be used as often as the opDollar, so I understand if you oppose the idea, but it would at least make the language a little more "complete".
>>
>> I suggested this, and it was shot down rather pointedly by Walter (with not very convincing arguments I might add). Probably not much chance of success.
>>
>> http://forum.dlang.org/post/op.vco5zwhreav7ka@localhost.localdomain
>
> Can you use "null"?
Hm... now that null has its own type, I likely could.
I suppose that would map properly to 0.
-Steve
|
June 04, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Monday, 4 June 2012 at 20:26:52 UTC, Steven Schveighoffer wrote:
> On Mon, 04 Jun 2012 16:13:49 -0400, Mehrdad
>> Can you use "null"?
>
> Hm... now that null has its own type, I likely could.
>
> I suppose that would map properly to 0.
>
> -Steve
But if the key is non-nullable this might be confusing, or even not possible.
|
June 04, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Roman D. Boiko | On Mon, 04 Jun 2012 16:32:55 -0400, Roman D. Boiko <rb@d-coding.com> wrote:
> On Monday, 4 June 2012 at 20:26:52 UTC, Steven Schveighoffer wrote:
>> On Mon, 04 Jun 2012 16:13:49 -0400, Mehrdad
>>> Can you use "null"?
>>
>> Hm... now that null has its own type, I likely could.
>>
>> I suppose that would map properly to 0.
>>
>> -Steve
> But if the key is non-nullable this might be confusing, or even not possible.
Well, you could say that null keys are not allowed. But then it makes no sense for null not to work in other places.
I really am not sure this works well, I think it would be too confusing.
map[null] = 5; // set the first element to 5?
map[null..4] = 6; // set all the elements with keys before 4 to 6
map!keyType k = null;
map[k..$]; // likely an error.
I really actually think I like using map.begin better than null...
-Steve
|
June 04, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dario Schiavon | On Saturday, 2 June 2012 at 11:49:17 UTC, Dario Schiavon wrote:
> Hi,
>
> I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of the array rather than the length (and perhaps rename opDollar to opEnd to reflect this interpretation), so that collection[someIndex .. $] would consistently refer to a slice from someIndex to the end of the collection (of course the keys must have a defined ordering for it to make sense).
>
> I'm just thinking, if we want to generalize slices for those cases, shouldn't we have a symmetrical operator for the first element of the array? Since the $ sign was evidently chosen to parallel the regexp syntax, why don't we add ^ to refer to the first element? This way, collection[^ .. $] would slice the entire collection, just like collection[].
>
> Until now, ^ is only used as a binary operator, so this addition shouldn't lead to ambiguous syntax. It surely wouldn't be used as often as the opDollar, so I understand if you oppose the idea, but it would at least make the language a little more "complete".
The problem I see with this, it would be a larger burden when writing generic code. Libraries would have to be written to compensate for those containers. I'd prefer that all containers are simply zero-based, unless there's a need for negative indices (i.e. pointers). I think random-access ranges may be intended to be zero-based as well.
|
June 06, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Xinok | On Mon, 04 Jun 2012 17:23:57 -0400, Xinok <xinok@live.com> wrote:
> On Saturday, 2 June 2012 at 11:49:17 UTC, Dario Schiavon wrote:
>> Hi,
>>
>> I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of the array rather than the length (and perhaps rename opDollar to opEnd to reflect this interpretation), so that collection[someIndex .. $] would consistently refer to a slice from someIndex to the end of the collection (of course the keys must have a defined ordering for it to make sense).
>>
>> I'm just thinking, if we want to generalize slices for those cases, shouldn't we have a symmetrical operator for the first element of the array? Since the $ sign was evidently chosen to parallel the regexp syntax, why don't we add ^ to refer to the first element? This way, collection[^ .. $] would slice the entire collection, just like collection[].
>>
>> Until now, ^ is only used as a binary operator, so this addition shouldn't lead to ambiguous syntax. It surely wouldn't be used as often as the opDollar, so I understand if you oppose the idea, but it would at least make the language a little more "complete".
>
> The problem I see with this, it would be a larger burden when writing generic code. Libraries would have to be written to compensate for those containers. I'd prefer that all containers are simply zero-based, unless there's a need for negative indices (i.e. pointers). I think random-access ranges may be intended to be zero-based as well.
caret would have to map to 0 for slices and containers who already have a notion of first element being zero.
This would not be hard. And in fact, would make generic code *easier*. Right now, you have to special case containers who support slicing but do not start on 0. The only one I know of at this point is Red Black Tree.
-Steve
|
June 06, 2012 Re: opCaret to complement opDollar when specifying slices | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wed, Jun 6, 2012 at 3:53 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote: > On Mon, 04 Jun 2012 17:23:57 -0400, Xinok <xinok@live.com> wrote: > >> On Saturday, 2 June 2012 at 11:49:17 UTC, Dario Schiavon wrote: >>> >>> Hi, >>> >>> I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of the array rather than the length (and perhaps rename opDollar to opEnd to reflect this interpretation), so that collection[someIndex .. $] would consistently refer to a slice from someIndex to the end of the collection (of course the keys must have a defined ordering for it to make sense). >>> >>> I'm just thinking, if we want to generalize slices for those cases, shouldn't we have a symmetrical operator for the first element of the array? Since the $ sign was evidently chosen to parallel the regexp syntax, why don't we add ^ to refer to the first element? This way, collection[^ .. $] would slice the entire collection, just like collection[]. >>> >>> Until now, ^ is only used as a binary operator, so this addition >>> shouldn't lead to ambiguous syntax. It surely wouldn't be used as often as >>> the opDollar, so I understand if you oppose the idea, but it would at least >>> make the language a little more "complete". >> >> >> The problem I see with this, it would be a larger burden when writing generic code. Libraries would have to be written to compensate for those containers. I'd prefer that all containers are simply zero-based, unless there's a need for negative indices (i.e. pointers). I think random-access ranges may be intended to be zero-based as well. > > > caret would have to map to 0 for slices and containers who already have a notion of first element being zero. > > This would not be hard. And in fact, would make generic code *easier*. Right now, you have to special case containers who support slicing but do not start on 0. The only one I know of at this point is Red Black Tree. > > -Steve Circular buffers essentially start nowhere and end nowhere. Having a caret operator for slices would ease the manipulation of circular buffers and would allow one to "rotate" the buffer, essentially changing the cared and dollar value. -- Bye, Gor Gyolchanyan. |
Copyright © 1999-2021 by the D Language Foundation