Make your suggestions. But I think it is all off-base. None of this is
addressing some improvement in working conditions, ease of use, problems
in the language, etc.
1. I don't agree.
2. This mailing list is also for discussing stylistic improvements to
the language.
3. If you think
Make your suggestions. But I think it is all off-base. None of this is
addressing some improvement in working conditions, ease of use, problems
in the language, etc.
RANT
You are addressing stylistic issues. Issues that effect the way _I_ want
to work with the language. All of you are being
Simple solution.
If you want to require formats such as m/.../ (which I actually think is
a
good idea), then make it part of -w, -W, -ww, or -WW, which would be a
perl6
enhancement of strictness.
That's like having "use strict" enable mandatory perlstyle compliance
checks, and rejecting
The compatibility path for perl5 to perl6 is via a translator. It
is not expected that perl6 will run perl5 programs unchanged. The
complexity of the translator and the depth of the changes will be
decided by the decisions Larry makes.
This becomes not merely
"It is not expected that perl6
Tom Christiansen writes:
if you truly must--are important things. If the perl6:perl5
relationship is similar in breadth to what we saw in the perl5:perl4
one, then perhaps, maybe even probably, one will get away with it.
However, if the stretch is appreciably further, I don't think one
Jonathan Scott Duff wrote:
I think that Csubst is too syntactically close yet semantically far
from Csubstr that the evil demons of confusion will rear their ugly
heads.
I agree too, any suggestions are welcome. The fact that 'sub' and
'substr' are already taken makes this tough...
Given
On Mon, Aug 28, 2000 at 08:12:22AM -0700, Nathan Wiger wrote:
Jonathan Scott Duff wrote:
I think that Csubst is too syntactically close yet semantically far
from Csubstr that the evil demons of confusion will rear their ugly
heads.
I agree too, any suggestions are welcome. The fact
next if /\s+/ || /\w+/; next if match /\s+/ or match /\w+/;
Gosh this is annoying. I *really* don't want to have to type "match"
all the time. And now I have to use Cor rather than C||, which is
already ingrained in my head (I rarely use "or" or "and")
There are thirteen
Tom Christiansen wrote:
There are thirteen years of precedent, not to mention the millions of users,
who are completely accustomed to writing expressions like
next if /\s+/ || /\w+/;
It's nearly part of Perl's language signature. I wouldn't count
on this going away if you still
Tom Christiansen wrote:
But if *MOST* perl1 .. perl5 programs aren't going to work unchanged,
that means that most people's existing perl knowledge-base will no
longer be valid. That probably means that they aren't going to be
able to just type in the Perl that they already know, either,
On Mon 28 Aug, Tom Christiansen wrote:
It's nearly part of Perl's language signature. I wouldn't count
on this going away if you still think to call this "Perl". It is
of course much more likely in the renamed "Frob" language, however.
First off, this argument is just a little too
=head1 TITLE
Replace =~, !~, m//, and s/// with match() and subst()
In a marked oversight, I'd also like to note that tr// would be replaced
with trade:
Perl 5 Perl 6
--- --
$str =~ tr/a/b/;$new =
Perl6 RFC Librarian writes:
match; # all defaults (pattern is /\w+/?)
match /pat/;# match $_
match /pat/, $str; # match $str
match /pat/, @strs; # match any of @strs
When I was thinking about this very topic yesterday and today, I
came up
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace =~, !~, m//, and s/// with match() and subst()
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 27 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 164
Nathan Wiger writes:
Honestly, not sure. Although, there are two things I'd say about it:
1. I don't think it's a showstopper for this RFC, since the
feature you are addressing is actually a new piece of
functionality.
Hmm. This is exactly the same situation as with chomp()
Nathan Torkington wrote:
Hmm. This is exactly the same situation as with chomp() and somehow
chomp() can tell the difference between:
$_ = "hi\n";
chomp;
and
@strings = ();
chomp @strings;
Good point. I was looking at it from the general "What's wrong with how
@arrays are
16 matches
Mail list logo
