Larry wrote:
On Sun, Mar 26, 2006 at 02:40:03PM -0800, Larry Wall wrote:
: On the original question, I see it more as a junctional issue.
: Assuming we have only chmod($,$), this sould autothread:
:
: unless chmod MODE, all(@files) -> $oops {
: ???;
: profit();
: }
Except that junctional logic is allowed to fail as soon as it can be
falsified, so if some set of file is not chmodable, you'd randomly
get an error message for one of them. You really need something that
drives it to completion, like hyperop, or a pipe, or a list operator.
(Which is sort of what we already have, but the return status of such a
list operator should probably be a list, or something that does list.)
On the other hand, if it's only the boolean context that wants
to short-circuit a junction, maybe binding to $oops drives the
autothreading to completion somehow. (Or asking for a list value
from $oops, more likely).
Hmmmm. I'm not sure I want to extend the QM metaphor to quite that much
magical action at a distance. ;-)
Especially since, if the boolean context doesn't itself drive the distributed
chmod() to completion, then something like:
die unless chmod $MODE, all(@files);
is potentially going to leave your filesystem in an unpredictable state. :-(
In other words, this is another example of "Don't use junctions in actions
with side-effects".
What we have here is a close analogy to the reporting requirements of pattern
matching. We have an operation that we want to have return several (possibly
lazily computed) pieces of outcome status. That's why we use an Match object
for the outcomes of pattern matches, and that's why I suggested a similarly
structured Outcome object for chmod (and other built-ins). It feels like
there's a more universal "status reporting from list-op" mechanism here, just
waiting to be generalized out.
Damian
