Apocalypse 5
by Larry Wall
|
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
Editor's Note: this Apocalypse is out of date and remains here for historic reasons. See Synopsis 05 for the latest information.
RFC 144: Behavior of empty regex should be simple
I agree, the behavior should be simple. However, rather than always
matching, I propose to make it an error to actually have a null
pattern, or a null choice in a list of alternatives. Use an explicit
<null> if that's what you mean. (It's not a problem if $foo is null
in /$foo/, since variables are now managed by the regex engine and
not by interpolation.)
RFC 150: Extend regex syntax to provide for return of a hash of matched subpatterns
The $foo:=(...) notation essentially covers that case. One can say:
/ %hash{foo}:=(...) %hash{bar}:=(...) /
Fancier things can be done with closures.
RFC 156: Replace first match function (?...?) with a flag to the match command.
Having a :f modifier seems like a reasonable way to do it:
m:f/.../
Though it's vaguely possible we should be having a set of verbs that
parse like split:
split /.../
count /.../
first /.../
It's not clear whether those are actually methods, and if so, on
which object, the string or the regex. In any event, I don't think
we have to nail that down quite yet. I'm accepting the basic premise
of this RFC that the ?...? construct is going away, one way or another.
At the moment, it looks like this option is spelled :once.
RFC 165: Allow Variables in tr///
If interpolation of patterns by default is wrong, I think extending the tr///
interface via scalar interpolation is doubly wrong. Run-time
generated transliterations should be based on mappings that aren't
so position dependent. That is, rather than specifying it as two
long lists:
abc12xyz => ABC34XYZ
we specify something more like this:
abc => ABC
12 => 34
xyz => XYZ
That looks more like a list of pairs of scalars than a pair of scalars. In fact, internally, it's done like a funny parallel substitution:
s:e(/a/A/,
/b/B/,
/c/C/,
/1/3/,
/2/4/,
/x/X/,
/y/Y/,
/z/Z/)
In any event, it's more like tr/@foo/@bar/ than tr/$foo/$bar/.
But then, why stick with the fake string notation? Why not just say
tr(@foo,@bar) if that's what we mean? Then we're not limited
to character substitutions:
$string.tr [ " " , "<" , ">" , "\n" ],
[ " ", "<", ">", "<br>" ];
Or how about tr(%trans)?
%upper = {
"a-z" => "A-Z",
}
$string.tr %upper;
or just pair lists of some sort:
$string.tr("a-c" => "x-z",
"1-2" => "3-4",
"A-C" => "X-Z",
);
@trans = [
"a-z" => "A-Z",
@tr_danish,
];
$string.tr(@trans)
Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 |

