On Mon, Dec 05, 2005 at 12:32:03PM +0100, TSa wrote:
> HaloO,
>
> Luke Palmer wrote:
> >The most immediate offender here is the referential passing semantics.
>
> IIRC, the default is to be a read-only ref. Not even local modifications
> are permitted if the 'is copy' property is missing.
>
>
> > Here is a code case:
> >
> > sub foo ($x, &code) {
> > &code();
> > say $x;
> > }
> > my $bar = 41;
> > foo($bar, { $bar++ });
> >
> >As far as I recall, the spec says that this should output "42". My
> >intuition tells me that it should output "41".
>
> My intuition also opts for 41. Evaluating &code() inside foo either
> violates the constance of its own $x if the changes propagate back
> into the already bound/passed argument or violates the callers
> excapsulation. The latter depends on what exactly the second argument
> of the call of foo closes over. Theoretically the binding of
> CALLER<$bar> to foo<$x> could spill over to the closure which then
> would mean foo(x => $bar, { $x++ }) and require $x beeing declared
> either 'is copy' or 'is rw'. In other words it could be marked as error.
No, I think not, because the closure on the last line closes over a
read/write variable. It happens that read only reference to the same variable
is passed into the subroutine, but that's fine, because the subroutine never
writes to *its* reference.
Thinking about it in C terms, where pointers and values are explicit, it's as
if function arguments are always passed as const pointers to a value in a
outer scope. This seems fine and consistent to me, but you can never be sure
whether anyone else has another pointer to that same value, which they can
modify at any time.
If nearly all function parameters are PMCs (internally) I don't think that
this is an efficiency problem, as PMCs are always reference semantics, even
when loaded into Parrot's registers.
Nicholas Clark
