http://qs321.pair.com?node_id=172855


in reply to (ichi) Re x 4: Apocalypse 5 and regexes
in thread Apocalypse 5 and regexes

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

[download]

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";

[download]

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";

[download]

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";    # ???

[download]

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

[download]

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. ;-)

Replies are listed 'Best First'.
Perl6, baby perl and nurturing environment
by stefp (Vicar) on Jun 09, 2002 at 02:59 UTC
    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.

[reply]
      I have never bought the concept of baby perl because ones has soon to deal with adult code.

      To the contrary, it seems to me that most people who use Perl at some point never deal with, let alone learn to handle, "adult code". Interview people who list Perl on their resume (and actually used it) and see how many have not, for instance, learned how references and objects work.

      Even though this is not a particularly esoteric feature either of Perl or programming, I am confident that you will find that most have not. And God forbid that you should ask about a feature like closures which has not been hyped in various big name languages for the last decade. Most people at least feel obligated to say that they have heard of OO and planned to learn it at some point...

[reply]
(ichi) Re x 6: Apocalypse 5 and regexes
by ichimunki (Priest) on Jun 10, 2002 at 16:54 UTC
    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? ;)

[reply]
[d/l]
[select]
Re: Re: (ichi) Re x 4: Apocalypse 5 and regexes
by demerphq (Chancellor) on Jun 14, 2002 at 11:22 UTC
    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.

[reply]

In Section Meditations