Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

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

by TheDamian (Priest)
on Jun 06, 2002 at 21:59 UTC ( #172375=note: print w/ replies, xml ) Need Help??


in reply to (ichi) 2.times('Re: ') Apocalypse 5 and regexes
in thread Apocalypse 5 and regexes

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.


Comment on Re: (ichi) 2.times('Re: ') Apocalypse 5 and regexes
Select or Download Code
(ichi) Re x 4: Apocalypse 5 and regexes
by ichimunki (Priest) on Jun 07, 2002 at 15:31 UTC
    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?).

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

      $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. ;-)
        This is very much a non sequitur. I have never bought the concept of baby perl because ones has soon to deal with adult code. In a sense I realize this is a chance because I have long lived in a closed source world without the opportunity of seing adult code propagated by openness of various flavors of free software. But this is also a challenge, first to master it, than to get it accepted from people without such exposure. Even when Perl demonstrates a keen understanding of Natural Language Principles.

        In the section "more is more" of your paper, speaking of the C++ language you critize the approach of teaching by subsetting. I am well aware that you strive to avoid the grammatical traps that you criticize in C++ but showed fixable. Larry and you choose the freeness of designing a new syntax instead of building on top of an existing one (unllike perl5 trapped in backward compatibility without any more acceptable degreea of liberty to grow) But really, does this notion of baby perl make sense without a nurturing motherwise environment? I am not speaking of social ones: perl mongers, YAPC (these two thanks to Kevin Lenzo and YAS), perl monks, and O'Reilly conference have been instrumental here. I am speaking of high level tools. Currently, we are trapped between Visual-Studio like environment or emacs/vi like. Even the bases, binding graphical toolit are not there. When KDE is getting a clear lead. The perl crowd is trapped in the oldish Tk or slowing moving to Gtk. I know that you, leaders, are already busy with the core of Perl but I feel that these outer peels of the onion don't get the attention they deserve... even if I see that a proof of concept Qt appli is bundled with parrot. Despite its long and useful life, Perl never got the exposure he desserve, and like linux did, must learn to be visible on the deskop

        Note: I must confess I have not recently followed Activestate progress but their tools seemed top heavy last time I checked..

        -- stefp -- check out TeXmacs wiki

        PS: someone talked of two languages side by side. I have the opposite opinion, A5 hints how can regular perl and so called regexes can mix and interact so intimately. I am eager to see that in action in your exegis.

        Sold! Especially easy sale since I wasn't the one who wanted to put spaces in between my %name and my {key}. :)

        I am very excited about the new match objects. These (along with the rest of the RE changes) are going to be a powerful factor in getting people into Perl6, I think.

        I get a little nervous seeing the polymorphous $match{key} and then thinking of a not-so-polymorphous %match{key} perhaps appearing next to it in a script. But I suspect this is more to do with objects (references, really) not getting their own sigil, instead references will look like scalars. I suppose one could say I'm still not thrilled with the sigils either way. I will be reading your papers--so at least my obstinacy here has exposed me to more resources-- and maybe I'll change my mind... certainly I don't consider myself a "clueful and competent" programmer, but I do think when there are an infinite number of classes into which an object can fall, having a special notation for just a few of them seems limiting (I count $, @, %, *,and &, but the $ looks like it will still be putting in overtime).

        Am I misunderstanding proposed object notation or in Perl6 won't there be some temptation to simply create all hashes and arrays anonymously (based on code seen so far: $match = {}; $match{key} = VALUE; will be valid syntax for what we used to write as $match = {}; $match->{key} = VALUE;)? Is it just my limited knowledge of the subject, or is Perl the only major programming language that goes to this much trouble to put type/class information into the symbols used to represent variables?

        And of course no matter how the language ends up looking someone will be unhappy with the changes. It's not a good compromise unless both parties to the dispute feel shortchanged, right? ;)

        Nice paper.

        I studied turing for a while and about the only thing that I liked was the error messages (an area that perl seems to be weak in) and the fact that loop iterators could _not_ exist outside of the loop. The latter at first glance was a pain in the butt, but after very little usage became very convenient and intuitive (that variable is transitory...)

        I hated the collections tho'. They may have been able to catch errors that are common amongst beginners but to do lots of things that would be natural in Pascal or C was a total nightmare (I was one of a few students in the class that had any real prior experience with C and Pascal, which may have been part of the problem). You ended up writing things in a totally cryptic way just to work around the restrictions (an experience that I repeated years later with VB and its lack of anything usefully close to a reference or pointer, you ended up using variant arrays to simulate pointer structures). I suppose Perl being the opposite (having very few restrictions, and the ones that are there you dont tend to notice) that makes me such a fan(atic).

        Im curious though, it seem to that your first rule, that of avoiding syntactic homonyms and synonyms would be diametrically opposed to perls philosophy of TMTOWTDI. Is this a correct reading of your point? How does perl stand up as a teaching language and how do you feel that perl meets your seven rules?

        Thanks for a very interesting paper,

        Yves / DeMerphq
        ---
        Writing a good benchmark isnt as easy as it might look.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://172375]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (7)
As of 2014-07-24 23:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls