Re: Removing/fixing $[line noise here] variables

[John Porter]

Brust, Corwin wrote:
 
 messages.rfc - An RFC to discussing the wisdom of allowing run time error
 and warning messages to be modified at run time
 ...
 I want perl's error (and warning) messages to be specific to each program I
 write.

Isn't this covered by locales?

-- 
John Porter

Re: Removing/fixing $[line noise here] variables

[Steve Simmons]

On Wed, Aug 02, 2000 at 03:34:56PM -0400, John Porter wrote:

 Brust, Corwin wrote:

  I want perl's error (and warning) messages to be specific to each program I
  write.
 
 Isn't this covered by locales?

Completely different beast.  I don't claim to fully understand locales,
but that's not what they're for.

Re: Removing/fixing $[line noise here] variables

[Simon Cozens]

On Wed, Aug 02, 2000 at 01:48:36PM -0600, Tom Christiansen wrote:
 Isn't this covered by locales?
 Unicode and locales are immiscible.

In Perl 5. This is *by no means* a general statement.
ICU is, for instance, a Unicode locale library.

-- 
Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who, "Androids of Tara"

Re: Removing/fixing $[line noise here] variables

[Larry Wall]

Steve Simmons writes:
: On Tue, Aug 01, 2000 at 04:47:47PM -0400, Dan Sugalski wrote:
: 
:  Put together an RFC for it. (Soon!) This is a language topic, but it will 
:  impact internals a touch, and I'd like to get as many of the "impact 
:  internals" things spec'd out as soon as possible . . .
: 
: Uh, OK - but how about we wait 24 hours to see who screams bloody murder?

Some of these concepts are not going to be global concepts in Perl 6.
The per-filehandle variables will be attached to filehandle objects.
The format variables will likely be attached to format objects.  Every
one of these global variables needs to be scrutinized to see if it
should be replaced with a lexically scoped variable.

If there are any left after that, then we could certainly consider
putting them into global hashes.

Larry

RE: Removing/fixing $[line noise here] variables

[Dan Sugalski]

At 03:53 PM 8/1/00 -0500, Brust, Corwin wrote:
Could this then also give the programer control over the content of
error/warning messages produced by Perl at runtime?

That's feasable. It'd be a performance hit, but I can't picture this really 
being a performance-critical area... :)

Put together an RFC for it. (Soon!) This is a language topic, but it will 
impact internals a touch, and I'd like to get as many of the "impact 
internals" things spec'd out as soon as possible. Even if the final form 
differs, it's easier to modify a capability than bolt it on after. (cf 
perl5  threads...)

-Original Message-
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 3:37 PM
To: Perl6 Language Changes
Subject: Removing/fixing $[line noise here] variables


For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
well.  `mod' is `CORE', `FORMATS', etc, as above.  A value of 0 means the
function is actually gone, 1 means it's disappearing next major release,
2 mean next minor, etc.  The programmer can control what happens when
the feature is used by setting a %PERL_DEPRECATED{mod}{warning} value
to 0 for default, 1 for once, 2 for never, etc, etc.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Removing/fixing $[line noise here] variables

[Alan Burlison]

Steve Simmons wrote:

 I'd prefer that we break these vars out into a set of hashes with
 appropriate names:
 
   $PERL_CORE{warnings}  vs  $^W
   $PERL_CORE{version}   vs  $^V
   $PERL_FORMATS{name}   vs  $^
   $PERL_FORMATS{lines_left} vs  $-

Hmm - I quite like this.  I'd like it even more if they were package
scoped and/or localisable.  My choice of warning level in my package
shouldn't affect your choice in your package.

-- 
Alan Burlison