HaloO,
Austin Frank wrote:
It seems to me like these are related contexts-- arguments to a sub are
supposed to fulfill its parameter list. This makes the overloading of
prefix:<*> confusing to me.
Would an explicit type List help?
I'm pretty sure we don't need slurpiness in argument lists, and I don't
know if the prefix:<*> notation for named arguments would be useful in
parameter lists. But just because I can reason that, for example,
prefix:<*> in an argument list can't mean slurpiness, that doesn't make
it clear to me what prefix:<*> _does_ mean in that context.
Slurpiness in a parameter list is a property of a *zone* not of a
single parameter, IIRC. In a parameter list * actually is no operator
but a syntactic type markup! As arity indicator it could actually be
given after the param like the !, ? and = forms.
If the slurpy zone has more type constraints then just 'give me all'
these have to be met by the dynamic args. The very rudimentary split
in the types is on behalf of named versus positional reflected in the @
versus % sigils. Using prefix:<*> at the call site just defers the
matching to dispatch time unless the type inferencer knows that there
is no chance of meeting the requirements! And parens are needed to
itemize pairs syntactically.
Note that the invocant zone does neither support slurpyness with *
nor optionality with ?. And I'm not sure how explicit types like
List or Pipe behave with respect to dispatch.
I think I understand that prefix:<*> is available outside of parameter
lists because that's the only place we need it to mean slurpiness.
No, I think outside of parameter declarations prefix:<*> indicates
lazy evaluation which I see as a snapshoting of the part of the state
that is relevant for producing the actual values later in the program.
But this might contradict the synopsis which talk of 'when a value
becomes known' which sounds like a ASAP bound ref whose value at deref
time depends on side-effects between the lazification and deref!
So, is there a conceptual connection between imposing named argument
interpretation on pairs in an arg list and slurping up the end of a
parameter list? Are there other meanings of prefix:<*> that relate to
one or the other of these two meanings?
I see the following type correspondences:
*$ Item of List # accessible through the $ variable
*@ List of Item # accessible through the @ variable
*% List of Pair # accessible through the % variable
and perhaps
*& Item of Code # accessible through the & variable
but this last one is not slurping up more than one block.
Hmm, I'm also unsure if a single *$ param suffices to
bind a complete list of args into an Item of Ref of List.
OTOH, it is clearly stated that *$ after a *@ or *% never
receive values.
--
