Add resolution document for #135 (Add Dict/Tuple to the core)

[vrurg]

Open the way to eventually introduce ValueList and ValueMap into Raku.

[vrurg]

The resolution states that the types are to be introduced in 6.e. But technically there is no problem to add them into 6.c. And the only reason not to do so is minimization of backward-incompatible changes. Yet, as long as no 3rd party code is using these names, I foresee no breakages.

That's all about "cons". On the "pros" side would be code which is not ready to migrate to 6.e could already benefit of simplification of some algorithms.

[JJ]

👍

[lizmat]

I know this is a bit like bikeshedding, but there's already a Tuple module in the ecosystem. Why not call them Tuple and TupleMap ?

What I miss here, is mention of some of the other list like things, like <a b c>, which I think should also become ValueLists.

I guess my @l is ValueList = 1,2,3 and my %m is ValueMap = :42a, :666b should maybe also be mentioned?

Also, I think we need some generic way to specify ValueList and ValueMap literals.

[vrurg]

@lizmat

I know this is a bit like bikeshedding, but there's already a Tuple module in the ecosystem. Why not call them Tuple and TupleMap ?

I was following the discussion in #135 and, in particular, @jnthn comment on IRC. Then there was your statement: "I do not care what they are called". Put together, both resulted in the discussion ending up with Value* names.

FWIW, I like Dict and Tuple more, but can't disagree with the fact that the growing zoo of type names makes it harder to navigate.

What I miss here, is mention of some of the other list like things, like <a b c>, which I think should also become ValueLists.

I don't think it makes sense to go that deep in this document. It's current purpose is to let the types to be eventually included into the core.

But otherwise I'd rather agree that <a b c> should be a ValueList. Contrary, (1, 2) must remain a List because of ($a, 1, 2). Though the specs might certainly limit us to 6.e only with respect to changes like this one.

I guess my @l is ValueList = 1,2,3 and my %m is ValueMap = :42a, :666b should maybe also be mentioned?

It's up to the specs. They define the language, not documents in problem solving. What we decide in this repo under the language tag usually must be reflected in specs.

Also, I think we need some generic way to specify ValueList and ValueMap literals.

This is another big problem. We still don't have a generic way to create a Map. Because of this a correct EXPORT sub must still use Map.new() for its return value.

So, I'd put it this way: if we want different names, we'd better have this agreed upon in #135 and then reflected here. I wouldn't push then and turn this PR into a draft. Otherwise we can have it accepted and decide on implementation details in a separate issue which should result in new spectests.

[lizmat]

@vrurg fair enough, I should have re-read the original discussion before answering. ValueList and ValueMap it is. I will create them as modules in the ecosystem.

[lizmat]

ValueList has entered the ecosystem, and Tuple is now a subclass of ValueList.

[lizmat]

ValueMap has entered the ecosystem.

[lizmat]

Please look at the functionality offered by ValueList and ValueMap. Does it match your expectations?

There are a few points I would like to make about this implementation (and potentially any implementation of this).

1. ValueList is not a subclass of List, but it is Iterable and Positional.
2. ValueMap is a subclass of Map, because much of the needed infrastructure was already in the core (specifically the :DECONT parameter on Map.STORE).
3. Because ValueList and ValueMap are Iterable, you could NOT use them as keys in a QuantHash, because they would get iterated over. This is circumvented by having ValueList.new and ValueMap.new actually return a container, as containers inhibit iterating over Iterables. This however feels very hacky and problematic in the long run. Preferable would maybe be to mark the ValueList and ValueMap classes as nodal (or whatever we would call this), inhibiting iterating over them in a single arg context. But I guess this point could actually be big enough for a problem solving issue of its own.

[vrurg]

Please look at the functionality offered by ValueList and ValueMap. Does it match your expectations?

Can't promise you this for today. Would just base my opinion on your notes.

1. ValueList is not a subclass of List, but it is Iterable and Positional.

Bad idea. Both must be subclasses of their relevant counterparts.

BTW, from the design point of view, I'd rather expect Array not to be a List, but be a positional due to totally different approach of managing its content.

I was planning to add similar :DECONT behavior to List, but it was never a priority task. Would be happy if somebody is able to pick it up and have done. Otherwise merging of ValueList must wait.

3. Because ValueList and ValueMap are Iterable, you could NOT use them as keys in a QuantHash,

This is about the same problem as we currently have with lists. Yet, manual containerization does the trick: my @a is List = <a b c>; say set($@a). What's confusing me is (and haven't been working with quanthashes for a while): why set(@a,) doesn't work as expected? I mean, why does it forcibly flattens? Is it intentional or an overlook?

[codesections]

I'm a bit confused on one point: How do ValueList and ValueMap (or whatever we end up calling them) interact with the immutable data structures from my WIP grant? Being immutable will inherently make those data structures also be value types. I'm writing those types as a library currently, but (as discussed in the grant proposal) with the hope that they'll make it into core at some point – and I've been hopping that they'll be tested/stable enough by 6.e.

So is the idea that we'd have two of each value type in core (eventually)? Or that this would be an alternative to the persistent types I'm working on and only one would go in core? Or is the plan that this would be a first pass at value types and would be "upgraded" to persistent types once my grant types are battle-tested enough?

[vrurg]

@codesections This is something I overlooked. Not totally, but haven't considered sufficiently thorough. My mistake was that I messed up the backing algorithm (as I remembered it) with data structures themselves in my mind.

Anyway, at the moment I think we would need both. Value* are simplistic and as such are good for simple base tasks. List and ValueList are still going to be faster on accessing elements, than ListHat. Same would likely apply to Map/ValueMap vs. MapHat.

My preliminary view is such that *Hat would rather be targeting concurrent applications; especially those where data modifications happen. Whereas the basic types are more for lower-level cases of static data.

The other question is that when it comes to adoption of your grant, we should, perhaps, consider different naming scheme.

[lizmat]

FWIW, thinking about this more and more, I think we need to re-consider the entire stack at some point. If not for 6.e, then for 6.f. Whatever the name is. We've learned a lot about all of this, and what people expect from Raku at this point.

I'm seriously thinking about just closing the original issue.

[vrurg]

@lizmat It makes two of us. It's a scary kind of task, so you were the first to say it out loud. :)

In the meantime, changing the hierarchy doesn't change the fact that positional and associative value types has their use and are needed. Re-considering the stack wouldn't make them gone.

Neither it would change the fact they're basically are special cases of more generic List and Map. I.e., deconting versions are easily built atop of container-preserving ones, whereas the opposite is far more tricky.

[lizmat]

Since I have closed the issue, I suggest we close this PR as well.

[vrurg]

Ok. I disagree, but hope we'd have it resolved in another round.