http://wiki.dlang.org/DIP67
Abstraction over the build-in associative array(one type of range
for containers and another type for dynamic generators).
Plese criticize.

On Tuesday, 28 October 2014 at 22:44:32 UTC, Freddy wrote:
> http://wiki.dlang.org/DIP67
> Abstraction over the build-in associative array(one type of range
> for containers and another type for dynamic generators).
> Plese criticize.

It's kind of a weird proposal to be honest. Ranges primitives are
normally things like popFront(), front, and empty. The primitives
here are methods that return other ranges.

I'd think an associative range would be one that had something
like frontKey and frontValue. Alternatively it could be anything
with a front which is a 2-element tuple  (a lot like how C++'s
associative iterators have a std::pair<KeyTy, ValueTy>
value_type) but tuples aren't in druntime so that'd be a problem.

I've always found byKey and byValue odd because you rarely want
to iterate through an associative array without having both the
key and the value on hand. Doing byKey requires you to do a
lookup to get the corresponding value which just takes up cycles
unnecessarily. It also makes multimaps, if we ever support them,
a bit problematic (that is, associative arrays which support
storing a key more than once).

Brad Anderson:

> you rarely want
> to iterate through an associative array without having both the
> key and the value on hand.

This is very false. I have tons of cases where you only iterate on values or keys. On the other hand I have suggested several times that I'd like a byPairs (that yields keys-values tuple pairs).


> Doing byKey requires you to do a
> lookup to get the corresponding value which just takes up cycles
> unnecessarily.

Usually people use a "AA.byKey.zip(AA.byValue)" that is not reliable.

Bye,
bearophile

On Wednesday, 29 October 2014 at 06:59:09 UTC, bearophile wrote:
> This is very false. I have tons of cases where you only iterate on values or keys. On the other hand I have suggested several times that I'd like a byPairs (that yields keys-values tuple pairs).
>

It happens to me too but it's very much a minority of uses. Having sets as well as maps would help replace some of these cases. Not all, of course.

>
>> Doing byKey requires you to do a
>> lookup to get the corresponding value which just takes up cycles
>> unnecessarily.
>
> Usually people use a "AA.byKey.zip(AA.byValue)" that is not reliable.

Better than doing key lookups on every iteration but awfully ugly and should be unnecessary. byPairs sounds good.

On Wed, Oct 29, 2014 at 05:23:07PM +0000, Brad Anderson via Digitalmars-d wrote:
> On Wednesday, 29 October 2014 at 06:59:09 UTC, bearophile wrote:
> >This is very false. I have tons of cases where you only iterate on values or keys. On the other hand I have suggested several times that I'd like a byPairs (that yields keys-values tuple pairs).
> >
> 
> It happens to me too but it's very much a minority of uses. Having sets as well as maps would help replace some of these cases. Not all, of course.
> 
> >
> >>Doing byKey requires you to do a lookup to get the corresponding value which just takes up cycles unnecessarily.
> >
> >Usually people use a "AA.byKey.zip(AA.byValue)" that is not reliable.
> 
> Better than doing key lookups on every iteration but awfully ugly and should be unnecessary. byPairs sounds good.

I've submitted a PR for byPair before, but it was roadblocked by the fact that people demand that it return std.typecons.Tuple, yet we're not allowed to import Phobos in druntime. Other than this IMO nitpicky issue, the code was already all ready to go many moons ago.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL

On Wednesday, 29 October 2014 at 17:36:41 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Oct 29, 2014 at 05:23:07PM +0000, Brad Anderson via Digitalmars-d wrote:
>> On Wednesday, 29 October 2014 at 06:59:09 UTC, bearophile wrote:
>> >This is very false. I have tons of cases where you only iterate on
>> >values or keys. On the other hand I have suggested several times that
>> >I'd like a byPairs (that yields keys-values tuple pairs).
>> >
>> 
>> It happens to me too but it's very much a minority of uses. Having
>> sets as well as maps would help replace some of these cases. Not all,
>> of course.
>> 
>> >
>> >>Doing byKey requires you to do a lookup to get the corresponding
>> >>value which just takes up cycles unnecessarily.
>> >
>> >Usually people use a "AA.byKey.zip(AA.byValue)" that is not reliable.
>> 
>> Better than doing key lookups on every iteration but awfully ugly and
>> should be unnecessary. byPairs sounds good.
>
> I've submitted a PR for byPair before, but it was roadblocked by the
> fact that people demand that it return std.typecons.Tuple, yet we're not
> allowed to import Phobos in druntime. Other than this IMO nitpicky
> issue, the code was already all ready to go many moons ago.
>
>
> T

Can byPair be implemented in phobos, or does it need to access private/package stuff in druntime?

