Re: RFC 170 (v1) Generalize =~ to a special-purpose assignment operator
On Tue, 29 Aug 2000, Nathan Wiger wrote: > David Nicol and I were brainstorming offline, and came up with a cool > extension: ~=. These new operator would do a similar thing to =~ as > described by the RFC, only LEFT padding the args: > > $stuff =~ dojunk(@args); # $stuff = dojunk(@args, $stuff); > $stuff ~= dojunk(@args); # $stuff = dojunk($stuff, @args); > > The position of the ~ tells you how args are filled in: if it's on the > left, then they're filled in to the left. If they're on the right, then > they're filled in to the right. Quite flexible, IMO. This would be bad for someone reading the code, as it would take extra concentration to tell a "~=" from a "=~"; right now, a "=" with a "~", I just know what it is, without having to determine the order. -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain
Re: RFC 165 (v1) Allow Varibles in tr///
Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis pered: | > > The way tr/// works is that a 256-byte table is constructed at compile | > > time that say for each input character what output character is | > | > Speaking of which, what's going to happen when there are more than 256 | > values to map? | | It's already happened, but I forget the details. Let me see if I understand this correctly. For every tr/// in a program, 256 bytes have to be allocated? Even if I only do something like tr/a/A/? And, it is going to get worse for UTF8/UTF16? Is this really the optimal solution for this (sorry, this is probably going into -internals space). Seems to me that we could very quickly end up with a really large memory image. -spp
Re: RFC 165: Allow variables in a tr///
Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis pered: | | > Would there be any interest in adding these two ideas to this RFC: | > | > 1) tr is not regex function, so it should be regularized to | > | >tr(SEARCH, REPLACE, MOD, STR) | | MOD should be last, because you're frequently going to want to omit MOD. Ok, that's fine with me. tr(SEARCH, REPLACE, STR, MOD) - 'standard way' tr(SEARCH, REPLACE, STR)- 'no modifiers' tr(SEARCH, REPLACE) - 'no modifiers, and default to $_' tr(SEARCH, REPLACE, $_, MOD)- have to use all four if modifiers but $_ I just wasn't sure which would be omitted more often, the MOD or the STR. -spp
Re: RFC 165: Allow variables in a tr///
Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED] m> whispered: | >The // tend to confuse people and make them expect tr to operate as a | >regular expression. | | So what? q/.../ is not a "regex function" either. These are all | pick-you-own-quotes function. This makes no sense. Personally, I would say that q/.../ and friends were a bad idea. A lot of non-gurus see /.../ (whatever comes before it) and their first impression is that it has something to do with regex. I would suggest that anything that isn't a regex should not use /.../. Make q, qq, etc use matched pairs. Make tr look like a regular function and do tr(SEARCH, REPLACE, MOD, STR). It just seems more orthagonal to me. -spp
Re: Overlapping RFCs 135 138 164
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> ($foo = $bar) =~ s/x/y/; will never make much sense to me. TC> What about these, which are much the same thing in that they all TC> use the lvaluability of assignment: TC> chomp($line = ); TC> ($foo = $bar) += 10; that should be a much clearer: $foo = $bar + 10; TC> ($foo += 3) *= 2; that is way too many assignment ops. better is the normalized $foo = ($foo + 3) * 2; TC> $n = select($rout=$rin, $wout=$win, $eout=$ein, 2.5); who uses select directly anymore? use a module! :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: Overlapping RFCs 135 138 164
Steve Fink wrote: > > Hm. Larry didn't really like anything that would reverse the order of > the pattern and the expression to be matched against, and I think I > agree at least that it should always be possible to put the direct > object at the beginning, preferably in a way usable by more than just > regex-related operators. Agreed. v2 of RFC 164 supports this syntax. > My problem with RFC138 disappearing into RFC164 is that I strongly > dislike the idea of losing // and having to use the five-letter match() > all the time. Agreed too. Again, v2 I believe should address all these concerns. It retains all of Perl 5 syntax plus much more that can be extended. I think you'll like it. And comments are always welcome!! These are "Requests for Comments" after all. ;-) -Nate
Re: RFC 170 (v1) Generalize =~ to a special-purpose assignment operator
> This RFC proposes a simple use for C<=~>: as a last-argument rvalue > duplicator. What this means is that an expression such as this: > >$value = dostuff($arg1, $arg2, $value); > > Could now be rewritten as: > >$value =~ dostuff($arg1, $arg2); David Nicol and I were brainstorming offline, and came up with a cool extension: ~=. These new operator would do a similar thing to =~ as described by the RFC, only LEFT padding the args: $stuff =~ dojunk(@args); # $stuff = dojunk(@args, $stuff); $stuff ~= dojunk(@args); # $stuff = dojunk($stuff, @args); The position of the ~ tells you how args are filled in: if it's on the left, then they're filled in to the left. If they're on the right, then they're filled in to the right. Quite flexible, IMO. -Nate
RFC 164 (v2) Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last-Modified: 29 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 164
Status: Developing
=head1 CHANGES
1. Added 100% backwards-compatible syntax
2. Included C replacement for C
3. Expanded examples and contexts
=head1 ABSTRACT
Several people (including Larry) have expressed a desire to get rid of
C<=~> and C. This RFC proposes a way to replace C, C,
and C with three new builtins, C, C, and C.
It also proposes a way to allow full backwards-compatible syntax.
=head1 DESCRIPTION
=head2 Overview
Everyone knows how C<=~> and C work. Several proposals, such as RFCs
135 and 138, attempt to fix some stuff with the current pattern-matching
syntax. Most proposals center around minor modifications to C and
C.
This RFC proposes that C, C, and C be dropped from the
language, and instead be replaced with new C, C, and
C builtins, with the following syntaxes:
$res [, $res] = match /pat/flags, $str [, $str];
$res [, $res] = subst /pat/new/flags, $str [, $str];
$res [, $res] = trade /pat/new/flags, $str [, $str];
These subs are designed to mirror the format of C, making them
more consistent. Unlike the current forms, these return the modified
string, leaving the input C<$str> alone.
Context modifies the return values just as Perl 5 context does, with
some extensions:
1. If called in a void context, they act on and modify C<$_>,
consistent with current behavior.
2. If called in a scalar context, C returns the number
of matches (like now), and the rest return the first (or
only) string.
3. If called in a list context, a list of the modified strings
will be returned.
4. If called in a numeric context, they all return the number
of substitutions made.
Extra arguments can be dropped, consistent with C and many other
builtins:
match; # all defaults (pattern is /\w+/)
match /pat/;# match $_
match /pat/, $str; # match $str
match /pat/, @strs; # match any of @strs
subst; # strip leading/trailing whitespace
subst /pat/new/;# sub on $_
subst /pat/new/, $str; # sub on $str
subst /pat/new/, @strs; # return array of modified strings
trade; # nothing
trade /pat/new/;# tr on $_
trade /pat/new/, $str; # tr on $str
trade /pat/new/, @str; # return array of modified strings
These new builtins eliminate the need for C<=~> and C altogether,
since they are functions just like C, C, C, and so
on. There are also shortcut forms, see below.
Sometimes examples are easiest, so here are some examples of the new
syntax:
Perl 5 Perl 6
--
if ( /\w+/ ) { } if ( match ) { }
die "Bad!" if ( $_ !~ /\w+/ ); die "Bad!" if ( ! match );
($res) = m#^(.*)$#g; ($res) = match #^(.*)$#g;
next if /\s+/ || /\w+/; next if match /\s+/ or match /\w+/;
next if ($str =~ /\s+/) || next if match /\s+/, $str or
($str =~ /\w+/) match /\w+/, $str;
next unless $str =~ /^N/;next unless match /^N/, $str;
$str =~ s/\w+/$bob/gi; $str = subst /\w+/$bob/gi, $str;
s/\w+/this/; subst /\w+/this/;
tr/a-z/Z-A/; trade /a-z/Z-A/;
$new =~ tr/a/b/; $new = trade /a/b/, $new;
# 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, $_;
}
foreach (@str) { print "Got it" if match /\w+/, @str;
if (/\w+/) { $gotit = 1 };
}
print "Got it" if $gotit;
This gives us a cleaner, more consistent syntax. In addition, it makes
several things easier, is more easily extensible:
&callsomesub(subst(/old/new/gi, $mystr));
$str = subst /old/new/i, $r->getsomeval;
and is easier to read English-wise. However, it requires too much
typing. For that reason, we include the shortcut form as well:
=head2 Shortcut Form
RFC 139 describes a way that the C syntax can be expanded to any
function. So, to gain backwards compatibility, we simply allow this
syntax along with the shortcut function names C, C, and C [1]:
Shortcut FormBuiltin
--
s/\w+/W/g;
Re: Overlapping RFCs 135 138 164
>What about these, which are much the same thing in that they all
>use the lvaluability of assignment:
And don't forget:
for (@new = @old) { s/foo/bar/ }
--tom
Re: Overlapping RFCs 135 138 164
>($foo = $bar) =~ s/x/y/; will never make much sense to me. What about these, which are much the same thing in that they all use the lvaluability of assignment: chomp($line = ); ($foo = $bar) += 10; ($foo += 3) *= 2; func($diddle_me = $protect_me); $n = select($rout=$rin, $wout=$win, $eout=$ein, 2.5); --tom
Re: Overlapping RFCs 135 138 164
> > RFC138: Eliminate =~ operator. > > > RFC164: Replace =~, !~, m//, and s/// with match() and subst() > > Which I could see unifying. I'd ask people to wait until v2 of RFC 164 > comes up. It may well include everything from RFC 138 already. Hm. Larry didn't really like anything that would reverse the order of the pattern and the expression to be matched against, and I think I agree at least that it should always be possible to put the direct object at the beginning, preferably in a way usable by more than just regex-related operators. I'm not so convinced that that is always the best order, but weakening RFC138 to propose only an alternative would force me to rename it. So I'll probably just withdraw RFC138 and ponder whether to submit another one with a different name that proposes something similar as an option to =~ or whatever it becomes. My problem with RFC138 disappearing into RFC164 is that I strongly dislike the idea of losing // and having to use the five-letter match() all the time. So Nate is welcome to any or all of the ideas in RFC138, but I don't think RFC164 will ever be something that fills the need I was addressing with RFC138. I gotta have my perl -lne 'print $1 if /count=(\d+)/'. ($foo = $bar) =~ s/x/y/; will never make much sense to me. But I can live with it.
RFC 170 (v1) Generalize =~ to a special-purpose assignment operator
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Generalize =~ to a special-purpose assignment operator
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 170
Status: Developing
Requires: RFC 164
=head1 ABSTRACT
Currently, C<=~> is only available for use in specific builtin pattern
matches. This is too bad, because it's really a neat operator.
This RFC proposes a simple way to make it more general-purpose.
=head1 DESCRIPTION
First off, this assumes RFC 164. Second, it requires you drop any
knowledge of how C<=~> currently works. Finally, it runs directly
counter to RFC 139, which proposes another application for C<=~>.
This RFC proposes a simple use for C<=~>: as a last-argument rvalue
duplicator. What this means is that an expression such as this:
$value = dostuff($arg1, $arg2, $value);
Could now be rewritten as:
$value =~ dostuff($arg1, $arg2);
And C<$value> would be implicitly transferred over to the right side as
the last argument. It's simple, but it makes what is being operated on
very obvious.
This enables us to rewrite the following constructs:
($name) = split /\s+/, $name;
$string = quotemeta($string);
@array = reverse @array;
@vals = sort { $a <=> $b } @vals;
$string = s/\s+/SPACE/, $string;# RFC 164
$matches = m/\w+/, $string; # RFC 164
@strs = s/foo/bar/gi, @strs;# RFC 164
As the shorter and more readable:
($name) =~ split /\s+/;
$string =~ quotemeta;
@array =~ reverse;
@vals =~ sort { $a <=> $b };
$string =~ s/\s+/SPACE/;# looks familiar
$string =~ m/\w+/; # this too [1]
@strs =~ s/foo/bar/gi; # cool extension
It's a simple solution, true, but it has a good amount of flexibility
and brevity. It could also be the case that multiple values could be
called and returned, so that:
($name, $email) = special_parsing($name, $email);
Becomes:
($name, $email) =~ special_parsing;
Again, it's simple, but seems to have useful applications.
=head1 IMPLEMENTATION
Simplistic (hopefully).
=head1 MIGRATION
This introduces new functionality, which allows backwards compatibility
for regular expressions. As such, it should require no special
translation of code. This RFC assumes RFC 164 will be adopted (which it
may not be) for changes to regular expressions.
True void contexts may also render some parts of this moot, in which
case coming up with a more advanced use for C<=~> may be desirable.
=head1 NOTES
[1] That m// one doesn't quite work right, but that's a special case
that I would suggest should be caught by some other part of the grammar
to maintain backwards compatability (like bare //).
=head1 REFERENCES
RFC 164: Replace =~, !~, m//, and s/// with match() and subst()
RFC 139: Allow Calling Any Function With A Syntax Like s///
Re: RFC 165 (v1) Allow Varibles in tr///
> > The way tr/// works is that a 256-byte table is constructed at compile > > time that say for each input character what output character is > > Speaking of which, what's going to happen when there are more than 256 > values to map? It's already happened, but I forget the details.
Re: RFC 165 (v1) Allow Varibles in tr///
On Tue, 29 Aug 2000 20:36:46 -0400, Bryan C.Warnock wrote: >> The way tr/// works is that a 256-byte table is constructed at compile >> time that say for each input character what output character is > >Speaking of which, what's going to happen when there are more than 256 >values to map? A bigger table. For 16-bit characters, you'd need 2 x 64k = a 128k bytes table. Well, in principle. -- Bart.
Re: RFC 165 (v1) Allow Varibles in tr///
On Tue, 29 Aug 2000, Mark-Jason Dominus wrote: > I think the reason this hasn't been done before it because it's *not* > quite straightforward. > > The way tr/// works is that a 256-byte table is constructed at compile > time that say for each input character what output character is Speaking of which, what's going to happen when there are more than 256 values to map? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 110 (v3) counting matches
>I think what Tom means is that (for example)
>print "${\(localtime())}\n";
>does not produce "Tue Aug 29 19:15:55 2000".
Yup. You are hereby appointed tchrist-to-lateur translator. :-)
--tom
Re: RFC 110 (v3) counting matches
>>>p.s. Has anybody already suggested that we ought to have a nicer
>>>solution to execute perl code inside a string, replacing "${\(...)}" and
>>>"@{[...]}", which also won't ever win a beauty contest? Oops, wrong
>>>mailing list.
>>
>>The first one doesn't work, and never did. You want
>>@{[]} and @{[scalar ]} instead.
>"Doesn't work"?
> print "The sum of 1 + 2 is ${\(1+2)}.\n";
>-->
> The sum of 1 + 2 is 3.
>I'm surprised your wouldn't have known this. The principle is the same:
>"${...}" expects a scalar reference inside the block, and '\' provides
>one. Of course, there shouldn't be a real multi-element list inside the
>parens, but just one scalar. And often, the parens aren't needed.
I'm surprised that you still don't understand. Notice what I showed
you for the replacement above: @{[scalar ]}.
Using ${\(...)} doesn't work in the sense that contrary to popular
belief, it fails to provide a scalar context to the contents of
those parens. Thus ${ \( fn() ) } is still calling fn() in list
context, not scalar context. Witness:
sub fn { sprintf "called in %s context", wantarray ? "list" : "scalar" }
print "Test 1: ";
print "@{ [fn()] }\n";
print "Test 2: ";
print "${ \(fn()) }\n";
print "Test 3: ";
print "@{ [scalar fn()] }\n";
That, when executed, yields:
Test 1: called in list context
Test 2: called in list context
Test 3: called in scalar context
*That's* why test 2 "doesn't work".
--tom
Re: RFC 110 (v3) counting matches
> >>solution to execute perl code inside a string, replacing "${\(...)}" and
> >
> >The first one doesn't work, and never did. You want
> >@{[]} and @{[scalar ]} instead.
>
> "Doesn't work"?
I think what Tom means is that (for example)
print "${\(localtime())}\n";
does not produce "Tue Aug 29 19:15:55 2000".
Anyway, this is off-topic for this mailing list, so let's put an end
to this part of the discussion unless it relates somehow to regexes.
Re: RFC 110 (v3) counting matches
On Tue, 29 Aug 2000 16:21:35 -0600, Tom Christiansen wrote:
>>p.s. Has anybody already suggested that we ought to have a nicer
>>solution to execute perl code inside a string, replacing "${\(...)}" and
>>"@{[...]}", which also won't ever win a beauty contest? Oops, wrong
>>mailing list.
>
>The first one doesn't work, and never did. You want
>@{[]} and @{[scalar ]} instead.
"Doesn't work"?
print "The sum of 1 + 2 is ${\(1+2)}.\n";
-->
The sum of 1 + 2 is 3.
I'm surprised your wouldn't have known this. The principle is the same:
"${...}" expects a scalar reference inside the block, and '\' provides
one. Of course, there shouldn't be a real multi-element list inside the
parens, but just one scalar. And often, the parens aren't needed.
--
Bart.
Re: RFC 165 (v1) Allow Varibles in tr///
Tom Christiansen wrote: > > >tr///e is the same as s///g: > > > >tr/$foo/$bar/e == s/$foo/$bar/g > > I suggest you read up on tr///, sir. You are completely wrong. Yep, sorry. I tried to hit cancel and hit send instead. I'll shut up now. -Nate
Re: RFC 165: Allow variables in a tr///
> One thing to be careful of there is thread safety. You can't hand > the data off the syntax node (the one with the tr op on it), because > tr/$foo/$bar/ wouldn't work for several threads in it at the same > time then. Certainly, but that is true for everything else that is in the op node, which includes the pattern in m/.../o. One of my hopes is that the Perl 6 internals will fix this long-standing error, in which case the solution they adopt will apply to tr///e in the same way that it will to m//o and ?? and X...Y and all the rest.
Re: RFC 165 (v1) Allow Varibles in tr///
>tr///e is the same as s///g: > >tr/$foo/$bar/e == s/$foo/$bar/g I suggest you read up on tr///, sir. You are completely wrong. --tom
Re: RFC 165: Allow variables in a tr///
>Building a tr/// table is much much simpler and much less work than >compiling a regex, but we don't make people write >eval " \$s =~ m/$pat/ " >when they want to interpolate a string into a regex at run time. >Instead, we take care of it transparently. tr/// could easily be made >to work the exact same way. One thing to be careful of there is thread safety. You can't hand the data off the syntax node (the one with the tr op on it), because tr/$foo/$bar/ wouldn't work for several threads in it at the same time then. --tom
Re: RFC 110 (v3) counting matches
>p.s. Has anybody already suggested that we ought to have a nicer
>solution to execute perl code inside a string, replacing "${\(...)}" and
>"@{[...]}", which also won't ever win a beauty contest? Oops, wrong
>mailing list.
The first one doesn't work, and never did. You want
@{[]} and @{[scalar ]} instead.
And I can't see you coming up with anything that's "better" than
this, since this already works and follows directly from understanding
of Perl. Too often on these lists anything that "follows directly"
one seeks to special-case with brand-new syntax. This is a poor
general principle.
This has nothing to do with regexes (although it could if we had
@foo normally interpolate into patterns with $" = '|' instead, which
would break that), so when you find a better list to discuss it on,
I'll mumble again.
--tom
Re: RFC 165 (v1) Allow Varibles in tr///
> Note that the 256-byte thing is out the window with Unicode, but that > I no longer know how it is done. Thanks. I was going to mention that, but I forgot before I sent the message. The 256-byte thing is still in place with unicode, but it's only used on byte strings, not on UTF8 strings. Since the byte/UTF8 thing might be going out the window in Perl 6, it's hard to speculate about the implications for tr///. But I think my main point still stands: We don't have any problem with reconstructing a (potentially humongous) regex structure at run time, so I don't see why we should have a problem with reconstructing the tr/// tables at run time.
Re: RFC 165 (v1) Allow Varibles in tr///
> Accepting variables in tr// makes no sense. It defeats the purpose of > tr/// - extremely fast, known transliterations. The propsal extends tr/// to handle extremely fast transliterations whose nature is not known at compile time. > > tr///e is the same as s///g: > > tr/$foo/$bar/e == s/$foo/$bar/g It is nothing of the sort. $foo = 'fo'; $bar = 'ba'; $s1 = $s2 = "foolproof"; $s1 =~ tr/$foo/$bar/e; # The result is "baalpraab"; $s2 =~ s/$foo/$bar/g; # The result is "baolproof"
Re: RFC 165: Allow variables in a tr///
Tom Christiansen wrote: > > There is *nothing*wrong* with any of them, and to suggest breaking > them is extremely demoralizing. Agreed. 100%. But wait for the RFC, I think you'll find you might actually like it. It doesn't break *any* of Perl 5's regex expressions. Not one. And it adds a whole bunch of neat stuff. -Nate
Re: RFC 110 (v2) counting matches
Mark-Jason Dominus wrote: > > It occurs to me that since none of the capital letters are taken, we > could adopt the convention that a capital letter as a regex modifier > will introduce a *word* which continues up to the next comma. Excelsior! -- David Nicol 816.235.1187 [EMAIL PROTECTED] Yum, sidewalk eggs!
Re: RFC 165 (v1) Allow Varibles in tr///
Mark-Jason Dominus wrote: > > I think the reason this hasn't been done before it because it's *not* > quite straightforward. Before everyone gets tunnel vision, let me point out one thing: Accepting variables in tr// makes no sense. It defeats the purpose of tr/// - extremely fast, known transliterations. tr///e is the same as s///g: tr/$foo/$bar/e == s/$foo/$bar/g I don't think this RFC accomplishes anything, personally. -Nate
Re: RFC 165: Allow variables in a tr///
> When does the structure get built? That's why eg. tr[a-z][A-Z] > brooks no variables, for it is solely at compile time that these > things occur, and why you must resort to delayed compilation via > eval qq/.../ to prod the compiler into building you a new one. Certainly. But if there were no variable interpolation for regexes, you could make the same argument about regexes. I don't see any reason why the regex solution couldn't or shouldn't be extended to tr/// also. If the pattern and replacement sets contain variables, then table construction can be deferred until run time; if there are no variables, the table is computed at compile time. Building a tr/// table is much much simpler and much less work than compiling a regex, but we don't make people write eval " \$s =~ m/$pat/ " when they want to interpolate a string into a regex at run time. Instead, we take care of it transparently. tr/// could easily be made to work the exact same way. > Maybe you want qt/.../.../ or something. I don't think a new notation is necessary in this case. All that's needed is a small extension to the existing semantics, in a direction that has already been thoroughly investigated.
Re: RFC 165: Allow variables in a tr///
Perl has always excelled at convenience. Look at this code:
while (<>) {
for (split) {
s/foo/bar/g;
next if /glarch/i;
tr/aeiou/eioua/s;
print;
}
}
There is *nothing*wrong* with any of them, and to suggest breaking
them is extremely demoralizing. Don't you people have anything
that's *broken* to fix? Sheesh.
I fully expect to see an RFC for each and every lovely Perlism
that isn't in C, Python, and Java. Well, Perl *isn't* C, Python,
or Java, and there's no need to freak out just because of this!!
--tom
Re: RFC 165: Allow variables in a tr///
>But I think this is worth discussing further, because it neatly
>accomplishes the goal of the RFC in a straightforward way:
>tr('a-z', 'A-Z', $str)
>replaces a-z with A-Z, and
>tr($foo, $bar, $str)
>replaces the characters from $foo with the characters from $bar.
>No special syntax is necessary.
When does the structure get built? That's why eg. tr[a-z][A-Z]
brooks no variables, for it is solely at compile time that these
things occur, and why you must resort to delayed compilation via
eval qq/.../ to prod the compiler into building you a new one.o
Maybe you want qt/.../.../ or something.
--tom
Re: RFC 165: Allow variables in a tr///
>Would there be any interest in adding these two ideas to this RFC: >1) tr is not regex function, so it should be regularized to > tr(SEARCH, REPLACE, MOD, STR) >The // tend to confuse people and make them expect tr to operate as a >regular expression. So what? q/.../ is not a "regex function" either. These are all pick-you-own-quotes function. This makes no sense. --tom
Re: Overlapping RFCs 135 138 164
Mark-Jason Dominus wrote: > > RFC135: Require explicit m on matches, even with ?? and // as delimiters. This one is along a different line from these two: > RFC138: Eliminate =~ operator. > RFC164: Replace =~, !~, m//, and s/// with match() and subst() Which I could see unifying. I'd ask people to wait until v2 of RFC 164 comes up. It may well include everything from RFC 138 already. -Nate
Re: RFC 165 (v1) Allow Varibles in tr///
> =head1 IMPLENTATION > > No idea, but should be straight forward. I think the reason this hasn't been done before it because it's *not* quite straightforward. The way tr/// works is that a 256-byte table is constructed at compile time that say for each input character what output character is produced. Then when it's time to apply the tr/// to a string, Perl iterates over the string one character at a time, looks up each character in the table, and replaces it with the corresponding character from the table. With tr///e, you would have to generate the table at run-time. This would suggest that you want the same sorts of optimizations that Perl applies when it encounters a regex that contains variables: 1. Perl should examine the strings to see if they have changed since the last time it executed the code 2. It should rebuild the tables only if the strings changed 3. There should be a /o modifier that promises Perl that the variables will never change. The implementation could be analogous to the way m/.../o is implemented, with two separate op nodes: One that tells Perl 'construct the tables' and one that tells Perl 'transform the string'. The 'construct the tables' node would remove itself from the op tree if it saw that the tr//o modifier was used.
Re: RFC 165: Allow variables in a tr///
> tr('a-z', 'A-Z', $str)
>
> replaces a-z with A-Z, and
>
> tr($foo, $bar, $str)
>
> replaces the characters from $foo with the characters from $bar.
> No special syntax is necessary.
This is actually right up the alley of v2 of RFC 164, which I am editing
currently. Exactly, in fact.
Please, continue the discussion, but much of this will be covered in RFC
164, which should hopefully be out by this afternoon. I will keep
monitoring this discussion for possible useful additions.
-Nate
Re: RFC 165: Allow variables in a tr///
> Would there be any interest in adding these two ideas to this RFC:
>
> 1) tr is not regex function, so it should be regularized to
>
>tr(SEARCH, REPLACE, MOD, STR)
MOD should be last, because you're frequently going to want to omit MOD.
But I think this is worth discussing further, because it neatly
accomplishes the goal of the RFC in a straightforward way:
tr('a-z', 'A-Z', $str)
replaces a-z with A-Z, and
tr($foo, $bar, $str)
replaces the characters from $foo with the characters from $bar.
No special syntax is necessary.
People might even stop writing things like
tr/[a-z]/[A-Z]/
if we did that.
Re: Overlapping RFCs 135 138 164
Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis pered: | | RFC135: Require explicit m on matches, even with ?? and // as delimiters. | | RFC138: Eliminate =~ operator. | | RFC164: Replace =~, !~, m//, and s/// with match() and subst() | | I would like to see these three RFCs merged into one if this is | appropriate. I am calling on the three authors to discuss in private You can add "RFC 156: Replace first match function (C) with a flag to the match command" to that list. I'd be happy to withdraw my RFC if it was folded into a combined RFC. -spp
Re: RFC 165: Allow variables in a tr///
Would there be any interest in adding these two ideas to this RFC: 1) tr is not regex function, so it should be regularized to tr(SEARCH, REPLACE, MOD, STR) The // tend to confuse people and make them expect tr to operate as a regular expression. 2) Remove y/// as a command. -spp
Re: RFC 110 (v3) counting matches
On Tue, 29 Aug 2000 11:13:47 -0600, Tom Christiansen wrote:
>We already *HAVE* a token set that forces list context, thank you
>very much. It's called "()=". I'm glad you like it.
$_ = 'a!a!a!a!a!a';
$count = () = split /!/;
print $count;
-->
1
'()=' is not perfect. It is also butt ugly. It is a "dirty hack".
p.s. Has anybody already suggested that we ought to have a nicer
solution to execute perl code inside a string, replacing "${\(...)}" and
"@{[...]}", which also won't ever win a beauty contest? Oops, wrong
mailing list.
--
Bart.
Re: RFC 110 (v3) counting matches
On Tue 29 Aug, Mark-Jason Dominus wrote: > > OK, I think this discussion should be closed. > > Richard should add a section to RFC110 that discusses the > > $count = () = m/PAT/g; > > locution and its advantages and disadvantages compared to his > proposal, duly taking into account the many valuable comments that > have been made. Will do. Richard -- [EMAIL PROTECTED]
Re: RFC 110 (v3) counting matches
What about a generator() keyword?[*] push @got, generator /bar/ Where generator keeps applying the EXPR or BLOCK until it runs out of results. [*] This resembles something that I must have read about in ICON. > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> The reason why not is because you're adding a special case hack to TC> one particular place, rather than promoting a general mechanism TC> that can be everywhere. TC> Tell me: which is better and why. TC> 1) A regex switch to specify scalar context, as in a mythical /r: TC> push(@got, /bar/r) TC> 2) A general mechanism, say for example, "scalar": TC> push(@got, scalar /bar/) TC> Obviously the "scalar" is better, because it does not require that TC> a new switch be learnt, nor is its use restricted to pattern matching. TC> Furthermore, it's inarguably more mnemonic for the sense of "match this TC> scalarishly". -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 110 (v3) counting matches
Tom Christiansen wrote:
>
> >And hashes are assembled just like lists anyways:
>
> > %hash = list get_key_vals;
> > %hash = (key, val, key2, val2); # same thing
>
> Eh? List context is conferred by the % on the LHS. You need
> no redundant listification redundancy there.
I was trying to show that "hash" isn't a needed keyword, NOT that "list"
is needed here.
> Now, you *can* force list context, but I (and Larry, one of whose
> text I just quoted) don't see it as common, so it's not worth the
> word. But it's not impossible, either, as you can use either the
> construct @{ [ ... ] } if you're in a string and trying to interpolate
> some function call, or simply through ()=... otherwise.
I know. But I've always thought this it too obscure. You only need one
trigonometric function, you know - everything else can be derived from
manipulation of sine. But we support 6. Why? To make things easy things
easier.
If you do need to force list context - and all of the example so far
have demonstrated you do from time to time - then *sometimes* "list"
makes more sense, just like *sometimes* "scalar" makes more sense:
foo(list bar()); # easy
foo( () = bar() ); # not as easy
foo(bar()); # easy
foo(scalar bar()); # not as easy
my($arg1) = func;# easy
my $arg1 = list func;# not as easy
my $num = @a;# easy
my($num) = scalar @a;# not as easy
The only thing you seem to be arguing against is clarity. I don't see
any disruption in the language here, or any reason "list" is less useful
than "scalar".
> Education is a wonderful thing.
I certainly hope this wasn't directed towards me.
-Nate
Re: RFC 166 (does-not-match)
> This is going to need a much better definition...
Yes, that was my point.
I snipped the following discussion, in which you argued against a
suggestion that I advanced only as an example of something that would
not work.
> (?^baz) should behave as (.*)(?{$1 !~ /baz/})
I don't think that's going to do it. Consider this pattern:
/foo(?^baz)baz/
Here I am trying to match strings like "foobarbaz" and "foo---baz"
that have a foo and a baz separated by something else that is not a
baz. But with your definition,
"foobazbaz" =~ /foo(?^baz)baz/
is true, when I wanted it to be false. This is because the (?^baz)
matches the empty string after the 'o', and the "baz" in the pattern
matches the first baz in the string, instead of the second one.
> I think one should outlaw .* before or after a (?^foo) construct, as
> the result is meaningless.
As it stands now the whole notion is meaningless, because you have not
given it a meaning.
Can you provide a detailed explanation of just what is and what is not
outlawed? I presume that .+ is also forbidden. What about a*, .?,
.{3}, etc.?
I wonder if this restriction is really necessary?
> I can tighten the definition up. If there have been calls for a
> (?^baz) type construct before, there will be again. It is a matter of
> getting the definition straightforward and useable.
Yes, I agree completely. I am looking forward to the next version of
your RFC.
Re: RFC 110 (v3) counting matches
>And hashes are assembled just like lists anyways:
> %hash = list get_key_vals;
> %hash = (key, val, key2, val2); # same thing
Eh? List context is conferred by the % on the LHS. You need
no redundant listification redundancy there.
>But no, I certainly wouldn't suggest going down the path of 1000
>explicit contexts. Bad. Implicit context good! But a "list" helper
>function like a "scalar" helper function would solve a lot of common
>problems.
No, a list helper function would *not* solve a lot of *common* problems:
There's no C function corresponding to C since,
in practice, one never needs to force evaluation in a list
context. That's because any operation that wants R already
provides a list context to its list arguments for free.
It's not a "common problem".
Now, you *can* force list context, but I (and Larry, one of whose
text I just quoted) don't see it as common, so it's not worth the
word. But it's not impossible, either, as you can use either the
construct @{ [ ... ] } if you're in a string and trying to interpolate
some function call, or simply through ()=... otherwise.
Education is a wonderful thing.
--tom
Re: RFC 110 (v3) counting matches
>For me, yeah. But I can name at least 30 people in my building alone
>that have been hacking Perl for years who wouldn't get this. And a "well
>they don't know what's going on" argument doesn't work. Not everyone is
>a Perl expert.
I will always find this argument specious. Some people "hack on X" for
years but never but scratch the surface. There are various reasons for
this, depending. But you won't fix it--espeically by adding more crudola
for them to scratch up.
>Besides, you're telling me this:
> foo(list bar())
>is *LESS* intuitive? I really don't buy that.
Noting that we use [] for an anon array and {} for an anon hash,
not ARRAY or array and HASH or hash, it seems to follow to use ()
for the list.
It's not my fault that people don't know this. I've certainly
explained it.
% tcgrep '^\s.*\(\s*\)\s*=' ~/cookbook/*.pod
/home/tchrist/cookbook/chap10.pod:() = some_function();
% tcgrep '^\s.*\(\s*\)\s*=' ~/camel/*.pod
/home/tchrist/camel/200lexical.pod:() = funkshun();
/home/tchrist/camel/200lexical.pod:$x = ( () = funk() ); # also set
$x to funk()'s return count
/home/tchrist/camel/290subs.pod:canmod() = 5; # Assigns to $val.
/home/tchrist/camel/290subs.pod:nomod() = 5; # ERROR
/home/tchrist/camel/650threads.pod:$t1->tid() == $td->tid()
--tom
Re: RFC 110 (v3) counting matches
Jonathan Scott Duff wrote: > > I'll agree that /l is bad too. But I think adding a new "list" > keyword is also bad. What about other contexts? Are we going to have > "scalar", "list", "hash", "boolean", "string", "number", etc.? Not to > mention (even though I am) user-defined contexts (my Dog $spot; $spot > = gen_dog(); <-- that's a "Dog" context). The interesting thing is that "scalar" and "list" are the only two that can't be done completely implicitly without arbitrary edge case decisions. Nobody wants to admit this, but it's true. Somebody once posted a "proof" of this, but I'll have to dig... And hashes are assembled just like lists anyways: %hash = list get_key_vals; %hash = (key, val, key2, val2); # same thing But no, I certainly wouldn't suggest going down the path of 1000 explicit contexts. Bad. Implicit context good! But a "list" helper function like a "scalar" helper function would solve a lot of common problems. Not Perl 5? Probably. Not Perl 6? Don't buy it. Bad idea? Maybe. -Nate
Re: RFC 166 (does-not-match)
>I can tighten the definition up. If there have been calls for a >(?^baz) type construct before, there will be again. It is a matter of >getting the definition straightforward and useable. Are you really just wanting !/BAD/ there? That is, something that isn't matched by /BAD/? One would, of course, normally simply write !/BAD/, or perhaps !~ /BAD/. However, if reading a config file of patterns, you can't go invert the sense of the match. Well, easily, that is. The Perl Cookbook, in Chapter 6, has these solutions: * True if either C or C matches, like C: /ALPHA|BETA/ * True if both C and C match, but may overlap, meaning that C<"BETALPHA"> should be ok, like C: /^(?=.*ALPHA)(?=.*BETA)/s * True if both C and C match, but may not overlap, meaning that C<"BETALPHA"> should fail: /ALPHA.*BETA|BETA.*ALPHA/s * True if pattern C does not match, like C<$var !~ /PAT/>: /^(?:(?!PAT).)*$/s * True if pattern C does not match, but pattern C does: /(?=^(?:(?!BAD).)*$)GOOD/s I suspect the penultimate is just what you're looking for. Or shall I go back and deepread the whole thread? :-( --tom
Re: RFC 110 (v3) counting matches
Tom Christiansen wrote: > > Goodness, it certainly does. It's loads easier than learning a new buzz^Wkeyword > or a new switch, because you already know it. Nobody with a sound mind would ever suggest that: > $stuff = () = $r =~ /crap/shit/; Wouldn't still work. At least not me. But these two work: print "Got " . @array . " elements"; print "Got " . scalar @array . " elements"; So why again does a "list" keyword not make sense? Seems "scalar" is just as redundant here. > However, if foo($) is thus "prototyped", > you need but write > > foo( () = bar() ) > > to get bar() to be called in list context. This is wholly intuitive. For me, yeah. But I can name at least 30 people in my building alone that have been hacking Perl for years who wouldn't get this. And a "well they don't know what's going on" argument doesn't work. Not everyone is a Perl expert. Besides, you're telling me this: foo(list bar()) is *LESS* intuitive? I really don't buy that. -Nate
Re: RFC 166 (disambiguator)
On Tue 29 Aug, Mark-Jason Dominus wrote: > > 2. You can already write /$foo(?:)bar/ to get what you wanted. This >is almost identical to what Richard proposed anyway. This has the effect I was after. > > It is really not clear to me that this problem needs to be solved any > better than it is already. > > I suggest that this section be removed from the RFC. > OK. I was throwing up some ideas. (I have a few more in development) -- [EMAIL PROTECTED]
Re: RFC 166 (does-not-match)
On Tue 29 Aug, Mark-Jason Dominus wrote:
>
> Richard Proctor's RFC166 says:
>
> > =head2 Matching Not a pattern
> >
> > (?^pattern) matches anything that does not match the pattern. On
> > its own, one can use !~ etc to negatively match patterns, but to
> > match a pattern that has foo(anything but not baz)bar is currently
> > difficult. With this syntax it would simply be /foo(?^baz)bar/.
>
> The problem with this proposal is that it's really unclear what it
> means.
This is going to need a much better definition...
>
> The reason we don't have this feature today is not that it has never
> been thought of before. People have thought of this a hundred times.
> The problem is that nobody has ever figured out how it should work.
> I don't mean that the implemenation is difficult. I mean that nobody
> understand what such a a feature actually means. Richard doesn't say
> this in his RFC, even for the simple examples he raises. He just
> assumes that it will be obvious, but it isn't.
>
> "foo-bazbar" =~ /foo(?^baz)bar/# true or false?
> "foo-baz-bar" =~ /foo(?^baz)bar/# true or false?
The simple answer is both are false.
> OK, I'm going to try to invent a meaning for (?^baz). I'm going to
> choose what appears to be a reasonable choice, and see what happens.
>
> Let's suppose that what (?^baz) means is "match any substring that is
> not 'baz'." That is a reasonably clear meaning. Then it behaves like
> (.*)(?{$1 ne 'baz'}) does today. Then the examples above are both
> true.
No your example is wrong it should behave as (.*)(?{$1 !~ /baz/}) both the
examples are false. (?^foo) matches any substring that does not match the
pattern foo.
>
> Now let's see how that choice works out.
>
> "foobaz" =~ /foo.*(?^baz)/
>
> This is TRUE, because "foo" matches "foo", ".*" matches "baz", and
> "(?^baz)" matches the empty string at the end, which is a substring
> that is not "baz".
This is a traditional problem with a greedy .* this however does beg
the question is (?^baz) greedy? I think the right answer is that it should
not be (but I am open to debate on that).
>
> In fact, with this apparently reasonable choice of meaning for
> (?^baz), /foo.*(?^baz)/ will match anything that /foo.*/ will. The
> (?^baz) has hardly any effect at all.
With a greedy .* the (?^baz) has no effect, unless something follows that
has to be matched.
>
> It is a good thing that we did not implement it that way, because it
> is sure to become an instant FAQ: "Why does /foo.*(?^baz)/ match
> 'foobaz'?" You are going to see this question in comp.lang.perl.misc
> every week.
I think one should outlaw .* before or after a (?^foo) construct, as
the result is meaningless.
>
> So this choice I made for the meaning of (?^baz) appears to have been
> the wrong one. I could go on and make a different reasonable-seeming
> choice and show what was wrong with it, but I don't want to belabor my
> point, which is:
>
> Every choice anyone has ever made for the meaning of (?^baz) has
> always been the wrong one for one reason or another. So without a
> detailed explanation of what (?^baz) might mean, suggesting that Perl
> 6 have one is not helpful.
I can tighten the definition up. If there have been calls for a
(?^baz) type construct before, there will be again. It is a matter of
getting the definition straightforward and useable.
Richard
--
[EMAIL PROTECTED]
Re: RFC 110 (v3) counting matches
OK, I think this discussion should be closed. Richard should add a section to RFC110 that discusses the $count = () = m/PAT/g; locution and its advantages and disadvantages compared to his proposal, duly taking into account the many valuable comments that have been made. Thanks to everyone who participated in the discussion.
Re: RFC 110 (v3) counting matches
>But, for "crying out loud!", then what the hell do we need "scalar" for?
>You can accomplish the same thing like this:
> $num = @array;
> print "Got $num elements";
Wrong. You just wasted a scalar needlessly, which ()= doesn't
do. Of course, you *don't* need scalar() there.
print "Got " . @array . " elements";
>"scalar" makes things easy. So does something like "list". This
> $stuff = () = $r =~ /crap/shit/;
>Doesn't make anything easy.
Goodness, it certainly does. It's loads easier than learning a new buzz^Wkeyword
or a new switch, because you already know it.
>> Perl does context. Perl does *IMPLICIT* context. Cope.
>Great. Then let's drop "scalar" to be consistent. This can be done
>completely implicitly, right?
There are no anonymous scalars. You'd at best have to write
foo(scalar bar())
as something more like
foo(do { my $x = bar() })
which is lame. However, if foo($) is thus "prototyped",
you need but write
foo( () = bar() )
to get bar() to be called in list context. This is wholly intuitive.
If it isn't, you need to review how
my($x)
works--once again.
--tom
Re: RFC 110 (v3) counting matches
Tom Christiansen wrote: > > >While I agree that /l is bad, I think going through the crap of "= () =" > >is even worse. Does it work? Yes. But is it easily usable and fun, even > >for non-experts? No. > > Oh, for crying out loud--at some point, you have to stop tossing > rotting fish for the starving ignorant and actually get them to > LEARN something. Or let them die of starvation. > > Note the difference between > > my $var = func(); > > and > > my($var) = func(); Fine. I understand that. Surprise! I'm not an idiot. But, for "crying out loud!", then what the hell do we need "scalar" for? You can accomplish the same thing like this: $num = @array; print "Got $num elements"; "scalar" makes things easy. So does something like "list". This $stuff = () = $r =~ /crap/shit/; Doesn't make anything easy. > Perl does context. Perl does *IMPLICIT* context. Cope. Great. Then let's drop "scalar" to be consistent. This can be done completely implicitly, right? -Nate
Overlapping RFCs 135 138 164
RFC135: Require explicit m on matches, even with ?? and // as delimiters. C and C are what makes Perl hard to tokenize. Requiring them to be written C and C would solve this. (Nathan Torkington) RFC138: Eliminate =~ operator. Replace EXPR =~ m/.../ with m/.../ EXPR, and similarly for s/// and tr///. Force an explicit dereference when using qr/.../. Disallow the implicit treatment of a string as a regular expression to match against. (Steve Fink) RFC164: Replace =~, !~, m//, and s/// with match() and subst() Several people (including Larry) have expressed a desire to get rid of C<=~> and C. This RFC proposes a way to replace C and C with two new builtins, C and C. (Nathan Widger) I would like to see these three RFCs merged into one if this is appropriate. I am calling on the three authors to discuss in private email how this may be done. I hope that the discussion will result in the withdrawal at least two of the three RFCs, and that this private discussion produces a new RFC. The new RFC should discuss the points raised by all three existing RFCs, should investigate several solutions in parallel, and should compare them with one another and contrast the benefits and drawbacks of each one. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 110 (v2) counting matches
> "MD" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes: MD> m// and s/// presently take eight different flags. (cegimosx) In the MD> past, several others have been proposed, including /r, /t, and /z. and i have proposed /k to keep values in the $& and @+ vars. this is in the regex special vars rfc #158 MD> Anyway, I will consider the subject closed unless someone produces an MD> RFC for it. we should have a final report showing all the proposed modifiers as well as the proposed long forms. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 110 (v3) counting matches
> $count = () = /PATTERN/g; >With a keyword forcing a list context, this new option is unnecessary. We already *HAVE* a token set that forces list context, thank you very much. It's called "()=". I'm glad you like it. --tom
Re: RFC 110 (v3) counting matches
>While I agree that /l is bad, I think going through the crap of "= () =" >is even worse. Does it work? Yes. But is it easily usable and fun, even >for non-experts? No. Oh, for crying out loud--at some point, you have to stop tossing rotting fish for the starving ignorant and actually get them to LEARN something. Or let them die of starvation. Note the difference between my $var = func(); and my($var) = func(); Those are completely different in that they call func() in scalar and list contexts. Why? Because of hte presence or absence of (), of course. If they can't learn that adding () to the LHS of an assignment makes it list context, then they will be forever miserable. Perl does context. Perl does *IMPLICIT* context. Cope. --tom
Re: RFC 110 (v2) counting matches
> Mark-Jason Dominus wrote: > > > > m/.../Count (instead of m/.../t) > > m/.../iCount (instead of m/.../it) > > m/.../Count,i (instead of m/.../ti) > > m/.../Count,Insensitive (instead of m/.../ti) > > Blech, no. Please. Less typing good. More typing bad. > > If you're just proposing synonyms, I don't see anyone using these > besides as mnemnonics. In which case, the key is just making sure > that we pick good letters. Iwas proposing synonyms for the existing options, and an expanded namespace for future options. It is perfectly reasonable for common flags to get short names and uncommon flags to get long names. For example, I think that if the /c option had had only a long name, it would have imposed very little burden on the community, and it would have left /c itself available for the more useful application of producing a count. > I don't see us running out of letters. The problem is not with running out of letters. The problem is with running out of appropriate letters. I raised this suggestion in response to Richard Proctor's observation that /c was unavailable for 'count', and suggesting /t instead. > Last I checked, m// only takes half a dozen flags. m// and s/// presently take eight different flags. (cegimosx) In the past, several others have been proposed, including /r, /t, and /z. > And so on. This seems like a much more productive use, otherwise we're > just wasting characters. Characters are not in short supply. Anyway, I will consider the subject closed unless someone produces an RFC for it.
Re: RFC 110 (v3) counting matches
On Tue, 29 Aug 2000 08:56:16 -0700, Nathan Wiger wrote:
>> $count = () = getpwnam("tchrist");
>
>Hmmm. I agree a general purpose mechanism is good, but in this case we
>already have "scalar" so why not "list"?
>
>$count = list getpwnam("tchrist");
>
>While I agree that /l is bad, I think going through the crap of "= () ="
>is even worse.
I was just thinking the same thing, on the proposed //t option which
would count the matches, same as:
$count = () = /PATTERN/g;
With a keyword forcing a list context, this new option is unnecessary.
You could even build sequences:
print scalar list /PATTERN/g;
More than one way to do things is nice, but you can overdo it. You'll
get a language where even experts don't even know half of the
possibilities. Ada or PL/1, anyone?
PL/1
The language was intended to be a general purpose language
suitable for all applications [...]. PL/1 also attempted to
combine run-time efficiency with flexibility, however, the
result was a very complex language. Consequently the language
never lived up to its expectations.
--
Bart.
Re: RFC 110 (v3) counting matches
On Tue, Aug 29, 2000 at 08:56:16AM -0700, Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > $count = getpwnam("tchrist")/l;
> > $count = getpwnam("tchrist", LIST);
> > $count = getpwnam("tchrist")->as_list;
> >
> > All of those, frankly, suck. This is much better:
> >
> > $count = () = getpwnam("tchrist");
>
> Hmmm. I agree a general purpose mechanism is good, but in this case we
> already have "scalar" so why not "list"?
>
> $count = list getpwnam("tchrist");
>
> While I agree that /l is bad, I think going through the crap of "= () ="
> is even worse. Does it work? Yes. But is it easily usable and fun, even
> for non-experts? No.
I'll agree that /l is bad too. But I think adding a new "list"
keyword is also bad. What about other contexts? Are we going to have
"scalar", "list", "hash", "boolean", "string", "number", etc.? Not to
mention (even though I am) user-defined contexts (my Dog $spot; $spot
= gen_dog(); <-- that's a "Dog" context).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 110 (v3) counting matches
Tom Christiansen wrote:
>
> $count = getpwnam("tchrist")/l;
> $count = getpwnam("tchrist", LIST);
> $count = getpwnam("tchrist")->as_list;
>
> All of those, frankly, suck. This is much better:
>
> $count = () = getpwnam("tchrist");
Hmmm. I agree a general purpose mechanism is good, but in this case we
already have "scalar" so why not "list"?
$count = list getpwnam("tchrist");
While I agree that /l is bad, I think going through the crap of "= () ="
is even worse. Does it work? Yes. But is it easily usable and fun, even
for non-experts? No.
-Nate
Re: RFC 110 (v2) counting matches
>If we want to use uppercase, make these unique as well. That gives us >many more combinations, and is not necessarily confusing: > m//f - fast match > m//F - first match > m//i - case-insentitive > m//I - ignore whitespace > >And so on. This seems like a much more productive use, otherwise we're >just wasting characters. Larry's on record as preferring not to have us going down the road of using distinct upper and lower case regex switches. The distance between //c and //C, say, is far too narrow. --tom
Re: RFC 110 (v3) counting matches
>That empty list to force the proper context irks me. How about a
>modifier to the RE that forces it (this would solve the "counting matches"
>problem too).
> $string =~ m{
> (\d\d) - (\d\d) - (\d\d)
> (?{ push @dates, makedate($1,$2,$3) })
> }gxl;
> $count = $string =~ m/foo/gl; # always list context
The reason why not is because you're adding a special case hack to
one particular place, rather than promoting a general mechanism
that can be everywhere.
Tell me: which is better and why.
1) A regex switch to specify scalar context, as in a mythical /r:
push(@got, /bar/r)
2) A general mechanism, say for example, "scalar":
push(@got, scalar /bar/)
Obviously the "scalar" is better, because it does not require that
a new switch be learnt, nor is its use restricted to pattern matching.
Furthermore, it's inarguably more mnemonic for the sense of "match this
scalarishly".
Likewise, to force list context (a far less common operation, mind
you), it is a bad idea to have what amounts to a special argument
to just one function to this. What happens to the next function you
want to do this to? How about if I want to force getpwnam() into list
context and get back a scalar result?
$count = getpwnam("tchrist")/l;
$count = getpwnam("tchrist", LIST);
$count = getpwnam("tchrist")->as_list;
All of those, frankly, suck. This is much better:
$count = () = getpwnam("tchrist");
It's better because
* You don't have to invent anything new, whether syntactically
or mnemonically. The sucky solution all require modification
of Perl's very syntax. With the list assignment, you just need
to learn how to use what you *already have*. I could say as
much for (?{...}). Think how many of the suggestions on these
lists can be dealt with simply through using existing features
that the suggesting party was unaware of.
* It's a general mechanism that isn't tailored for this particular
function call. Special-purpose solutions are often inferior
to general-purpose ones, because the latter are more likely to
be creatively usable in a fashion unforeseen by the author.
* What could possibly be more intuitive for the action of acting
as though one were assigning to a list than doing that very
thing itself? Since () is the canonical list (it's empty, after
all), this follows directly and requires on special knowledge
whatsoever.
--tom
Re: RFC 110 (v2) counting matches
Mark-Jason Dominus wrote: > > m/.../Count (instead of m/.../t) > m/.../iCount (instead of m/.../it) > m/.../Count,i (instead of m/.../ti) > m/.../Count,Insensitive (instead of m/.../ti) Blech, no. Please. Less typing good. More typing bad. If you're just proposing synonyms, I don't see anyone using these besides as mneumoics. In which case, the key is just making sure that we pick good letters. I don't see us running out of letters. Last I checked, m// only takes half a dozen flags. I haven't been counting, but I'm pretty sure I haven't seen 20 new flags proposed. If we want to use uppercase, make these unique as well. That gives us many more combinations, and is not necessarily confusing: m//f - fast match m//F - first match m//i - case-insentitive m//I - ignore whitespace And so on. This seems like a much more productive use, otherwise we're just wasting characters. -Nate
Re: RFC 110 (v3) counting matches
On Tue, Aug 29, 2000 at 09:23:59AM -0600, Tom Christiansen wrote:
> () = $string =~ m{
> (\d\d) - (\d\d) - (\d\d)
> (?{ push @dates, makedate($1,$2,$3) })
> }gx;
That empty list to force the proper context irks me. How about a
modifier to the RE that forces it (this would solve the "counting matches"
problem too).
$string =~ m{
(\d\d) - (\d\d) - (\d\d)
(?{ push @dates, makedate($1,$2,$3) })
}gxl;
$count = $string =~ m/foo/gl; # always list context
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 110 (v3) counting matches
On Tue, Aug 29, 2000 at 11:21:30AM -0400, Joe McMahon wrote:
> This is NOT completely thought out yet; I've been mulling it over as a
> possible RFC. I'm not happy with this syntax as it stands - there's too
> much possible action at a distance. I'm not seeing a nicely-parseable,
> easily-understandable way of doing this. Would this be a possible:
>
>$string =~ /(\d\d)-(\d\d)-(\d\d)?&{push @list,makedate(\1,\2,\3)}/g;
>
> Or is that just too ugly and nasty for words?
How about something like this?
$re = qr/(\d\d)-(\d\d)-(\d\d)/g;
$re->onmatch_callback(push @list, makedate(^0,^1,^2));
$string =~ $re;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 110 (v3) counting matches
>much possible action at a distance. I'm not seeing a nicely-parseable,
>easily-understandable way of doing this. Would this be a possible:
> $string =~ /(\d\d)-(\d\d)-(\d\d)?&{push @list,makedate(\1,\2,\3)}/g;
>Or is that just too ugly and nasty for words?
Yes, passing a reference to the numbers 1, 2, and 3 is clearly too ugly.
But you'll find we've already got that, I think.
sub makedate {
my($dd,$mm,$yy) = @_;
warn "Just got a date for @_\n";
return "[$yy/$mm/$dd]";
}
$string = "22-33-44 and 55-66-77 are ok";
@dates = ();
() = $string =~ m{
(\d\d) - (\d\d) - (\d\d)
(?{ push @dates, makedate($1,$2,$3) })
}gx;
print "Now the dates are: @dates\n";
Running that yields:
Just got a date for 22 33 44
Just got a date for 55 66 77
Now the dates are: [44/33/22] [77/66/55]
--tom
Re: RFC 110 (v3) counting matches
Philip Newton wrote:
>
> What I use in a script of mine is:
>
> while ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
> ($mo, $dy, $yr) = ($1, $2, $3);
> }
>
> Although this, of course, also requires that you know the number of
> backreferences. Nicer would be to be able to assign from @matchdata or
> something like that :)
>
I mentioned in another thread the concept (stolen from SNOBOL) of a
conditional function call, post-match. Winging a syntax which I am
absolutely NOT committed to:
my @list;
my $capture = sub {push @list, makedate(\1,\2,\3);};
$string =~ /(\d\d)-(\d\d)-(\d\d)?&$capture/g;
In a regular, non-global match, the anonymous sub gets called if the
match preceeding it succeeds. If it fails, the function doesn't get
called. In a "/g", it gets called *each time* a global match succeeds;
you get an implicit "while" over the string.
This is NOT completely thought out yet; I've been mulling it over as a
possible RFC. I'm not happy with this syntax as it stands - there's too
much possible action at a distance. I'm not seeing a nicely-parseable,
easily-understandable way of doing this. Would this be a possible:
$string =~ /(\d\d)-(\d\d)-(\d\d)?&{push @list,makedate(\1,\2,\3)}/g;
Or is that just too ugly and nasty for words?
--- Joe M.
Re: RFC 110 (v2) counting matches
On Tue, 29 Aug 2000 09:00:43 -0400, Mark-Jason Dominus wrote: >> And, I don't really see the need for the comma. >> >> m/.../CountInsensitive (instead of m/.../ti) > >I guess, but to me CountInsensitive looks like one option, not two. That goes fot this too. : m/.../iCount (instead of m/.../it) -- Bart.
Re: RFC 110 (v3) counting matches
On Tue, 29 Aug 2000 08:51:29 -0400, Mark-Jason Dominus wrote:
>There are many operations that would be simpler if there was
>a magic array that contained ($1, $2, $3, ...). If anyone wants to
>write an RFC on this, I will help.
Heh. I once complained about the lack of such an array, in
comp.lang.perl.misc, *years* ago.
My practical problem was something like this, in a translation program.
$phrase is one of many patterns in a table, to look for English phrases,
%translate contains the French translations. interpolate() is a sub that
fills in the parameters -- the numbers in the string):
$_ = "It is 5 past 10."
$phrase = 'it is (\d+) past (\d+)';
s/^$phrase/interpolate($translate{$phrase}, $1, $2)/ie;
The problem is that with variable patterns, you *don't know* how many
paren groups there are.
The solution they came upo with, was @+ and @-. I still can't work with
those. An array of matches, (e.g. @&) would be a lot easier. It could
also be a lot slower; see the discussion on $& for this. (mystery: how
can filling in $& be a lot slower than filling in $1?)
--
Bart.
Re: RFC 110 (v2) counting matches
> On Tue, 29 Aug 2000 08:47:25 -0400, Mark-Jason Dominus wrote: > > >m/.../Count,Insensitive (instead of m/.../ti) > > > >That would escape the problem that we are running out of letters and > >also the problem that the current letters are hard to remember. > > Yes, but wouldn't this give us backward compatibility problems? For > example, code like > > $result = m/(.)/Insensitive, ord $1; No, because that is presently a syntax error. The one you have to watch out for is: $result = m/(.)/s,Insensitive, ord $1; > And, I don't really see the need for the comma. > > m/.../CountInsensitive (instead of m/.../ti) I guess, but to me CountInsensitive looks like one option, not two.
Re: RFC 110 (v2) counting matches
On Tue, 29 Aug 2000 08:47:25 -0400, Mark-Jason Dominus wrote: >m/.../Count,Insensitive (instead of m/.../ti) > >That would escape the problem that we are running out of letters and >also the problem that the current letters are hard to remember. Yes, but wouldn't this give us backward compatibility problems? For example, code like $result = m/(.)/Insensitive, ord $1; And, I don't really see the need for the comma. m/.../CountInsensitive (instead of m/.../ti) (Camel case strikes back!) -- Bart.
Re: RFC 110 (v3) counting matches
> On Mon, 28 Aug 2000, Mark-Jason Dominus wrote:
>
> > But there is no convenient way to run the loop once for each date and
> > split the dates into pieces:
> >
> > # WRONG
> > while (($mo, $dy, $yr) = ($string =~ /(\d\d)-(\d\d)-(\d\d)/g)) {
> > ...
> > }
>
> What I use in a script of mine is:
>
> while ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
> ($mo, $dy, $yr) = ($1, $2, $3);
> }
>
> Although this, of course, also requires that you know the number of
> backreferences.
The real problem I was trying to discuss was not this particular
application. I was trying to point out a larger problem, which is
that there are several regex features that are enabled or disabled
depending on what context the match is in, so that if you want one
scalar-context feature and one list-context feature at the same time,
there is no direct way to do it.
> Nicer would be to be able to assign from @matchdata or something
> like that :)
I agree. There are many operations that would be simpler if there was
a magic array that contained ($1, $2, $3, ...). If anyone wants to
write an RFC on this, I will help.
Re: RFC 110 (v2) counting matches
> /t is suggested for "counT", as /c is already taken. Using /t > without /g would be result in only 0 or 1 being returned, which is > nearly the existing syntax. It occurs to me that since none of the capital letters are taken, we could adopt the convention that a capital letter as a regex modifier will introduce a *word* which continues up to the next comma. So for example: m/.../Count (instead of m/.../t) m/.../iCount (instead of m/.../it) m/.../Count,i (instead of m/.../ti) m/.../Count,Insensitive (instead of m/.../ti) That would escape the problem that we are running out of letters and also the problem that the current letters are hard to remember.
Re: RFC 110 (v3) counting matches
On Mon, 28 Aug 2000, Mark-Jason Dominus wrote:
> But there is no convenient way to run the loop once for each date and
> split the dates into pieces:
>
> # WRONG
> while (($mo, $dy, $yr) = ($string =~ /\d\d-\d\d-\d\d/g)) {
> ...
> }
What I use in a script of mine is:
while ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
($mo, $dy, $yr) = ($1, $2, $3);
}
Although this, of course, also requires that you know the number of
backreferences. Nicer would be to be able to assign from @matchdata or
something like that :)
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
RFC 166 (disambiguator)
Richard Proctor suggests that (?) will match the empty string.
Then it can be inserted into regexes to separate elements that need to
be separated. For example, /$foo(?)bar/ interpolates the value of
$foo and then looks for that pattern followed by 'bar'. You cannot
simply write /$foobar/ because then Perl tries to interpolate $foobar,
which is not what you wanted.
1. You can already write /${foo}bar/ to get what you wanted. This
solution already works inside of double-quoted strings. (?) would
not work inside of double-quoted strings.
2. You can already write /$foo(?:)bar/ to get what you wanted. This
is almost identical to what Richard proposed anyway.
It is really not clear to me that this problem needs to be solved any
better than it is already.
I suggest that this section be removed from the RFC.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
RFC 166 (does-not-match)
Richard Proctor's RFC166 says:
> =head2 Matching Not a pattern
>
> (?^pattern) matches anything that does not match the pattern. On
> its own, one can use !~ etc to negatively match patterns, but to
> match a pattern that has foo(anything but not baz)bar is currently
> difficult. With this syntax it would simply be /foo(?^baz)bar/.
The problem with this proposal is that it's really unclear what it
means.
The reason we don't have this feature today is not that it has never
been thought of before. People have thought of this a hundred times.
The problem is that nobody has ever figured out how it should work.
I don't mean that the implemenation is difficult. I mean that nobody
understand what such a a feature actually means. Richard doesn't say
this in his RFC, even for the simple examples he raises. He just
assumes that it will be obvious, but it isn't.
"foo-bazbar" =~ /foo(?^baz)bar/# true or false?
"foo-baz-bar" =~ /foo(?^baz)bar/# true or false?
OK, I'm going to try to invent a meaning for (?^baz). I'm going to
choose what appears to be a reasonable choice, and see what happens.
Let's suppose that what (?^baz) means is "match any substring that is
not 'baz'." That is a reasonably clear meaning. Then it behaves like
(.*)(?{$1 ne 'baz'}) does today. Then the examples above are both
true.
Now let's see how that choice works out.
"foobaz" =~ /foo.*(?^baz)/
This is TRUE, because "foo" matches "foo", ".*" matches "baz", and
"(?^baz)" matches the empty string at the end, which is a substring
that is not "baz".
In fact, with this apparently reasonable choice of meaning for
(?^baz), /foo.*(?^baz)/ will match anything that /foo.*/ will. The
(?^baz) has hardly any effect at all.
It is a good thing that we did not implement it that way, because it
is sure to become an instant FAQ: "Why does /foo.*(?^baz)/ match
'foobaz'?" You are going to see this question in comp.lang.perl.misc
every week.
So this choice I made for the meaning of (?^baz) appears to have been
the wrong one. I could go on and make a different reasonable-seeming
choice and show what was wrong with it, but I don't want to belabor my
point, which is:
Every choice anyone has ever made for the meaning of (?^baz) has
always been the wrong one for one reason or another. So without a
detailed explanation of what (?^baz) might mean, suggesting that Perl
6 have one is not helpful.
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
> 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 people are talking about the wrong things, then you should submit your own RFCs on the right things, instead of complaining about what other people are doing. I have not seen any RFCs from you. > MJD's // killer RFC is a headache. I would appreciate a clear discussion of why that is. That is what we are here for. If the RFC does not lay out clearly what problem it is tryhing to solve, that is a problem with the RFC and it's something we should discuss on the list. However, this comment by itself is not useful. > I don't see how this solves an already existing problem. I didn't either, and I objected to RFC138 on that basis. But Larry said: # Well, the fact is, I've been thinking about possible ways to get rid # of =~ for some time now, so I certainly don't mind brainstorming in # this direction. So I consider the metasubject (of whether we should be discussing that topic at all) to be officially closed.
