Brent 'Dax' Royal-Gordon skribis 2004-04-15 16:56 (-0700):
1. Allow %hash<<foo>> to be typed as %hash<foo>. There would be a conflict with numeric less-than, but we can disambiguate with whitespace if necessary. After all, we took the same solution with curlies.
Curlies which, as said, I also don't like typing.
I referred to the curlies only to point out that we're already disambiguating with whitespace with one of the other indexers.
On a US Dvorak or QWERTY keyboard,
{'foo'} is 9 key presses and 7 characters
<<foo>> is 9 key presses and 7 characters
<foo> is 7 key presses and 5 characters
`foo is 4 key presses and 4 characters
Number of keystrokes isn't our only concern here. This is Perl, not APL--we care about the size of the language and its intuitiveness too. (Perhaps not much, but we do.)
I don't like %hash{'foo'} because it's ugly. I don't like %hash<<foo>> because it's ugly and adds syntax. I don't like %hash`foo because it's ugly, adds syntax, and looks nothing like an indexing operator. (I'll revisit this third point soon.) I think it will be easier to fix %hash{'foo'} or %hash<<foo>> than %hash`foo.
Also important when picking a character is its glyph. ` is light weight, like the . that we use for methods. I don't want whitespace around this operator, so the operator must not be fat, like %, @ or #.
I agree that none of those are suitable. That's why I didn't propose them.
The biggest deficiency with the two syntaxes that are already there is that they both use a pair of characters.
Why is this a deficiency? I've never felt put out by the fact I had to type an extra character to index an array or hash.
It's also worth noting that, except for Javascript, every language I can think of uses paired characters for indexing. Perl 5 uses {} and []; the C-like languages I know use []; Visual Basic (ugh) uses ().
In Javascript, the dot syntax is a clever generalization, allowing the language's underlying hash-like data structures to look like both hashes and objects. This isn't the case with Perl.
I dislike XML and HTML because they're a lot of typing (not only because of the redundancy in the closing tags).
If the proposal was for a syntax like:
<index type="hash">
<var>%hash</var>
<string>foo</string>
</index>I'd be inclined to agree with you. But we're talking about *one* *extra* *character* here. That's two keys. It's hardly the end of the world.
Compare:
$foo<bar><baz><quux>
$foo`bar`baz`quux
In fact, I encourage everyone to type the above two lines a few times.
I'm not arguing that your syntax isn't shorter or easier to type. I'm arguing that shorter and easier to type aren't enough to justify it.
2. Allow barewords in curlies as a special case. We're already allowing them on the left side of => (I think), which is even more ambiguous.
It would require some character to disambiguate again, or you have the unquoted strings that Perl 5 has, but restricted to hash usage. Adding a sub or method that happens to have the same name as a hash's key should not break any code.
"If the inside of a hash indexer consists entirely of \w characters, it will be interpreted as the name of a hash key. If you want it to call a subroutine instead, add a ~ stringifying operator to the beginning of the call, or a pair of parentheses to the end of it." Simple, clear, and doesn't shift around based on subroutine definitions. (It's not what Perl 5 does, but that's Perl 5's fault.)
3. Define hash indexing with a pair to index on the key. This would allow the syntax %hash{:foo}. (This could even be achieved by making C<~$pair eq $pair.key>.)
{:foo} is 8 key presses. A too small step to be worth anything in practice.
It looks better to me and doesn't add any syntax.
4. Define a bareword-quoting prefix operator (i.e. one that turns the next \w+ into a string) and use the normal hash indexer, {}. I have no suggestion for this operator's name, although if you wanted to rip out the current unary backticks, it could be a candidate: %hash{`key}.
Same as 3, but with another character.
The only syntax it adds is something more generally useful than your proposal, in that it could be used anywhere you want a bareword.
To make my position clear: WE DO NOT NEED THREE WAYS TO INDEX A HASH. I don't really think we need two. All we really need is one way with a good enough syntax to meet all of our needs.
-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
