G'day Larry / p6l / p5p,
Larry Wall wrote:
One little problem at the outset here is that Perl 6 has almost no
concept of "built-in" or "CORE", except insofar as the Prelude happens
to choose to import certain subs into the user's scope by default.
Once you actually start parsing and calling functions, there is
no distinction at all between different versions of "open", say.
I think that chromatic's suggestion of roles is an excellent one. In P5 we
certainly do have a concept of built-in (core) functions, and if nothing
else autodie uses this internally to work its dark magicks.
In P6, I imagine we can just drop the the core and user roles, leaving the
other roles intact.
Originally, my plan was for the vanilla autodie:
use autodie;
to enable autodie for all core functions in scope. However I think that
having a 'default' role makes quite a lot of sense. User-defined
subroutines can register themselves with the default role, so a vanilla
autodie can enable Klingon semantics[1] for whatever system is being used at
the time.
Currently, when testing exceptions from autodie, we can use:
given ($@) {
when (undef) { say "No errors here" }
when ('open') { say "Open died" }
when (':file') { say "Some sort of file error" }
>> ...
}
That may be what we have to do for Perl 5, but from the Perl 6
viewpoint it's duplicating information that should derive directly from
the type and introspection systems.
For the following discussion, I fear I'm bumping my head on the low ceiling
of my P6 knowledge, so I apologise in advance for my ignorance.
The autodie exceptions are real objects, which do contain an awful lot of
information about what went wrong, including the failed subroutine, where it
was called from, what arguments were involved, and so on. They just happen
to smart-match against our roles, since those are things that are likely to
be commonly checked.
However I suspect this is a very different system to what's intended for P6
given the next paragraph:
> For instance, functions are real objects in P6,
> and can have other methods than just the "invoke" method. If you want
> to tell a function how to behave, you might just talk to it directly...
So could I theoretically say (in pidgin P6):
open.on_fail(try_the_other_drive);
print.on_fail(panic);
system.on_fail(wake_sysadmin_from_slumber);
That certainly has a lot of value when thinking about parallel processing,
since errors can be handled in-situ, ignored, or handled later when the data
is collated or used.
However there's still a number of quite concrete current-day examples where
the traditional try/catch paradigm provides excellent value. The classic is
a single-threaded sysadmin task:
try {
mount_tapes;
check_tape_labels;
backup_files;
delete_old_files;
}
catch {
wake_sysadmin_from_slumber;
}
finally {
unmount_tapes;
}
Here if any part of our try fails, then we immediately want to stop what
we're doing, rather than overwriting the wrong tape, or deleting files we
didn't successfully back-up. I trust these sorts of exceptions will still
be around in P6?
That's because it would be S33, which hasn't been written yet... :)
Oh good, my searching skills aren't completely dead then.
[snips]
As chromatic suggested, it would be good to use some kind of role-ish
mixin idea (with or without Moose) instead of hierarchies of strings.
Given my ignorance of Moose, and my desire for autodie to be a candidate for
inclusion in the P5 core, I was intending autodie to be orthogonal to Moose.
Of course I'm happy for there to be hooks which Moose may find useful.
I do very much like the idea of roles, they're going to be quite useful.
Mixins I haven't even considered. I'll make sure there's a sane way to use
them, but the ones provided with standard autodie will probably be quite
lightweight.
I dunno--you're dragging us back down from the stratosphere of theory
to the troposphere of practice.
I don't expect we can keep things entirely lined up, but it would
be nice to avoid gratuitous divergence if we can.
I'm not sure actually sure if we've avoided divergence yet, but unless
there's any barotrauma due to the sudden change in pressure, I'll continue
to throw autodie exception-related plans to p6l as they happen. ;)
All the best,
Paul
[1] Klingon semantics: It is better to die() in the attempt than to return()
in failure. I'll buy a beverage for whomever can help me translate that
back into Klingon in time for OSCON. ;)
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
