HaloO,
John M. Dlugosz wrote:
I don't want to have to "extract" it. I want to be able to say
$x = foo
I guess that does not collapse the capture that foo returns. So
it goes into $x unaltered. If you later use $x as an invocant
of a method this extracts the invocant slot from the capture.
And $x<named> works as expected.
and get the single value return from foo, and only dress it up if I want
the optional secondary returns
my ($x, :$named) = foo; # or something like that
Should work.
Sorry, you lost me again.
Single-assignment is a feature from constraint programming e.g. in Oz.
There you have a single-assignment store. I interpreted Larry's comment
on my coro question as making single-assignment semantics first-class
and everything else second-class.
A capture can contain an array that later on can change its content:
@a = 1,2,3;
@b = 4,5,6;
@c = 7,8,9;
$cap = \(@a,@b);
$cap[0] = @c; # error
$cap[0][] = @c; # ok, @a now 7,8,9
Writing into a container is contra-variant. Reading is co-variant.
So a capture has to be invariant. Assume A <: B <: C and regard
my A $a;
my C $c;
my B $ba := $a; # ok for reading from $a
my B $bc := $c; # ok for writing into $c
Both bindings are type errors. If captures were recursively immutable
you could allow bindings ala $ba. Well, or we interpret $a and $b as
typed views of whatever value they lead to. This insures that there
will never be assignment or binding type errors.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
