HaloO,
Larry Wall wrote:
Yes, I think think you're probably right that the correctest answer
to this will be to make the operation of binding $x++ trigger
the autoincrement lazily.
I consider this answer far from correct. Postincrement is an operator
like any other code object and it returns a value. E.g. the standard
postincrement does not return an lvalue, that is $x++ = 3 is an error.
Overloaded definitions should adhere to this behavior.
my $capture := \($x++);
foo(|$capture); # increments $x
bar(|$capture); # increments $x again
Since postfix:<++> is like any other code object we would also
have
my $capture := \($x.blahh)
foo(|$capture); # calls .blahh
bar(|$capture); # calls .blahh again
This should not be the case. The capture should call the code
object once and capture the return value. The other way can
be written as \({$x.blahh}) if that is what the programmer wants.
But perhaps \($x++) can be explained by analogy to { $x++ }. It's
basically just a thunk, and the eventual binding and/or evaluation is
what prevents it from degrading into the morass of call-by-name-ness.
So it's very much like the thunks in
$maybe ?? $x++ !! $y++
where you don't know which will be incremented until the implementation
of ??!! decides to run one thunk or the other.
But ??!! is specced to take three thunks as parameters. The capture
generator \ should not have thunks as parameters. This means that
\(some_condition() ?? $x !! $y) captures either $x or $y and sticks
to that. It should not thunk the whole expression and evaluate
some_condition whenever the capture is accessed.
It's also a strange way to name a monadic sort of relationship:
my $capture := \($x++);
$x = 0;
|$capture xx * # 0,1,2,3,4
\($x++) should not capture $x because this was the argument of
the sub call. Or do we want \($x + $y) to capture $x and $y
along with the fact that when the capture is accessed their
values at that time need to be dispatched to infix:<+>?
But certainly a lot of the get-into-trouble examples involve $x++,
so we'll need to be careful with that particular monad^Wside effect.
Actually not. Every code object invocation is a get-into-trouble
example unless it is purely functional code.
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
