Perl 6 RFCs

Recently I visited the Perl6 development site and downloaded some of the RFCs. I found RFC 164 very interesting. Its title is 'Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()'. I think that it is not a good idea. We like m//, s/// and tr// in this way. This effort would make one-liners turn into ten-liners. Not to mention obfuscated code. But the main problem is: our brain is accustomed to read Perl code. It is harder to read:

next if match /\s+/ or match /\w+/;
# than
next if /\s+/ || /\w+/;
[download]

What do You think?

<-- z0d -->

Comment on Perl 6 RFCs Select or Download Code

Replies are listed 'Best First'.
(tye)Re: Perl 6 RFCs by tye (Sage) on Apr 13, 2001 at 18:12 UTC
Well I hope they pick another name besides subst() as that is just way too close to substr() [so close that I had to delete the "r" that my fingers automatically threw on the end when I typed it]. - tye (but my friends call me "Tye")	[reply]
Re: Perl 6 RFCs by Fingo (Monk) on Apr 13, 2001 at 15:53 UTC
Well, knowing the way Perl works so far, they will allow backwards compatibility. So the `match()` would probably be adopted by perl teachers to make it easier to read for newbies. (IE most beginers guides explain `$_` later to make the examples easier to understand.	[reply] [d/l] [select]
Re: Perl 6 RFCs by Masem (Monsignor) on Apr 13, 2001 at 18:44 UTC
There will be backwards compatibility, so us 'old timers' of perl5 will be happy. However, I suspect that if implemented, the first few 6.0.x releases will be solving a lot of problems with breaking the old code, thanks to how this RFC suggests that "//" and "=~" will be treated. Most interesting, "=~" appears to be more general, and will take the lhs arguement, use it as the 'next' arguement on the rhs, then set the rhs result back to the variable on the lhs, much like =+ and friends. Eg (as the RFC gives): `@array =~ sort { $a <=> $b }; #eqivalent to: # @array = sort { $a <=> $b } @array;` [download] But I agree with tye that subst and substr are too dang close and are going to cause more problems than this RFC alone. "Sub" or "subs" might be good enough, but that's up to the Perl 6 committee. 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]
Re: Perl 6 RFCs by michellem (Friar) on Apr 14, 2001 at 20:17 UTC
I have mixed feelings. In reading the RFC, there were a few examples I liked alot, like: `# Some become easier and more consistent... ($str = $_) =~ s/\d+/&func/ge; $str = subst /\d+/&func/ge; ($new = $old) =~ tr/a/z/; $new = trade /a/z/, $old; # And these are pretty cool... foreach (@old) { @new = subst /hello/X/gi, @old; s/hello/X/gi; push @new, $_; } foreach (@str) { @new = trade /a-z/A-Z/, @str; tr/a-z/A-Z/; push @new, $_; } $gotit = 1; print "Got it" if match /\w+/, @st +r; foreach (@str) { undef $gotis unless /\w+/; } print "Got it" if $gotit;` [download] So there are some advantages to be gained here. Problem is, if people mix standards in their code (ie using m/// when it makes things short and easy, but using match() when that makes things easy) is that going to make it harder to read code over time? (I guess that might always be a problem with backwards compatibility...)	[reply] [d/l]


go ahead... be a heretic
	PerlMonks