lvalue functions and lvalue parameters
Daniel Hulme
and call by foo. What if I want to write, say, an lvalue ?? !! function
thus
sub cond(Bool $c, $a, $b) is rw {
if $c return $a else return $b;
}
Will this fail because $a and $b are not rw? If so, will it fail at run-
or compile-time? What about this:
sub cond(Bool $c, $a is copy, $b is copy) is rw {
if $c return $a else return $b;
}
Is it allowed, and if so is the behaviour to return a writeable copy of
$a or $b? I imagine that in any case
sub cond(Bool $c, $a is rw, $b is rw) is rw {
if $c return $a else return $b;
}
will do what I want. I suppose the issue comes down to the scope of
modifiers like rw. In the first example, $a and $b are constant in the
scope of the function, but they aren't written in the scope of the
function. They are then passed to the caller which may then try to write
them, but will they remember that they are rw in the caller's scope?
Furthermore, what if they aren't rw in the caller's scope?
my Int $a is constant = 0;
my Int $b is constant = 0;
(cond(True, $a,$b))++;
What goes on here, for any of the cond definitions? Do any of them
result in breaking the constancy of $a? I'm not sure, but I think my
vote is for contestant number one to fail at compile-time, number two to
generate new, writeable copies, and number three to give the returned
lvalue the same writeability as its caller.
Come to that, what is the behaviour of constant variables being rw'ed in
parameter lists?
sub rwify($a is rw) { $a += 19; }
my Int $a is constant = 23;
rwify $a;
say "The meaning of life is $a";
I would imagine it should fail on the function call, but I'm open to
other suggestions.
--
Humpty Dumpty sat on the wall, Humpty Dumpty had a great fall,
All the King's horses and all the King's men | http://surreal.istic.org/
Couldn't put Humpty together again. | powered by cat and ^d
Perhaps they shouldn't have given the horses the first go.
Jonathan Scott Duff
I don't have any real answers, but I'll weigh in with my opinion
anyway :-)
On Tue, Jun 20, 2006 at 10:59:01AM +0100, Daniel Hulme wrote:
> I've just thought of an interesting interaction with lvalue functions
> and call by foo. What if I want to write, say, an lvalue ?? !! function
> thus
>
> sub cond(Bool $c, $a, $b) is rw {
> if $c return $a else return $b;
> }
>
> Will this fail because $a and $b are not rw? If so, will it fail at run-
> or compile-time? What about this:
That looks like it should be a compile-time failure to me.
> sub cond(Bool $c, $a is copy, $b is copy) is rw {
> if $c return $a else return $b;
> }
>
> Is it allowed, and if so is the behaviour to return a writeable copy of
> $a or $b? I imagine that in any case
I'd expect a compile-time failure here too, or at the very least a
warning. Besides, returning a local copy each time hardly seems
useful, except perhaps as a way to leak memory.
> sub cond(Bool $c, $a is rw, $b is rw) is rw {
> if $c return $a else return $b;
> }
>
> will do what I want.
That is what I would expect too.
> my Int $a is constant = 0;
> my Int $b is constant = 0;
> (cond(True, $a,$b))++;
We have a "constant" declarator now, so that would be
constant Int $a = 0;
constant Int $b = 0;
(cond(True, $a,$b))++;
and that should fail at compile time because the compiler knows that
$a and $b are constant and can't be rw.
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Sam Vilain
>> sub cond(Bool $c, $a, $b) is rw {
>> if $c return $a else return $b;
>> }
>>
>> Will this fail because $a and $b are not rw? If so, will it fail at run-
>> or compile-time? What about this:
>>
> That looks like it should be a compile-time failure to me.
>
Depends on the interpreter of course, but ideally, yes, compile time.
>> sub cond(Bool $c, $a is copy, $b is copy) is rw {
>> if $c return $a else return $b;
>> }
>>
>> Is it allowed, and if so is the behaviour to return a writeable copy of
>> $a or $b? I imagine that in any case
>>
> I'd expect a compile-time failure here too, or at the very least a
> warning. Besides, returning a local copy each time hardly seems
> useful, except perhaps as a way to leak memory.
>
It doesn't have to be a real copy, that's up to the implementation to
apply whatever COW mechanism it likes. The type of $a and $b in this
case is compatible with the return type of the function, so it should be
fine.
This example is a bit useless - cond($x, $a, $b) = $foo won't store the
result anywhere. So this could be a warning along the lines of "useless
use of variable in void context" (but more tailored to this condition)
>> sub cond(Bool $c, $a is rw, $b is rw) is rw {
>> if $c return $a else return $b;
>> }
>>
>> will do what I want.
>>
> That is what I would expect too.
>
Right.
>> my Int $a is constant = 0;
>> my Int $b is constant = 0;
>> (cond(True, $a,$b))++;
>>
>
> We have a "constant" declarator now, so that would be
>
> constant Int $a = 0;
> constant Int $b = 0;
> (cond(True, $a,$b))++;
>
> and that should fail at compile time because the compiler knows that
> $a and $b are constant and can't be rw.
>
Indeed it should, with the same disclaimer as above re: compile/runtime
Sam.