2000-08-27-12:03:07 Peter Scott:
> > use Fatal qw(:io ...);
> > no Fatal qw(:arithmetic);
>
> Bingo, yes. I will make appropriate changes to RFC 80. You might
> think about whether RFC 70 needs to be changed.
I don't think so; while I mention styles of changes and growth for
Fatal.pm, I don't regard that as the focus of RFC 70. RFC 70 merely
proposes that the core be changed so that Fatal.pm can be finished;
the discussion of the nature of future growth for Fatal.pm was
merely included to motivate the requested change [make all
error-returning builtins wrappable]. While more detail is important,
I think it belongs in other RFCs; I'll only expect to change RFC 70
again if developments end up falsifying something I wrote, I don't
think I need to make discussion of Fatal.pm more comprehensive. I've
already cited RFC 80 in my references section; would you think that
sufficient? I don't want to keep blatting out updates if they're
trivial, since each one ends up provoking a repost, not to mention
there's no easy way to show people what the changes are, so you end
up asking them to constantly reread the thing. Lord knows there's
enough to read on perl6-all already:-).
> The ramifications of some of these things are sufficiently
> important that drawing attention to them might be a good thing.
> In this case, note that Perl 6 will need to spell out which core
> exceptions are by default fatal (eg, :arithmetic) and which
> aren't. Although RFC 70 doesn't have to do that.
It feels to me like this should maybe be divided into some change to
RFC 70, along with a companion RFC --- unless you want to fold all
discussion of Fatal.pm development into 70. But if you like I'll be
happy to include in RFC 70 the request that any builtins that
_by_default_ "throw exceptions" (die) on errors, _also_ be wrappable
so that Fatal.pm can be written to allow e.g. "no Fatal
qw(:arithmetic)". Of course that specific one may require additional
intimacy between Fatal and the core, since unless we make all
arithmetic scalars into objects, I don't think we're set up to allow
overriding basic arithmetic builtins like e.g. "/" for
divide-by-zero.
> >I beat you to it. While RFC 70 was intended to just request that it
> >be possible to finish Fatal.pm so it works as intended and desired,
> >it does mention:
> >
> > If [the finishing-up of Fatal.pm, after fixing the busted core]
> > were a success, then the requested category could also be posted
> > into a testable variable, allowing module authors who wished to
> > to automatically support this functionality as well.
>
> Got anything in mind? $^something?
Lordie no, please nonononono.
@Fatal::Args seems sweet, and if the proposal elsewhere to lexically
scope package variables from the point of view of the "use"-er
should fly, such a posting area should remain available as
@main::Fatal::Args. Or perhaps %Fatal::Args, since (a) most folks
will want to test for one or more specific ones, rather than
searching a list, and (b) it might be nice to be able to post a "1"
into the hash slot for "use" and a "0" for "no". I.e.
no Fatal qw(:arithmetic);
might have to reach in and dink with some disgusting
control-character-named handle to modify the core's behavior, but
it'd post the argument with the equivalent of
$Fatal::Args{':arithmetic'} = 0;
-Bennett
PGP signature
