Difference between methods List-list-cache

[2colours]

Hi,

this topic seemed like something that isn't an issue per se but probably is worth clarifying.

There is a method List defined on a couple of types: https://docs.raku.org/routine/List. The behavior is not described that well but the core idea seems to be clear: this is a conversion method.

There is another method list defined on a good number of types: https://docs.raku.org/routine/list. My main question is: what is this, conceptually? When is it invoked? What purpose does it serve? It seems to be invoked at least under some circumstances when one uses @ as a sigil, that seems to be one use. By the way, why is the name so similar to .List? Should this be read like the verb "to list"?

I have also seen cache used a couple of times and apparently that's also defined on Any: https://docs.raku.org/routine/cache. This is apparently different from what list does for the PositionalBindFailover but then again I feel uncertain what .list does in that case.

[raiph]

• .List Coerces to a List. If the invocant is already a List, the method call is a no op.

• .list Coerces to a list. If the invocant is already a list, the method call is a no op. A List is a list, but a list is a more general concept and so a list may not be (often isn't) a List. Similarly, coercing to a list does not necessarily mean (often does not mean) coercing to a List, but instead just a list.

• .cache Ensures a list is cached.

---

By convention, almost all built in types have TcLc ("BumpyCase") names, and those that do have a corresponding method and sub of the same name that is an explicit type coercion from any other type to the named built in type. Thus .List. (Conversely, built in types that are all lowercase are native types (int, str, etc) do not have explicit coercion methods/subs. One can only implicitly coerce from a suitable source type by writing a parameter with a native type and passing a suitable argument for coercing to that native type. For example, my Int $foo = 42; sub bar (int \baz) {}; bar $foo;.)

To elaborate on what I mean by a "list" I'll start with what I wrote in my answer to an SO asking what a "list" was in Raku:

a "list" ... is the notion of one thing, then another, then another.

Notably, a "list" doesn't refer to an unordered list of anything. It's definitely ordered. A hash is not a list. But a "list" is a more general notion than than a List, more general even than a Positional. Types like Seqs and Captures are also lists.

A "cache" in the context of .cache is just the very general notion of a cache being created and kept corresponding to the values in, or generated for, a list.

[2colours]

Thank you for the overview. I think there are some things I still need to digest.

In contrast an Array element is always rebindable (I'm ignoring the NYI ::=), and is only not assignable when it's bound to an immutable value.

This was also very interesting, although not strictly related to the question here.

So if I understand right, Seq would be a "list". Then why isn't .list on a Seq a no-op, as instead a List instance is returned?

Actually, is there any "list" that .lists to anything that isn't a List (descendants like Array included)?

Also, I saw it in the current Rakudo Actions.nqp in use that sigils @ and % basically enforce calling .list and .hash on the given data respectively. For .hash, this is rather well-recorded in the documentation but that's how .list also works, having a very visible effect in a Rakudo issue. What would this mean in the context of non-Positionals and non-Associatives respectively?

[niner]

FWIW I introduced the List method during the GLR, mostly as an internal tool because many methods use arrays internally to collect results and I didn't want to leak this implementation detail. So I added List as a fast way to convert that Array to a less powerful List. The irony being that it actually didn't see much use because you can't just re-use an Array's storage for a List object if you don't know that the array is going to be thrown away anyway. Anyway any inconsistencies and confusion is caused by this. It's not part of some great design.