Talk about collections rather than containers

[dumarchie]

In Raku parlance, a container generally refers to a scalar container.
Arrays and hashes are mutable collections that store values in scalar
containers. To avoid confusion it's better to refer to these composite
types as collections.

[JJ]

In Raku parlance, a container generally refers to a scalar container. Arrays and hashes are mutable collections that store values in scalar containers. To avoid confusion it's better to refer to these composite types as collections.

Not really. A container in Raku is generally called "variable" somewhere else; it tries to distinguish the content, a value, from what contains it, which is also an object by and of itself. In general, I would appreciate a previous issue to arrive to a consensus on this kind of things. However, I'll take a look at the PR because it's probably more straightforward than that.

[JJ]

Great clarificaton. You might want to address the nits before merging, anyhow.

[JJ]

alt: positional "argument" or "collection passed as a positional argument"

[dumarchie]

Hmm, this is a bit tricky. We have a positional argument that should do the Positional role. How about "the @collection passed as a positional argument"?

This b.t.w. illustrates why I prefer parameter name @collection instead of @a, because I don't think there's as much meaning in the phrase "the @a passed as a positional argument".

[JJ]

as a Positional argument. It's a Positional argument that's also a positional argument. There's a tongue-twister for you 😸

[JJ]

This is simply defined as

https://github.com/rakudo/rakudo/blob/db074a8bc49a0dbcdfc4ecd392c7eaadb0c078ed/src/core.c/array_operators.pm6#L26

As long as we're changing it, the best is to just use the original, as is the default policy.

[dumarchie]

In your review of PR #3973 you still agreed that it was better to use more meaningful parameter names.

I don't mind changing the parameter name if you now think that @a is better after all, because the @ sigil probably adds enough meaning. But as an aside, I think that Rakudo should not restrict the argument to Positional as non-Positional collection types may implement a shift method too. And I don't think that \a would be meaningful enough.

So should I change the parameter to @a or not?

[JJ]

The problem, again, is unambiguously making something that is really better. "Collection" is implicit in the sigil, for instance. And that's also correct, it's not positional, it's "thing-with-shift". I seem to remember I opened an issue somewhere about that, to create more atomic roles. Anyway, to the point, it's really up to you. I really appreciate the effort for improving the documentation you've put in.

[dumarchie]

I like the idea of more atomic roles. Then, for example, we could document that the "Shiftable" role has a stub

method shift(Shiftable:D:)

and change the subroutine form to something like

multi sub shift(Shiftable:D \object)

which will probably give us a more awesome error message when attempting to shift something that is not shiftable.

Maybe we could even combine such roles into more complex ones, like:

role Stacky does Pushable does Poppable {}
role Queuey does Pushable does Shiftable {}

so we can have a

class Array does Stacky does Queuey ...

showing what an Array can be used for.

[JJ]

Ditto here. It uses \a as an argument.

[dumarchie]

In this case using \a instead of \collection would really make the signature less meaningful.

[JJ]

Well, it's what it is. If we want to get really picky about it, it's \object_can_push. Which is why in the absence of a consensus, it's really the best to stick to the source. But, again, your call. We at least agree that the original \container was not a good idea.

[raiph]

Fwiw I'd love to see introduction of the word "collections" as a generic term covering lists and hashes. I've seen it used to mean this in a lot of other PLs.

A container in Raku is generally called "variable" somewhere else; it tries to distinguish the content, a value, from what contains it, which is also an object by and of itself.

That may be where we've ended up, and I may have contributed to that, but I think it's unfortunate and that it's wise to move toward using the word container strictly to mean Scalar (and perhaps Proxy too).

In general, I would appreciate a previous issue to arrive to a consensus on this kind of things.

I'm with you on the need for consensus but would say a PR like this one is a classic healthy way to get to that. By "like this" I mean one that's simple, small, done well, and with a humble attitude, all of which I think apply here.

However, I'll take a look at the PR because it's probably more straightforward than that.

Indeed. Your follow ups are notably sweet, and I thank you for your continued careful stewardship of the doc.

I love this shift. :)

[JJ]

Fwiw I'd love to see introduction of the word "collections" as a generic term covering lists and hashes. I've seen it used to mean this in a lot of other PLs.

Well... on the pure terminological side, a collection might include anything that's not "atomic". Would Junctions be collections? Hashmaps? On the low-level side, however, it breaks down to "thing-with-a-push", "thint-with-a-shift" and so on an so forth. Is an Iterable a collection? Anyway, that's something that would be long to discuss. In this PR, it's quite clear what we mean by that.

A container in Raku is generally called "variable" somewhere else; it tries to distinguish the content, a value, from what contains it, which is also an object by and of itself.

That may be where we've ended up, and I may have contributed to that, but I think it's unfortunate and that it's wise to move toward using the word container strictly to mean Scalar (and perhaps Proxy too).

Well, if I had to steer it towards something, I'd go for something "meta". A container is a meta-object, because it adds structure and metadata (roles, HOWs) to single values.

In general, I would appreciate a previous issue to arrive to a consensus on this kind of things.

I'm with you on the need for consensus but would say a PR like this one is a classic healthy way to get to that. By "like this" I mean one that's simple, small, done well, and with a humble attitude, all of which I think apply here.

As I have commented, the PR is great work. The underlying issue, however, would probably need an, er, different issue. Think that what we're discussing here will be lost when merged.

However, I'll take a look at the PR because it's probably more straightforward than that.

Indeed. Your follow ups are notably sweet, and I thank you for your continued careful stewardship of the doc.

