note
TheDamian
<i>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.</i>
<p>Thank-you. <tt>;-)</tt>
<p>The point is not to actually insist on optimisation at present (though part of our motivation in cleaning up the Perl syntax <em>is</em> 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.
<p><i>I am certain I haven't had any problems keeping my Ruby hashes and arrays separate (4)</i>
<p>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.
<p>In my (considerable) experience with such programmers, one of their most frequent difficulties is distinguishing between container types. I've published <a href="http://www.csse.monash.edu.au/~damian/papers/#Human_Factors_in_Programming_Languages">research</a><a href="#fn1"><sup>1</sup></a> that indicates that removing syntactic cues to the differences between data types (as the Turing language did, for example) makes that problem far worse.
<p><i>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</i>
<p>It isn't. In that particular case.
<p>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 <tt>$0</tt>):
<code>
$match = m/complex pattern/; # match object in $match
m/complex pattern>; # match object in $0
</code>
<p>Now array accesses on (say) <tt>$match</tt> give you the numbered captures:
<code>
print "$match[1] was val for $match[0]\n";
my ($key,$val) = (0,1);
print "$match[$val] was val for $match[$key]\n";
</code>
<p>Whereas hash accesses on it give you the named captures:
<code>
print "$match{val} was val for $match{key}\n";
my ($key,$val) = ("key", "val");
print "$match{$val} was val for $match{$key}\n";
</code>
<p>But if there's no syntactic distinction between arrays and hashes (represented here by a hypothetical, unified <tt>$match<...></tt> accessor), how do you distinguish between hash-like and array-like look-ups on non-literal keys:
<code>
print "$match<0> was val for $match<1>\n"; # array look-up
print "$match<'val'> was val for $match<'key'>\n"; # hash look-up
print "$match<$val> was val for $match<$key>\n"; # ???
</code>
<p>Deciding that last case on the basis of run-time type of the values in <tt>$val</tt> and <tt>$key</tt> is both much slower, and vastly more error prone (in light of Perl's free-and-easy interconversion of numbers and strings).
<p>So people will be generally forced to make the distinction explicit anyway:
<code>
print "$match<$val> was val for $match<$key>\n"; # ???
print "$match<+$val> was val for $match<+$key>\n"; # array look-up
print "$match<_$val> was val for $match<_$key>\n"; # hash look-up
</code>
<p>Which is far <b>worse</b> than what we have now.
<p><hr>
<ol>
<a name="fn1"><li>They didn't select me to help Larry design Perl 6 just because I'm even weirder than he is, you know! Well, not <em>solely</em> on that basis, at least. <tt>;-)</tt>
</ol>
171822
172559