Juerd wrote:
From S02: "Array and hash variable names in scalar context
automatically produce references."
Since [...] produces a scalar arrayref, we end up with an arrayref one
both sides of the =.
No.
There is no scalar context on the LHS of the assignment operator.
And, assigning to a reference is impossible, as a reference is a VALUE,
not a VARIABLE (container).
This argumentation breaks down as soon as you regard &infix:{'='} as
an operator like many others. How do you derive context for the lhs
and rhs of &infix:{'+'} or &infix:{'*~*'}? From its invocant part of
the signature? With the sigil giving the default overrideable with the
'is context' param trait? Or does only the slurpy indicator * enforce
list context?
But then there might be a little bootstrapping problem with MMD if
both contexts are defined. How does one dispatch an Array then?
Junctively flattened and unflattened?
And another oddity is that the compiler has potentially to go back
and re-compile some code with invocations of ops if it later sees more
overloaded definitions of these ops that have other context traits in
their signature. It's much easier to just compile to MMD code and leave
the rest to the runtime dispatch. But this requires a self-contained
definition of the meaning of @a and [] as described by Rod.
--
TSa (Thomas Sandlaß)
