Seg, 2008-06-09 às 23:09 +0100, Ovid escreveu:
> Well, looking at the examples that you and Jonathan listed, I see I
> should refine my question. For example:
> subset Crosshair of Point where {
> $_.inside_of($target_area)
> ||
> $target_area.has_moved
> ?? $_.move_inside($target_area)
> :: $target_area.move_outside($_)
> };
> In other words, I think we could get proper constraint programming if a
> subset can mutate its variable. Otherwise, all assignment would need
> to be wrapped inside of an eval and the code would be more bug-prone.
> Will said mutating work? If it does, all logic handling constraints
> can be encapsulated in one spot. On the other hand, this could lead to
> mysterious action at a distance. The losses are significant, but the
> wins seem absolutely fascinating.
In fact, I doubt that there's a way to completely avoid any possible
side effects on this closures. as the very first line of the closure
shows:
$_.inside_of(...)
This is a plain method call, there's no way to tell if this method will
change anything inside the object or not.
Obviously, in most cases this kind of constraint checking won't make any
change in the value. it's a dangerous feature, I agree, but it's a price
we pay for many other interesting features, and in fact, some neat
things can be implemented using this dangerous thing itself. Lazy
evaluation is certainly something that will benefit from that.
Imagine that inside_of depends on the result of some IO, the object can
use non-blocking IO, return immediatly and only do the actual reading if
that value is needed, and at that point, the information might even be
already available, so no blocking is ever needed. Or inside_of might
never be called and no IO is ever performed, and this simply defined by
if that value is bound to a variable of a given type (like in a
signature matching).
It's important to remember that, in Perl 6, something is only guaranteed
to be fully executed before the next statement when using short-circuit
operators, everything else is subject to eventually be made lazy, with
the exception of the feed operators, that explicitly say to assume lazy
behaviour.
lazyness is probably the most important perspective change from p5 to
p6, take a look at the code for the default P6 meta class I'm working in
SMOP (the introspection methods, in the end):
http://svn.pugscode.org/pugs/v6/smop/src-s1p/P6Meta.pm
daniel
