Naming the method form of s///
Mark J. Reed
"subst". (Just going by the spec here; the method doesn't exist yet in
Pugs). I anticipate typos galore from the near-collision of names between
"subst" and "substr"; perhaps "replace" would be a better name, even though
it breaks the mnemonic association with s///?
--
Mark J. Reed <mark...@mail.com>
Juerd
Another issue is how we're going to pass arguments to this method. s///
has very special syntax, that I don't think we can easily replicate.
I personally still prefer $foo.s/// and $foo.=s///, because I don't
think substitution belongs in a smart match op.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Mark J. Reed
>
> Another issue is how we're going to pass arguments to this method. s///
> has very special syntax, that I don't think we can easily replicate.
S05 says it's $str.subst(regex, string-or-block); presumably the flags would
go on the regex?
I personally still prefer $foo.s/// and $foo.=s///
I don't really like the combination of quotelike and method call syntaxes.
I would happily take "s" as a replacement for the method name, but I don't
think it can happily coexist with the operator.
because I don't think substitution belongs in a smart match op.
Well, that's the reason for the method version in perl6. Which, AFAICT,
returns the new string instead of the Match object, which is as it should
be. The only thing I don't like is the name. :)
Sage La Torra
> I anticipate typos galore from the near-collision of names between
> "subst" and "substr"; perhaps "replace" would be a better name, even
> though
> it breaks the mnemonic association with s///?
>
Perhaps the long name "substitute" would work? While it does loose the
brevity of subst, it's very clear about what it does and has the mnemonic
association with s///.
Sage
Juerd
> >Another issue is how we're going to pass arguments to this method. s///
> >has very special syntax, that I don't think we can easily replicate.
> S05 says it's $str.subst(regex, string-or-block); presumably the flags would
> go on the regex?
Ah, block.
Still, though, How would you specify :g? It doesn't make a lot of sense
on rx// -- just like you can't use it with qr// in Perl 5.
> > I personally still prefer $foo.s/// and $foo.=s///
> I don't really like the combination of quotelike and method call syntaxes.
> I would happily take "s" as a replacement for the method name, but I don't
> think it can happily coexist with the operator.
I was thinking of a postfix op (not normal postcircumfix, but quoting).
Postfix ops happen to be called with the dot too, but aren't necessarily
the same as methods.
> > because I don't think substitution belongs in a smart match op.
> Well, that's the reason for the method version in perl6. Which, AFAICT,
> returns the new string instead of the Match object, which is as it should
> be. The only thing I don't like is the name. :)
No, the method just returns the new string. The "inline" substitution is
still done with ~~ (although you can probably use .=subst too, but
really I don't like that syntax at all.)
I don't think using a method (even if called "s") is good huffman
coding. My expectation is that copying substitution will be used much -
perhaps even more than mutating substitution!
$foo.subst(/foo/, "bar")
$foo.s(/foo/, "bar")
$foo.s/foo/bar/
Hm. I don't know how "but" works exactly, but in the realm of syntactic
sugar, this is appealing:
$foo but s/foo/bar/
(Note that while " but " is long, it's extremely easy to type.)
Luke Palmer
> on rx// -- just like you can't use it with qr// in Perl 5.
It is a good point that it doesn't belong on the regex. Perhaps:
$foo.subst(/bar/, "baz", :g)
That seems to work, though the weight is at the front again. Oh.
$foo.subst(:g, /bar/, "baz")
> I don't think using a method (even if called "s") is good huffman
> coding. My expectation is that copying substitution will be used much -
> perhaps even more than mutating substitution!
And so a method called "s" is poor huffman coding... why? (I do agree
with your frequency conjecture)
Luke
Jerry Gay
> On 8/31/06, Juerd <ju...@convolution.nl> wrote:
> > Still, though, How would you specify :g? It doesn't make a lot of sense
> > on rx// -- just like you can't use it with qr// in Perl 5.
>
> It is a good point that it doesn't belong on the regex. Perhaps:
>
> $foo.subst(/bar/, "baz", :g)
>
> That seems to work, though the weight is at the front again. Oh.
>
> $foo.subst(:g, /bar/, "baz")
>
$foo.subst(/:g bar/, "baz")
is valid syntax already.
~jerry
Michael Snoyman
> > $foo.subst(:g, /bar/, "baz")
> >
> i seem to recall
>
> $foo.subst(/:g bar/, "baz")
>
> is valid syntax already.
>
If I'm not mistaken, the aversion to that syntax- as implied earlier in this
thread- was that the :g is really a modifier on the substitution, not on the
matching. (Please correct me if I'm wrong; as I look through the thread I
don't actually see the message I'm thinking of.)
That said, I think to a certain extend it *is* a modifier on the match.
It's saying "match bar globally," and then subst says "everything that the
regex matched should be replaced by baz." I think that's a pretty intuitive
way of handling the problem.
Michael
Jonathan Lang
> On 8/31/06, Juerd <ju...@convolution.nl> wrote:
> > Still, though, How would you specify :g? It doesn't make a lot of sense
> > on rx// -- just like you can't use it with qr// in Perl 5.
>
> It is a good point that it doesn't belong on the regex. Perhaps:
>
> $foo.subst(/bar/, "baz", :g)
>
> That seems to work, though the weight is at the front again. Oh.
>
> $foo.subst(:g, /bar/, "baz")
IIRC, :g is an adverb, and adverbs are merely syntactic sugar for
named parameters. So perhaps the signature for the substitution
method should include a slurpy hash of modifiers...
The question then becomes whether or not you can pass a modifier to
the regex in by means of the slurpy hash, or if it _has_ to be
packaged with the regex.
--
Jonathan "Dataweaver" Lang
Trey Harris
> Hm. I don't know how "but" works exactly, but in the realm of syntactic
> sugar, this is appealing:
>
> $foo but s/foo/bar/
I like it.
This should be easy to make work in theory, but for the problem with
C<but>'s semantics which I'll get to in a moment. C<but> can already take
a closure in addition to a role or enum:
my Point $p .= new;
$p.x = 3;
$p.y = 0;
my Point $z = $p but { .y = 17 };
in which case,
$x but { ... }
just translates into
do given $x { ...; $_ }
So extending it so that
$x but s/foo/bar/
just translates into
$x but { s/foo/bar/ }
seems like very simple and natural sugaring. You can obviously already use
that latter syntax of simply wrapping the substitution in a closure.
Except distressingly it doesn't do anything....
I think these semantics are Almost Right, but yet Entirely Wrong. The
problem is that C<but> reads to me as a *mutating* operator. That is, I
would expect the above code snippet to give me a C<$z.y> of 17, but leave
C<$p.y> as 0. Surely this is what one would expect from analogy of
0 but True
which I wouldn't think anyone wants to cause all uses of 0, from then on,
to booleanize true.
But yet C<but> with a closure doesn't copy, given the translation above,
or even allow modification, since C<given> doesn't either. $_ (in the
above case, $p) is set to point to the same object, and so $p.y and $z.y
are both modified (or rather, they both refer to the same object, which is
modified during assignment).
In other words, I would actually expect
$x but { ... }
to translate to
do given $x -> $_ is clone { ...; $_ }
where C<is clone> is a conjectural way of calling .clone if the argument
is an object type but reduces to C<is copy> if the argument is a value
type. (Neglecting for the moment that a pointy block doesn't appear to be
a valid argument for C<given>. Is this correct? If so, why?)
I do not think that C<but> should mutate its LHS, regardless what its RHS
is.
Trey
Juerd
> > I don't think using a method (even if called "s") is good huffman
> > coding. My expectation is that copying substitution will be used much -
> > perhaps even more than mutating substitution!
> And so a method called "s" is poor huffman coding... why? (I do agree
> with your frequency conjecture)
Because of the awkward syntax that goes with a method: two parens, four
delimiters, comma[s]?.
.s(/bar/, "baz"); # 20 keypresses on a US keyboard
While a postfix operator, with the same ".s" feel, could allow
.s/bar/baz/; # 12 keypresses on a US keyboard
And since it's something used a lot in expressions, you wouldn't use the
parenless form of the method call much.
We need a quotelike construct for this form of s/// for exactly the same
reason we need it for m// and the other s///. Our language deviates too
much from being Perl if we had only method forms.
$foo.match(/foo/);
$foo.subst(/foo/, "bar");
$foo.=subst(/foo/, "bar");
That just isn't Perlish, at all.
My suggestion for a s/// postfix op mainly stems from this argument, but
I really also believe that ~~ and s/// is a farfetched combination. Perl
5's =~ was a binding operator, and s/// fit right in. But Perl 6's ~~ is
a matching operator, and in my opinion should remain pure, and so: not
mutate.
I'm even a bit inclined to suggest that .m// should return matches,
while ~~m// should return a bool. But ignore that for now :)
Juerd
> > :g
> That said, I think to a certain extend it *is* a modifier on the match.
> It's saying "match bar globally," and then subst says "everything that the
> regex matched should be replaced by baz." I think that's a pretty intuitive
> way of handling the problem.
It is indeed a modifier on the *match*, or the *substitution*. Just not
on the *regex*. What you pass to a .subst method is a regex, not a
match. The difference is that matches and substitutions are actions,
while a regex is an object, i.e. data.
Juerd
> IIRC, :g is an adverb, and adverbs are merely syntactic sugar for
> named parameters. So perhaps the signature for the substitution
> method should include a slurpy hash of modifiers...
In which case you'd end up parsing the keys, because we have stuff like
:2nd and :3th. And if we're parsing anyway, you might as well pass in a
string. Indeed, :g would only be syntactic sugar.
Juerd
> I think these semantics are Almost Right, but yet Entirely Wrong. The
> problem is that C<but> reads to me as a *mutating* operator. That is, I
> would expect the above code snippet to give me a C<$z.y> of 17, but leave
> C<$p.y> as 0. Surely this is what one would expect from analogy of
In the terminology that I have been using, that would not be a mutating
operator, but a copying operator, exactly because the operand $p remains
untouched.
mutating:
sub foo ($foo is rw) { $foo = sqrt($foo) }
foo($bar);
$baz ~~ s/foo/bar/;
copying:
sub foo ($foo is copy) { $foo = sqrt($foo) }
foo($bar);
$baz.subst(/foo/, "bar");
> But yet C<but> with a closure doesn't copy, given the translation above,
> or even allow modification, since C<given> doesn't either. $_ (in the
> above case, $p) is set to point to the same object, and so $p.y and $z.y
> are both modified (or rather, they both refer to the same object, which is
> modified during assignment).
> In other words, I would actually expect
> $x but { ... }
> to translate to
> do given $x -> $_ is clone { ...; $_ }
Agreed that this would be much more useful.
> where C<is clone> is a conjectural way of calling .clone if the argument
> is an object type but reduces to C<is copy> if the argument is a value
> type.
Oh, I like "is clone" with these semantics. Though everything is an
object, so you'd need a different explanation...
> I do not think that C<but> should mutate its LHS, regardless what its RHS
> is.
Agreed, and that's why "$foo but s///" would be a reasonable replacement
for what's currently still "$foo.subst(//, '')". subst doesn't mutate.
Trey Harris
> Trey Harris skribis 2006-09-01 0:17 (-0700):
>> I think these semantics are Almost Right, but yet Entirely Wrong. The
>> problem is that C<but> reads to me as a *mutating* operator. That is, I
>> would expect the above code snippet to give me a C<$z.y> of 17, but leave
>> C<$p.y> as 0. Surely this is what one would expect from analogy of
>
> In the terminology that I have been using, that would not be a mutating
> operator, but a copying operator, exactly because the operand $p remains
> untouched.
Yes... I changed "copying" to "mutating" back and forth a couple times,
and then gave up, because of the "is clone" semantics I actually wanted
and didn't have a name for.
>> where C<is clone> is a conjectural way of calling .clone if the argument
>> is an object type but reduces to C<is copy> if the argument is a value
>> type.
>
> Oh, I like "is clone" with these semantics. Though everything is an
> object, so you'd need a different explanation...
Well, I'd say "value type" and "reference type", except we don't have
references anymore either. "value type" versus "non-value type", I guess.
Whether it defines .SKID or not?
Trey
Audrey Tang
> Luke Palmer skribis 2006-08-31 15:48 (-0600):
> > > I don't think using a method (even if called "s") is good huffman
> > > coding. My expectation is that copying substitution will be used much -
> > > perhaps even more than mutating substitution!
> > And so a method called "s" is poor huffman coding... why? (I do agree
> > with your frequency conjecture)
>
> Because of the awkward syntax that goes with a method: two parens, four
> delimiters, comma[s]?.
>
> .s(/bar/, "baz"); # 20 keypresses on a US keyboard
Minor nit, but:
.s: /bar/,'baz'; # 17 keypresses...
Audrey
Juerd
> > Because of the awkward syntax that goes with a method: two parens, four
> > delimiters, comma[s]?.
> > .s(/bar/, "baz"); # 20 keypresses on a US keyboard
> Minor nit, but:
> .s: /bar/,'baz'; # 17 keypresses...
"And since it's something used a lot in expressions, you wouldn't use
the parenless form of the method call much."
TSa
Trey Harris wrote:
> I do not think that C<but> should mutate its LHS, regardless what its
> RHS is.
I strongly agree. We have the mutating version
$p but= { .y = 17 };
which is just one char longer and nicely blends as a meta operator.
But are assignment ops allowed as initializer?
my $z = $p but= { .y = 17 };
Regards,
--
Larry Wall
: But are assignment ops allowed as initializer?
:
: my $z = $p but= { .y = 17 };
Why not? It's only the first = that's potentially special. (And it's
only for non-my, since my's = is an ordinary assignment at normal
run time.) I don't see much syntactic difference between your example and
state $z = $p += 17;
The fact that both of them modify $p in passing is unrelated to the
eventual use of the value to initialize something else.
Larry
Larry Wall
Well, okay, I should clarify that. The meaning of "$p += 17" is
unrelated. However, the declarator before the = does control when
and how often that expression is evaluated.
Larry