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.


Reply via email to