|Perl: the Markov chain saw|
Re: (ichi) Re x 4: Apocalypse 5 and regexesby TheDamian (Priest)
|on Jun 08, 2002 at 23:10 UTC||Need Help??|
I'm also not sure I understand the motive for optimization at this point (2,3)-- it seems premature... but I will defer to your experience.
The point is not to actually insist on optimisation at present (though part of our motivation in cleaning up the Perl syntax is to make more optimizations possible). The point is to avoid making changes now that make later optimisations impossible. Which is what unifying arrays and hashes would do.
I am certain I haven't had any problems keeping my Ruby hashes and arrays separate (4)
I'm sure. But we don't just design for programmers as clueful and competent as you. We have to consider the common mistakes made by the vast majority of Perl programmers -- whose level of experience and ability is quite low. And then consider how the changes we propose will affect them.
In my (considerable) experience with such programmers, one of their most frequent difficulties is distinguishing between container types. I've published research1 that indicates that removing syntactic cues to the differences between data types (as the Turing language did, for example) makes that problem far worse.
As to 5, I think I'll wait for Ex5, since I've not yet internalized A5, but I don't see how the brackets/brace is a problem if you are assigning a series of key/values to a hash
It isn't. In that particular case.
But that's not what I was talking about. I was talking about the case where a regex returns a "match object" (either directly, or via $0):
Now array accesses on (say) $match give you the numbered captures:
Whereas hash accesses on it give you the named captures:
But if there's no syntactic distinction between arrays and hashes (represented here by a hypothetical, unified $match<...> accessor), how do you distinguish between hash-like and array-like look-ups on non-literal keys:
Deciding that last case on the basis of run-time type of the values in $val and $key is both much slower, and vastly more error prone (in light of Perl's free-and-easy interconversion of numbers and strings).
So people will be generally forced to make the distinction explicit anyway:
Which is far worse than what we have now.