On Wednesday, 29 October 2014 at 18:04:30 UTC, John Colvin wrote:
> On Wednesday, 29 October 2014 at 17:36:41 UTC, H. S. Teoh via Digitalmars-d wrote:
>> On Wed, Oct 29, 2014 at 05:23:07PM +0000, Brad Anderson via Digitalmars-d wrote:
>>> On Wednesday, 29 October 2014 at 06:59:09 UTC, bearophile wrote:
>>> >This is very false. I have tons of cases where you only iterate on
>>> >values or keys. On the other hand I have suggested several times that
>>> >I'd like a byPairs (that yields keys-values tuple pairs).
>>> >
>>> 
>>> It happens to me too but it's very much a minority of uses. Having
>>> sets as well as maps would help replace some of these cases. Not all,
>>> of course.
>>> 
>>> >
>>> >>Doing byKey requires you to do a lookup to get the corresponding
>>> >>value which just takes up cycles unnecessarily.
>>> >
>>> >Usually people use a "AA.byKey.zip(AA.byValue)" that is not reliable.
>>> 
>>> Better than doing key lookups on every iteration but awfully ugly and
>>> should be unnecessary. byPairs sounds good.
>>
>> I've submitted a PR for byPair before, but it was roadblocked by the
>> fact that people demand that it return std.typecons.Tuple, yet we're not
>> allowed to import Phobos in druntime. Other than this IMO nitpicky
>> issue, the code was already all ready to go many moons ago.
>>
>>
>> T
>
> Can byPair be implemented in phobos, or does it need to access private/package stuff in druntime?

I don't see why not,It could be put into std.range and accept a
generic associative range(which includes the build-in associative
array).

On Wednesday, 29 October 2014 at 18:40:51 UTC, Freddy wrote:
> On Wednesday, 29 October 2014 at 18:04:30 UTC, John Colvin wrote:
>> On Wednesday, 29 October 2014 at 17:36:41 UTC, H. S. Teoh via Digitalmars-d wrote:
>>> On Wed, Oct 29, 2014 at 05:23:07PM +0000, Brad Anderson via Digitalmars-d wrote:
>>>> On Wednesday, 29 October 2014 at 06:59:09 UTC, bearophile wrote:
>>>> >This is very false. I have tons of cases where you only iterate on
>>>> >values or keys. On the other hand I have suggested several times that
>>>> >I'd like a byPairs (that yields keys-values tuple pairs).
>>>> >
>>>> 
>>>> It happens to me too but it's very much a minority of uses. Having
>>>> sets as well as maps would help replace some of these cases. Not all,
>>>> of course.
>>>> 
>>>> >
>>>> >>Doing byKey requires you to do a lookup to get the corresponding
>>>> >>value which just takes up cycles unnecessarily.
>>>> >
>>>> >Usually people use a "AA.byKey.zip(AA.byValue)" that is not reliable.
>>>> 
>>>> Better than doing key lookups on every iteration but awfully ugly and
>>>> should be unnecessary. byPairs sounds good.
>>>
>>> I've submitted a PR for byPair before, but it was roadblocked by the
>>> fact that people demand that it return std.typecons.Tuple, yet we're not
>>> allowed to import Phobos in druntime. Other than this IMO nitpicky
>>> issue, the code was already all ready to go many moons ago.
>>>
>>>
>>> T
>>
>> Can byPair be implemented in phobos, or does it need to access private/package stuff in druntime?
>
> I don't see why not,It could be put into std.range and accept a
> generic associative range(which includes the build-in associative
> array).

or std.array.

On Wed, Oct 29, 2014 at 06:40:50PM +0000, Freddy via Digitalmars-d wrote:
> On Wednesday, 29 October 2014 at 18:04:30 UTC, John Colvin wrote:
> >On Wednesday, 29 October 2014 at 17:36:41 UTC, H. S. Teoh via Digitalmars-d wrote:
[...]
> >>I've submitted a PR for byPair before, but it was roadblocked by the fact that people demand that it return std.typecons.Tuple, yet we're not allowed to import Phobos in druntime. Other than this IMO nitpicky issue, the code was already all ready to go many moons ago.
> >>
> >>
> >>T
> >
> >Can byPair be implemented in phobos, or does it need to access private/package stuff in druntime?
> 
> I don't see why not,It could be put into std.range and accept a generic associative range(which includes the build-in associative array).

And how would it be implemented in a way that is stable across AA implementations?


--T

H. S. Teoh:

> And how would it be implemented in a way that is stable across AA implementations?

Adding tuples as first-class entities in the language, and deprecating std.typecons.Tuple :-)

Bye,
bearophile