HaloO,
John M. Dlugosz wrote:
Please see part 2 of my comprehensive explaination of the Perl 6
Information Model, at http://www.dlugosz.com/Perl6/web/lvalues.html.
This isn't linked up to my main page yet. I'm taking comments and
further discussion here before I make it public.
This is a pretty good summary. It also nicely points out missing
specifications concerning the 'is ref' trait. I'm keen on reading
your analysis concerning the difference between a parameter with
a @ sigil and a 'Positional $x' sig.
I like your idea to call the class that handles container access
LValue. I have proposed the name AssignmentProxy elsewhere.
But I'm not sure what S06 means with can be converted to an lvalue
in the description of the 'is rw' parameter trait. To me this means
autoboxing such that you can call a mutating sub with a constant. The
modifications done to the automatic container are lost after the call.
You state that the compiler raises an error which clearly is the cleaner
approach.
There is a feature I miss for array and hash parameters: to make
them immutable. This allows for subtype based dispatch. So I propose
to add an 'is immutable' parameter trait. Here is an explanation
why that is useful. Assume that Dog is a subtype of Animal and that
it has a bark method that is not available in Animal, i.e. calling
it on an Animal instance is an error.
sub store17 (Animal @a)
{
@a[17] = Animal.new; # assignment error?
}
my Dog @dog;
store17(@s); # bind error?
@dog[17].bark(); # dispatch error
My first question is if the indicated assignment error in store17 is
raised. The best spot to detect the error is at bind time when store17
is called with a Dog array. Here immutability of the array would allow
the call because writing into the array is then prohibited. Reading a
Dog and using the Animal interface on it is type safe.
The 'is immutable' trait should also be applicable to methods so
that objects get a subset of their interface that is not mutating
the object. This is like const methods in C++. The default 'is readonly'
of parameters applies only to the lvalue not the referenced object.
A good question is if the compiler can statically detect array
assignment because postcircumfix:[ ] could be an immutable method
of the Array. A mutation of the array happens only when the returned
LValue instance is used as lhs of an assignment. So the question is
if the immutability of the array is propagated to the LValue and how
the compiler knows that. How would that be written in the sig of
postcircumfix:[ ]? The syntax has to define a conditional trait on
the return type. One approach could be to define that a type capture
transports the trait:
role Positional
{
method postcircumfix:[ ]
(::T $self: Int $i -- LValue[T] is immutable(T))
is immutable
{...}
}
After writing the above I realized that your webpage actually claims
that readonly @ sigil parameters are blocking the mutating Positional
interface. If this is true I'm happy. The thing that should be specced
then is the availability of 'is readonly' for methods. This is needed
to implement the distinction between the mutating and non-mutating
interfaces of objects. Hmm, could the compiler infer this trait from
the body of the method?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
