Function return types should also tell about the used assignment/container

[2colours]

Hello, this started bugging me lately... Instead of references, Raku has containers and the distinction between assignment and binding. This allows us to do assignments on data returned from a function and other powerful stuff. The problem is, it's not really recorded how certain functions return data - not even for built-in functions.

To illustrate the problem, let me show you two different built-in functions (methods, in this case).

my @asd = 1, 4, 234, 23, 1, 88, 2, 49;
@asd.batch(2)[0;0] =:= @asd[0]; # True

It seems that batch uses binding on the items of a list. It could be further tested that this is the case, it really seems to me that it does. On the other hand:

@asd[2] == @asd.categorize(* % 3){0}[0]; #True
@asd[2] =:= @asd.categorize(* % 3){0}[0]; #False
@asd.categorize(* % 3){0}[0].VAR.WHAT; #(Scalar)

We can conclude that categorize copies - one can assign values to items returned (they have a Scalar container) but they won't affect the original elements.

The thing is... as much as I think this is important information, I don't know how this should be presented. Maybe there is no better solution than to describe it textually. I can think of 3 possible cases regarding the data: a) a container is bound to input data b) a container is freshly created c) there is no container returned, only a crude value.

[lizmat]

FWIW, whether binding or assignment is used in built-in functions, has usually been a case of historical development, and changing insights / experience.

I think it would make sense to look at them (again) and decide which behaviour should be followed (and documented).

[Kaiepi]

Return types have a unique grammar, despite being considered an ordinary parameter in more pure FP-ish languages. Would it be possible for them to become a parameter in their own right to check what sort of container the return value has and predeclare output variables? They could differ in the sense that a redeclaration is an assertion of equality to said argument (outer/dynamic?) + optional dogpile of checks.

[Kaiepi]

If we can afford to be wishy-washy about symbols in the signature, maybe we'd get:

role Monad[::A] {
    method bind(&f:(A --> ::?ROLE ::B) --> B) { ... }
    method then(::?ROLE ::M \m --> M) { self.bind: -> \ { m } }
    method pure(A --> ::?CLASS) { ... }
}

In which a type capture marks an input for instantiation.

[raiph]

Hi @Kaiepi

Is self.bind: -> \ { m } missing something after the \ or is it pseudo-code? (Is that what you meant by "wishy-washy"?)

Have you looked at what Larry said about return types in both the design docs and on IRC?

[Kaiepi]

Is self.bind: -> \ { m } missing something after the \ or is it pseudo-code? (Is that what you meant by "wishy-washy"?)

\ is an anonymous term. I mean wishy-washy by B being captured within the context of the subsignature, but being used outside of it anyway. I figure if checks can be performed on a value on the way in, there should be a way to do so on the way out as well, particularly given new-disp work.

Have you looked at what Larry said about return types in both the design docs and on IRC?

I don't find anything specific about how the 'return type' should behave on IRC or in the design docs. It is referred to as such in the design docs, and is stated to be kept separately from the parameter list within a Code, which is Signature'd. This could translate to a list of "in" parameters and an "out" parameter. There is a prefix form of the return type given an anon which, if it works given any scope declarator, could help avoid the "wishy-washy" declaration ordering I was talking about:

#`[has is implied ordinarily.]
has ::?ROLE ::B method bind(&f:(A --> B)) { ... }