Re: Exegesis 2 - Perl 6
by princepawn (Parson) on May 16, 2001 at 05:11 UTC
|
| [reply] [d/l] [select] |
|
In order.
- 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.
- The global variables were ridiculous. The only one
I would miss is $!. I am used to typing that...
- 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.
- 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.
- 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...
| [reply] [d/l] [select] |
|
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")
| [reply] |
|
|
|
|
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.
| [reply] [d/l] |
|
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
| [reply] |
Re (tilly) 1: Exegesis 2 - Perl 6
by tilly (Archbishop) on May 16, 2001 at 06:12 UTC
|
$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:
- You save memory.
- Copying data speeds up.
- Incrementally building large strings slows down unless
you provide an operator for it with explicit side-effects.
- 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? | [reply] [d/l] [select] |
(tye)Re: Exegesis 2 - Perl 6
by tye (Sage) on May 16, 2001 at 04:50 UTC
|
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")
| [reply] |
Re: Exegesis 2 - Perl 6
by mwp (Hermit) on May 16, 2001 at 05:23 UTC
|
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 | [reply] |
Suggestion for PM Re: Exegesis 2 - Perl 6
by Masem (Monsignor) on May 16, 2001 at 15:32 UTC
|
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 - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
| [reply] [d/l] |
|
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
| [reply] |
Re: Exegesis 2 - Perl 6
by swiftone (Curate) on May 17, 2001 at 00:25 UTC
|
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 :)
| [reply] [d/l] [select] |
Errata Re: Exegesis 2 - Perl 6
by John M. Dlugosz (Monsignor) on May 22, 2001 at 18:36 UTC
|
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 | [reply] |