I love this shift. :)

👍

[dumarchie]

Fwiw I'd love to see introduction of the word "collections" as a generic term covering lists and hashes. I've seen it used to mean this in a lot of other PLs.

Then we should probably rename Rakudo's array_operators.pm6 to collection_operators.pm6 (or collection_operators.rakumod). I can change the heading in the independent routines documentation from "Array manipulation" to "Collection operators" already, if we agree that is a better name.

[JJ]

Fwiw I'd love to see introduction of the word "collections" as a generic term covering lists and hashes. I've seen it used to mean this in a lot of other PLs.

Then we should probably rename Rakudo's array_operators.pm6 to collection_operators.pm6 (or collection_operators.rakumod). I can change the heading in the independent routines documentation from "Array manipulation" to "Collection operators" already, if we agree that is a better name.

Er... No renaming, please. Again, implies loss of incoming links. Creating a new one that would point to all included concepts would be OK.

[dumarchie]

Fwiw I'd love to see introduction of the word "collections" as a generic term covering lists and hashes. I've seen it used to mean this in a lot of other PLs.

Then we should probably rename Rakudo's array_operators.pm6 to collection_operators.pm6 (or collection_operators.rakumod). I can change the heading in the independent routines documentation from "Array manipulation" to "Collection operators" already, if we agree that is a better name.

Er... No renaming, please. Again, implies loss of incoming links. Creating a new one that would point to all included concepts would be OK.

I searched for "Array_manipulation" in the whole project and found nothing, so I don't think there are any links inside the project. I created the heading not so long ago so I doubt there are incoming links from other resources.

[JJ]

Fwiw I'd love to see introduction of the word "collections" as a generic term covering lists and hashes. I've seen it used to mean this in a lot of other PLs.

Then we should probably rename Rakudo's array_operators.pm6 to collection_operators.pm6 (or collection_operators.rakumod). I can change the heading in the independent routines documentation from "Array manipulation" to "Collection operators" already, if we agree that is a better name.

Er... No renaming, please. Again, implies loss of incoming links. Creating a new one that would point to all included concepts would be OK.

I searched for "Array_manipulation" in the whole project and found nothing, so I don't think there are any links inside the project. I created the heading not so long ago so I doubt there are incoming links from other resources.

The principle is still the same. Pages disappear from search engines, lose their ranking. We aren't even fond of losing fragments in URLs. There's an alternative, which I'm not fond of, because it implies ops, that's returning a redirect. Also, let me remind you we're not agreed either in what's a collection, or if we should call it that way. Please open an issue and we'll discuss terminology, and what to do about it either.

[dumarchie]

Fwiw I'd love to see introduction of the word "collections" as a generic term covering lists and hashes. I've seen it used to mean this in a lot of other PLs.

Then we should probably rename Rakudo's array_operators.pm6 to collection_operators.pm6 (or collection_operators.rakumod). I can change the heading in the independent routines documentation from "Array manipulation" to "Collection operators" already, if we agree that is a better name.

Er... No renaming, please. Again, implies loss of incoming links. Creating a new one that would point to all included concepts would be OK.

I searched for "Array_manipulation" in the whole project and found nothing, so I don't think there are any links inside the project. I created the heading not so long ago so I doubt there are incoming links from other resources.

The principle is still the same. Pages disappear from search engines, lose their ranking. We aren't even fond of losing fragments in URLs. There's an alternative, which I'm not fond of, because it implies ops, that's returning a redirect. Also, let me remind you we're not agreed either in what's a collection, or if we should call it that way. Please open an issue and we'll discuss terminology, and what to do about it either.

Okay, I'll keep that change out of this PR. Please let me know if you agree with the changes in my second commit.

[JJ]

Okay, I'll keep that change out of this PR. Please let me know if you agree with the changes in my second commit.

Like the proverbial credit card, it was already pre-approved. I really appreciate the effort you have put into accommodating my nits.

[raiph]

@JJ

Yeah, I got carried away with excitement at @dumarchie having a go, and have already inappropriately over-simplified.

Some things I think we can agree on are the goodness of the desire to improve things, and of @dumarchie's intent and writing skills, and of the need for patient discussion and nuanced thinking about the conceptual, terminological, and practical complications (don't break links!) related to what are really a fundamentally thorny and intertwined mess of conundrums.

Would Junctions be collections?

I'll mostly postpone my further commentary about the term "collections" for now. The issue is, as you've said, complicated.

A container is a meta-object, because it adds structure and metadata (roles, HOWs) to single values.

I would be quite unhappy to see us use what is already a precisely defined and scary term ("meta-object") to mean anything other than what it currently does in Raku. It's just a scarier name for a HOW object, which is exactly the same as what the term "meta-object" means in PL theory, and as used in related terms like "meta-object protocol". I get that we aren't scared to buck norms and trends among PL languages, but I don't see good things coming of making "meta-object" more ambiguous and mind-bending in Raku than it already is in Raku and other PLs.

Perhaps consistently using the specific term "Variable-value" would work? Variable is the name of the Raku type that directly corresponds at compile-time to a variable to which a value of the sort we're talking about can be bound. A Variable-value doesn't have to be so bound, but the name is suggestive of what one is dealing with. Anyhoo, just an idea.

As I have commented, the PR is great work. The underlying issue, however, would probably need an, er, different issue. Think that what we're discussing here will be lost when merged.

Yeah. I've written this comment fully aware that it's plausible that, at most, only you and/or @dumarchie will read it.

Also, no need to reply. I'm really just thinking out loud...