Damian Conway wrote:
>
> But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically.
> And I'm removing that analogy from the next version of the RFC! ;-)
>
> They have *everything* to do with $_[0], $_[1], $_[2], etc.
I realize this, but I don't think most people will see it that way. I
see the analogy part much more clearly. Having ^1 and $1 be the same
makes a lot more sense than having $1 and ^0 both be the start.
Why? Consistency is key. With arrays, people understand that [0] is the
first element because they're dealing with a computer.
But with regexps (and HOFN), we're now into stuff that's good for
humans. And the "First" element should be "^1", just like for regexps.
Unless you want to start telling people that the "Zeroeth" element is
"^0".
But having the "First" element be "0" makes *no* sense. Not for humans.
It never has.
> In fact, every kind of indexing in Perl -- *except* $1, $2, etc. --
> starts at zero. Fixing $0's semantics would be far more consistent than
> breaking ^0.
That's fine too - if we want to do this, let's! Honestly. I say:
1. Make $ARGV[0] have the program name
2. Make $0 be the first regexp match
But I see two problems with this:
1. Now "for (@ARGV) breaks"
2. The "first" argument is now "0" again
Please! Make the "first" be ^1. It's more consistent and makes more
sense for us humans.
We're not "breaking ^0" either - it doesn't exist yet. Rather, we're
fixing it before the bug hits the customer. I guarantee you this will be
a common mistake, I've done tons of work in real-life user-interface
testing. Users see *simple* analogies, not deep ones ("^1 like $1, the
first one")
If I ask you to count to ten, which number do you start with?
-Nate
