On Sat, Mar 26, 2005 at 03:37:41AM -0700, Luke Palmer wrote:
: > $! will be a legal variable name. $/ is going away,
:
: By which you mean that $/ is turning into a special $0.
I'd say that $0 is a specialization of $/, but yes, basically, they
both represent the current match result, albeit differently. $0 is
explicitly what would have been returned by $1 if you'd put parens
around the entire match, which is not quite the same as the complete match.
result.
: > Anything that varied with the selected output filehandle like $|
: > is now a method on that filehande, and the variables don't exist.
: > (The p5-to-p6 translator will probably end up depending on some
: > $Perl5ish::selected_output_filehandle variable to emulate Perl 5's
: > single-arg select().)
:
: I think $| et al. could just translate to methods on $*OUT, and select
: would look like this:
:
: sub perl5_select($fh) {
: $*OUT = $fh;
: }
:
: Is there some subtlety that that doesn't cover?
Like, it renders standard output nameless? In Perl 5, the selected output
handle is a level of indirection above the standard names for the streams
attached to fd 0, 1, and 2. Saying select(FH) doesn't change the meaning
of STDOUT.
: > %+ and %- are gone. $0, $1, $2, etc. are all objects that know
: > where they .start and .end. (Mind you, those methods return magical
: > positions that are Unicode level independent.)
:
: Uh, it might be a bad idea to make $# objects. It might not, but it
: might. I think it would be fine if they turned into regular strings
: upon assignment (and to pass their full objecthood around, you'd have to
: backwhack them). But the problem with keeping them objects is that if
: you put them somewhere else and change them, they turn back into regular
: strings without .start and .end, which may be a hard-to-track-down bug
: if you're thinking that they stay objects... haven't really thought
: about this much (and my head is irritatingly foggy at the moment).
My head is always irritatingly foggy. :-)
Anyway, I'm think of them more as COW objects, and they'd have to know
if their original string was yanked out from under them in any case, so
that's probably the correct moment to invalidate .start and .end, if
we even bother.
: > $; is gone because the multidim hash hack is gone.
:
: Funny, I never used the multidim hash hack, I just emulated it:
:
: $hash{"$foo$;$bar"} = $value;
Well, guess how we'll emulate it in Perl 6. :-)
: > We never did find a use for $}, thank goodness.
:
: Isn't that the "enable all of Damian's unpublished modules" variable?
Shh. Impressionable people are listening.
: > $^W is is too blunt an instrument even in Perl 5, so it's probably gone.
:
: Well, almost. When writing a recent module, I found that one of the
: modules I was using was spitting out an error from its own internal code
: on one of my calls, and there was nothing wrong with the call. I
: submitted a bug report to the author, and searched for a way to shut it
: up so my users wouldn't complain at me. It ended up having to use $^W
: at compile time (and it looks very hackish). We ought to have a
: (perhaps not quite as hackish) ability to say "there's no reason for
: that warning, but I can't modify your code, so just be quiet".
Yes, we need to be able to suppress warnings in dynamic scopes as well
as lexical, but that's probably not a scalar proposition anymore, unless
the replacement for $^W is taken as a pointer to a hash of potential
warnings. Presumably you could temporize the whole hash to suppress
all warnings, or individual elements to suppress individual warnings.
But maybe that's a good place for temporized methods instead, and then
we could name sets of warnings. Or maybe there's yet some other approach
that makes more sense. We want to encourage people to suppress only
the exact warnings they want to suppress, and not just cudgel other
modules into silence.
: > I'm not quite sure what to do with $^N or $^R yet. Most likely they
: > end up as something $<foo>ish, if they stay.
:
: For $^N, how about $/[-1]?
I guess that makes some sense. I was thinking of $/[-$n] as relative
to the current match position, but hadn't thought it through to the
point of deciding how to count those. $^N mandates counting based on
right parentheses rather than left, which I guess makes sense. So
let's say that $/[-2] means (one) rather the incomplete ((three)two):
/(one)((three) { $/[-2] } two)
I note that this is another difference between $/ and $0, since $/
is representing the current state of the match, while $0 isn't bound
till the match succeeds (unless you explicitly bind it earlier, which
is yet another difference between $0 and $/, since you can't bind $/
to mean a portion of itself).
Larry
