Exegesis 2 - Perl 6

[Ovid]

Damian Conway is busy rewriting code from the Perl Cookbook. He's writing it in Perl 6 to allow us to see how the migration will work. Check it out at http://www.perl.com/pub/2001/05/08/exegesis2.html.

For the most part, the code looks familiar. Even newer constructs aren't terribly difficult to figure out:

my int ($pre, $in, $post) is constant = (0..2);

And something that I appreciate: named and typed parameters!

sub insert (HASH $tree is rw, int $val) {
   ...
}

Admittedly, I appreciate the versatility of variadic functions, but sometimes we get bitten. This is a nice feature.

There's lots more there to dig through. Looks like Perl 6 is going to be very interesting. Enjoy!

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[princepawn]

My comments on the article:
• typed lexicals are great. they will reduce memory and increase speed. And allow Perl to even more powerfully bridge the gap between shell and C that perl was designed to.
• Damian sayeth

  like most other global punctuation variables, $/ has been banished from Perl 6

  I guess that means bye-bye to a lot of obfuscated Perl code. The globals really never affect most people's lives anway, except $|
• Damian sayeth

  (in Perl 6 -> is spelled .)

  Hmm, we have tons of code using ->. Also, the arrow stands out better. Whats purpose of this change? I don't like it.
• Damian sayeth

  The call to $node.Found would normally be a method call (in Perl 6 -> is spelled .). But since $node is just a regular unblessed hash, there is no Found method to call. So Perl treats the request as a property query instead and returns (an alias to) the corresponding property.

  This is an interesting fall-through property. But does it mean that execution time increases because it starts making run-time checks for methods before doing a hash lookup?
• Damian sayeth

  But then the serpent of OO entered the garden, and offered Perlkind the bitter fruit of subroutine and method calls: print $subref->(); print $objref->method(); Now the leading $ no longer indicated the type of value returned. And in beginners' Perl classes across the land there arose a great wailing and a gnashing of teeth.

  Wow, for all my efforts to detect inconsistencies in Perl, it never occurred to me that the dollar sign should by arguments of context imply a scalar return value. It was just so natural to use I never thought of how it broke that rule.

  I dont believe Damian mentioned how method calls would imply the type of their return values did he? Nothing like

  @objref->method()
  

  is on the horizon is it?

[tilly]

In order.
1. Optional typing systems are a nice idea, but I doubt they will be used much. For instance if you properly declare things in Common Lisp, it is supposed to be as fast as C. But most people don't do that, and those who do occasionally get good foot-shootage out of it. Besides which, the performance gains will probably not really materialize for a couple of iterations.
2. The global variables were ridiculous. The only one I would miss is $!. I am used to typing that...
3. Changing the arrow syntax brings Perl in line with the syntax used by virtually all other languages. And backwards compatibility is not an issue since Perl 5 code will run through the translator which supports the old syntax.
4. The fallback goes the other way. You are making a method lookup and it falls back to a hash lookup when no such method is found.
5. Again you have what Damian said exactly backwards. Perl will go from methods not saying what you get but everything else saying what you will get to having nothing say what you will get. So I suspect that if something like @object.method() is on the horizon it will be something like map {$_->method()} @object is today...

[tye]

1) The real win advertised (to my reading, which was a bit between the lines) was that something of type "int" would take up less space, so I doubt that will take interations to get working. Speed improvements may also eventually come (or not).

3) But how do you concatenate strings in Perl 6?

        - tye (but my friends call me "Tye")

[premchai21]

My responses to each item follow:
• Typed lexicals are okay, as long as there continue to be untyped lexicals also.
• What? $/ is gone? Darn. I really liked that variable.
• /me likes ->. I like all the operators the way they are, thank you.
• Ow! Provide an option to turn the hash fall-through off at least.
• @objref->method()? I certainly hope not.

[davorg]

What? $/ is gone? Darn. I really liked that variable.

It's gone as a global variable. It's now a property of each individual filehandle.

Which makes far more sense.

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

[tilly]

Several of these changes look like they are moving more towards like Ruby and Python today. Some of the automatic dereferencing things make me wonder whether Larry is toying with changing Perl's copy-by-value on assignment rule as well.

What do I mean by that?

Well in Perl 5 if you say:

$foo = $bar;

a new value is made of $bar and copied into $foo. If I later say:

$foo .= $baz;

then $foo is modified in place. By contrast in Ruby if you say:

foo = bar;

you copy by reference. So later on if you say:

foo += baz

that expands to:

foo = foo + baz;

and you create a new string and copy a reference of that to foo. To get the fast in-place modification you have to instead try:

foo << baz;

which will also modify bar.

Anyways if Perl changed this basic semantic, here is what would be affected:

1. You save memory.
2. Copying data speeds up.
3. Incrementally building large strings slows down unless you provide an operator for it with explicit side-effects.
4. Subroutines that expect to change their arguments by reference would be hard to rewrite from Perl 5 to Perl 6.
Does anyone have any idea what Larry's thinking is on this issue? Will Perl continue to copy-by-value on assignment?

