(ichi) 2.times('Re: ') Apocalypse 5 and regexes

[ichimunki]

I can't imagine why I would want to put a space between an aggregate and its index (personally, YMMV). That makes it appear as if there are two entities there, when in fact it is one. I can imagine why I would want whitespace in a regex though (and the proposed RE system looks really great). I'm also under the impression that disallowing a space between %hash and {key} allows %hash {block} to perform a block action. The big mistake here is not a whitespace issue, though-- or an inconsistency WRT whitespace. It's a symbol issue.

Apparently Larry has a {} fetish. There is not a single reason why %hash[key] is less acceptable than %hash{key} in Perl6, yet it looks as those the latter will be the way to go. If you kick out %hash{key} in favor of %hash[key], you immediately open up the possibility that %hash [key] can be allowed (unless I've missed something that indicated [key] on its own to mean something the way {key} on its own means something).

[TheDamian]

There is not a single reason why %hash[key]? is less acceptable than %hash{key} in Perl6

You're perfectly correct. There's not a single reason; there are (at least) five:

1. We're trying to retain at least some backwards compatibility in the syntax for variable accesses,

2. Not distinguishing statically between hash and array look-ups severely limits opportunities for fundamental optimizations,

3. Not distinguishing statically between hash and array look-ups reduces our ability to do compile-time error detection,

4. Even without error checking, programmers are much less likely to make mistakes if there is three characters' difference between a hash look-up and an array look-up, rather than just a single sigil (that's why we inflect both noun and verb when making plurals in English),

5. Unless we distinguish hash and array look-ups, there's no way to create objects that can be used as both, according to need (e.g. we can't fix caller to allow named return elements, and we can't allow regexes to simultaneously return their numbered captures as an array and their named captures as a hash.

[ichimunki]

I'm not certain I'm concerned about consistency, if ever there were a time to make a change, this is it (1).

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 am certain I haven't had any problems keeping my Ruby hashes and arrays separate (4)-- and those don't even have sigils (of course, a simple naming convention might keep them straight, but what a pain if you decide to switch an object from one class to another-- indeed, the Perl sigils have this same annoying property).

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. Larry appears to be proposing / %hash{key}:=(val) %hash{key2}:=(val2) / I don't think that / %hash['key']:=(val) %hash['key2']:=(val2) / would be any less acceptable or readable once the programmer gets used to brackets (and using literals instead of bare words). I certainly like the notion of having something like %hash = ($x =~ /key:=(val) key2:=(val2) / ) available, but I didn't see that in A5 (maybe I missed it?).

[TheDamian]

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.

Thank-you. ;-)

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 research¹ 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):

    $match = m/complex pattern/;   # match object in $match
    m/complex pattern>;            # match object in $0

Now array accesses on (say) $match give you the numbered captures:

    print "$match[1] was val for $match[0]\n";
    
    my ($key,$val) = (0,1);

    print "$match[$val] was val for $match[$key]\n";

Whereas hash accesses on it give you the named captures:

    print "$match{val} was val for $match{key}\n";

    my ($key,$val) = ("key", "val");

    print "$match{$val} was val for $match{$key}\n";

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:

    print "$match<0> was val for $match<1>\n";          # array look-u
+p
    print "$match<'val'> was val for $match<'key'>\n";  # hash look-up
    print "$match<$val> was val for $match<$key>\n";    # ???

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:

    print "$match<$val> was val for $match<$key>\n";    # ???
    print "$match<+$val> was val for $match<+$key>\n";  # array look-u
+p
    print "$match<_$val> was val for $match<_$key>\n";  # hash look-up

Which is far worse than what we have now.

---

1. They didn't select me to help Larry design Perl 6 just because I'm even weirder than he is, you know! Well, not solely on that basis, at least. ;-)

[theorbtwo]

 $fullname = $fullname{$id};
 $email    = $email   {$id};

---

We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book

[erikharrison]

Actually this has been hashed (I say, I say, that's a joke there, boy) out pretty thoroughly on the language list. The braces are neccessary because otherwise anonymous hash constructors seem to have no syntactic justification, and we need the brackets for anonymous array constructors. Plus there are strong historical reasons at work.

As for Larry's braces fetish, this is absolutely not true. Having designed a few mini languages myself, I can tell you that there isn't anything else to use. Braces already mean code, parens mean args, brackets mean array ref, and angles are ugly, so filehandles got the diamond and hashes got the braces because in early Perl it was pretty clear what they meant. The only reason Larry seems to have a braces fetish is that alot of the Apocalypses have dealt with blocks - closure, special CAPITAL blocks, switch statements, embedded code.

Cheers,
Erik

Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet

[Abigail-II]

{I}{like}{to}{put}{a}{space}{between}{an}{aggregate}{and}{its}{index}{
+because}{if}{you}{do}{not}{things}{get}{very}{hard}{to}{read}{Remembe
+r}{that}{Larry}{used}{to}{use}{English}{as}{an}{inspiration}{when}{he
+}{designed}{Perl}{Too}{bad}{he}{has}{choosen}{German}{as}{the}{way}{f
+or}{Perl6}{I}{fail}{to}{see}{why}{you}{think}{it}{is}{just}{one}{enti
+ty}{Unlike}{Perl1}{hashes}{are}{first}{class}{citizens}{A}{hash}{is}{
+something}{but}{a}{hash}{element}{is}{something}{else}{Just}{like}{an
+}{object}{is}{different}{from}{a}{method}{and}{a}{method}{is}{differe
+nt}{than}{its}{arguments}{Abigail}

[Anonymous Monk]

{ I }{ do }{ not }{ see }{ why }{ it }{ is }{ a }{ problem }{ when }{ you }{ can }{ choose }{ to }{  break }{ with }{ whitespace }{ inside }{ of }{ the }{ braces }