Mailing List Archive

Re: braced barewords (was) Re: HERE IS: Kruskal's algorithm
On Tue, 12 Dec 1995 08:40:36 MST, Tom Christiansen wrote:
>
>> use warn 3;
>> {
>> no warn qw(W2_UNINIT W2_BARESTR);
>> ...
>> }
>
>that's not very pretty.

Do you mean the notation for the constants? What would
you suggest?

>
>I could certainly write a
>
> use fatal qw/uninit/;
>
>but the __WANR__ hooks aren't nicely stackable, so that
>might be problematic (see diagnostics.pm or CGI::ErrorWrap)
>

&warnhook etc. in the perl source could easily be an ARRAYREF
that would contain a list of cv's. All the cv's could then be
sequentially called. Would this be adequate?:

$SIG{__WARN__} = [\&sub1, 'sub2', sub { '..3..' }];
# ditto for __DIE__
# hmm, __PARSE__ does nothing useful now

On the other hand, I don't see why this can't be implemented
in a warn.pm if we adopt the convention that warn.pm will
provide the interface for stacking and unstacking handlers for
all modules that need to use the __WARN__ facility. Similarly
for die, although I don't like the name die.pm that much :-)
I think we're badly in need of such a convention and interface,
else we'll have modules trampling over each others' handlers.

A module like diagnostics could request special treatment (if no
other module is already getting it) to force itself into
the bottom of the stack so it sees only the warn messages
from perl itself.

- Sarathy.
gsar@engin.umich.edu
Re: braced barewords (was) Re: HERE IS: Kruskal's algorithm [ In reply to ]
> use warn 3;
> {
> no warn qw(W2_UNINIT W2_BARESTR);
> ...
> }

that's not very pretty.

> Inhibiting specific warnings will of course be implemented
> via __WARN__ so perl efficiency will not suffer. This will
> likely need a more regular format for warnings and errors
> that can be more reliably parsed inside a warn hook without
> fear of failing when a new warning gets implemented.

>I'm especially going to need comments on the first, based on your
>personal experiences, from answering novice questions, etc.

Yet again this morning I received 3 requests to
be able to promote unitialized variable accesses
to fatals.

I could certainly write a

use fatal qw/uninit/;

but the __WANR__ hooks aren't nicely stackable, so that
might be problematic (see diagnostics.pm or CGI::ErrorWrap)

--tom
Re: braced barewords (was) Re: HERE IS: Kruskal's algorithm [ In reply to ]
On Tue, 12 Dec 1995, Gurusamy Sarathy wrote:

> $SIG{__WARN__} = [\&sub1, 'sub2', sub { '..3..' }];
> # ditto for __DIE__
> # hmm, __PARSE__ does nothing useful now
>
> On the other hand, I don't see why this can't be implemented
> in a warn.pm if we adopt the convention that warn.pm will
> provide the interface for stacking and unstacking handlers for
> all modules that need to use the __WARN__ facility. Similarly
> for die, although I don't like the name die.pm that much :-)
> I think we're badly in need of such a convention and interface,
> else we'll have modules trampling over each others' handlers.
>
> A module like diagnostics could request special treatment (if no
> other module is already getting it) to force itself into
> the bottom of the stack so it sees only the warn messages
> from perl itself.

Ahem. Check out the Religion module in CPAN. It's not _exactly_ what you
are talking about, but it's real close.

> - Sarathy.
> gsar@engin.umich.edu

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
Re: braced barewords (was) Re: HERE IS: Kruskal's algorithm [ In reply to ]
On Tue, 12 Dec 1995 16:17:31 EST, Kenneth Albanowski wrote:
>> A module like diagnostics could request special treatment (if no
>> other module is already getting it) to force itself into
>> the bottom of the stack so it sees only the warn messages
>> from perl itself.
>
>Ahem. Check out the Religion module in CPAN. It's not _exactly_ what you
>are talking about, but it's real close.
>

Religion silently suffers the informal structure of the warn/die
messages that perl hands to the handlers. It really ought to be
reworked into a more structured error message format. I will attempt
something along these lines as part of the general overhaul of the
warn/die code in the sources.

When that happens, much of the "shaky" code in Religion would go away, and
it can do what is an imperative: provide a clear means for
registering/deregistering handlers and call them under some formal order.

If it can be agreed that a convention of using a pragma (for managing how
hooks are handed out to warn/die handling packages) is both useful and
neccessary, we should also think about a suitable (lowercase) name for the
package implementing the pragma.

- Sarathy.
gsar@engin.umich.edu
Re: braced barewords (was) Re: HERE IS: Kruskal's algorithm [ In reply to ]
On Tue, 12 Dec 1995, Gurusamy Sarathy wrote:

> Religion silently suffers the informal structure of the warn/die
> messages that perl hands to the handlers. It really ought to be
> reworked into a more structured error message format.

Not silently -- I go to a lot of work to reformat it into a more
structured format. :-)

But yes, this is shaky code, and really shouldn't be needed. To top it
off, I know perl can generate some other messages (when $/ has been
changed) that I'm not bothering to parse yet.

> I will attempt
> something along these lines as part of the general overhaul of the
> warn/die code in the sources.
>
> When that happens, much of the "shaky" code in Religion would go away, and
> it can do what is an imperative: provide a clear means for
> registering/deregistering handlers and call them under some formal order.

Sounds good from here.

> If it can be agreed that a convention of using a pragma (for managing how
> hooks are handed out to warn/die handling packages) is both useful and
> neccessary, we should also think about a suitable (lowercase) name for the
> package implementing the pragma.

What kind of pragma are you talking about? Something like:

use fatal proc $dieproc;

???


> - Sarathy.
> gsar@engin.umich.edu
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)