[tye]

After reading the linked article, I have one major reaction...

I like that Perl has borrowed from many languages/tools including C, sh, awk, sed, even ADA. With Perl6, I'm glad to see that we are finally borrowing a lot from Visual BASIC.

(It's what they call a "joke," son. Laugh)

        - tye (but my friends call me "Tye")

[mwp]

Wow. Thanks for linking this, Ovid... I think everyone should go and take a look. Damian does a great job, as usual.

While I was participating in the mailing list traffic for Perl 6, I fought against a lot of things that folks like Damian wanted to implement. (*cough* dot-syntax *cough*) Unfortunately, it seems they've decided to go ahead and do it anyhow... ah well. This article spells out a lot of things that even Larry's Apocalypse missed, and helped me understand how things are going to work.

I'm not sure I'm too happy about it, but I'm willing to give them a chance. Not that my opinion matters anyhow, but I like Perl and hope to go on using it, and that probably means coming to terms with the new version.

My two shakes...

'kaboo

[Masem]

While I'm looking forward to some of the features that 6 will make available to us without moving too far away from core perl functionality, the last statement on that page worries me alot (I know, he meant it in tongue-in-cheek:)

Ninety-eight percent backward compatibility even without an automatic p52p6 translator ... pretty slick!

While 98% might be a good number to brag about, we all know that it only takes one character out of thousands to cause an error (say, a mispelled variable name). Sure, from Larry's docs, it says that you'll need a special line near the top of any perl 6 or 5 program to trigger the appropriate action so that perl5 code will not try to be directly run under perl 6 without problems. But unless we see that special line of the code, it can be hard to tell what an inexperienced PM user will mean, whethey they meant %hash->{key} as a typo or a perl6-ism. When perl 6 is no longer just going to be out RSN but is actually avaialable and people developing for it, we here at PM are going to have a dickens of a time trying to help support it particularly if the user does not say up front which they are using.

So a possible suggestion (does not need to be added now), is for any section on PM where code is typically posted (SOPW, Q&A, Code, Craft, etc), add a radio group of buttons which reads "Perl 5", "Perl 6", and "Perl 5 and 6", and require the user to specify this before posting. The posted node can then put this info near the top or some other means to allow the reader to know what version of perl they're working with. This might even extend well into the Super Search features so that help only for perl 6 can be gotten or the like.

Update It might also be good to add "Perl 4 or lower" to that list, since as another monk has told me, that is still supported at some places and discussed here.

---

Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain

[John M. Dlugosz]

I noticed something similar on a page that compared Perl 5 and Perl 6 code. The surrounding text indicated which block was which, as well as pseudocode and expo-only stuff. I thought it could be color coded.

How about adding an optional property to the CODE tag? E.g. <CODE class=perl6> will show some styleistic change such as color or margin stripe. The actual meaning can be per-user, expanded in a style sheet.

In any case, I think a global 5/6 switch is not enough, since code can be mixed in one node.

—John

[swiftone]

Just thought I'd add my impressions to the pile.

Contextually, on the whole I'm looking forward to Perl6.

• I'm not a fan of the dot operator. I find it hard to "pick out" when scanning code. The arrow operator is more intuitive to me. Oh well.
• I'm leery of the "prompts" operation. That seems like it should either be dropped as bloat, or a more vague property, such as a hook called when inputting/outputting that we can fill in our own routine for. I'm very interested to see how efficiency is maintained with this.
• I'm very happy to see subroutine argument passing done better. I think the rather kludgy perl5 method leads to more global variables and less maintainable code. I think this is the most significant improvement of all.
• I'm a little confused by the properties. Is "%node{VALUE}  = $val is Found(0);" identical to $val.Found=0; %node{VALUE}=$val;"?
• Am I the only one finding the is syntax confusing? I think it has great potential (Perl has always impressed me by using English), but I'm a bit perplexed...
• Along the same note, I'm a little disappointed with $tree is rw and the prop accessor. Is there a reason we can't give these English terms? Saving keystrokes is all well and good, but not at the expense of readability. btw may not have been the ideal choice, but something linguisticly like that appeals to me.
• return 0 is true; Obfuscation will love this one :) Only from the minds of perl programmers. (said with pride)
• I'm very interested in finding out the string concat operator and the array slice notation. Clarity will win a lot of points with me. (Maybe we should make perl parsers keel over and die by using ++ for the string concat?)
• If the sigil is no longer helping to determine context, does that mean we are going to have an increase in @{[$foo->bar()]} uglyness?
• Damian mentions how @{$zref}{'b','c'}; evaluates under perl5, but not the equivilent under perl6. I much prefered the idea of one name for all types of a variable (i.e. $foo and @foo are the same variable in different contexts), with the sigil indicating return value, but I guess it's my own fault for not participating :)

[John M. Dlugosz]

I emailed Damian directly with some questions on the text, since he doesn't read Perlmonks. He updated the page fixing a couple typos and code errors ("My mental simulation of the compiler didn't catch that bug! Thanks").

—John