Mutating methods

[Juerd]

Perlists,

In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
chomp and chop do mutate.

I imagine these will all be methods in Perl 6:

$foo.lc
$foo.quotemeta
$foo.chomp

I'd like a mutating version of lc, and a non-mutating version of chomp.
With some nice syntax, if possible.

If there isn't already such a thing in the making, I hereby suggest to
re-introduce C<.=>, to mean more or less the same as in Perl 5, but with
Perl 6's version of the C<.> operator.

In other words: C<$foo.lc> would not mutate and C<$foo.=lc> would.

$foo += 5 ===> $foo = $foo + 5
$foo.=lc ===> $foo = $foo.lc

Makes sense to me.

Especially for C<sort> it would be nice for something like this:

@foo.sort # returns sorted copy

versus

@foo.=sort # sorts inline

I think this syntax reads better than Ruby's exclamation point
(foo.method!), because of the analogy with other mutating operators.

Please excuse me if this or something like this has already been taken
care of - I've searched for messages about it, but haven't found
anything.

Regards,

Juerd

[Luke Palmer]

Juerd writes:
> Perlists,
>
> In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
> chomp and chop do mutate.
>
> I imagine these will all be methods in Perl 6:
>
> $foo.lc
> $foo.quotemeta
> $foo.chomp
>
> I'd like a mutating version of lc, and a non-mutating version of chomp.
> With some nice syntax, if possible.
>
> If there isn't already such a thing in the making, I hereby suggest to
> re-introduce C<.=>, to mean more or less the same as in Perl 5, but with
> Perl 6's version of the C<.> operator.

I believe this has been discussed before, and that people generally
liked it. Maybe Larry even did (I seem to recall him saying something
positive about it -- but don't think he did just because I said so :-).
It seems likely that this will go in, though.

I'm in the mood for an exercise, so, here's how you implement it.

Let's say we have the Perl grammar:

grammar Perl
{
# ...
has %.assignment_ops is protected;
rule assignment_expression {
<assignment_lhs>
$op := (%.assignment_ops.keys())
$value := <%.assignment_ops{$op}{rule}>
{
$0 := %.assignment_ops{$op}{transform}($0)
if %.assignment_ops{$op}{transform}
}
}

rule method_call {
<term> <'.'> <method_name>
}
}

Or something. I'm just pulling that out of my ear.

Then we'll derive our own grammar with the C<.=> operator in, and plunk
it into Perl's parser.

grammar DotEqualsPerl is Perl
{
submethod BUILD() {
.assignment_ops{'.='} = {
rule => /<method_name>/,
transform => {

Perl::assignment_expression.new(
lhs => .{assignment_lhs},
rhs => Perl::method_call.new(
term => .{assignment_lhs},
method => .{value},
)
)

},
};
}
}

Finally, hooking it into Perl.

use grammar DotEqualsPerl;

Again, this is quite presumptuous about the workings of the Perl::*
classes. The Perl grammar will have to be extremely well documented.

The reason we couldn't just decalre it with C<infix:.=> is because its
right hand side is not a usual expression. That is:

$foo + bar;

Won't parse unless C<bar> is a declared sub, whereas:

$foo.bar;

Will always parse.

Luke

[Brent "Dax" Royal-Gordon]

Luke Palmer wrote:
> The reason we couldn't just decalre it with C<infix:.=> is because its
> right hand side is not a usual expression.

Isn't that what macros are for?

macro infix:.= ($lhs, $rhs) is parsed(/<method_name>/) {
return Perl::assignment_expression.new(
lhs => $lhs,
rhs => Perl::method_call.new(
term => $lhs,
method => $rhs,
)
);
}

TMTOWTDI, I suppose...

--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

Oceania has always been at war with Eastasia.

[Larry Wall]

On Wed, Mar 10, 2004 at 05:39:33PM +0100, Juerd wrote:
: Perlists,

:
: In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
: chomp and chop do mutate.
:
: I imagine these will all be methods in Perl 6:
:
: $foo.lc
: $foo.quotemeta
: $foo.chomp
:
: I'd like a mutating version of lc, and a non-mutating version of chomp.
: With some nice syntax, if possible.
:
: If there isn't already such a thing in the making, I hereby suggest to
: re-introduce C<.=>, to mean more or less the same as in Perl 5, but with
: Perl 6's version of the C<.> operator.

Except that C<.> isn't really a binary operator...

On the other hand, draft -1 of A12 has a conjectural

my Dog $dog .= new()

in it, and that's even further out there, since the .new on the right
would in fact be called on a $dog that is undefined!

: In other words: C<$foo.lc> would not mutate and C<$foo.=lc> would.

:
: $foo += 5 ===> $foo = $foo + 5
: $foo.=lc ===> $foo = $foo.lc
:
: Makes sense to me.

Yes, but the fact that you had to change the spacing bothers me.

: Especially for C<sort> it would be nice for something like this:
:
: @foo.sort # returns sorted copy
:
: versus
:
: @foo.=sort # sorts inline
:
: I think this syntax reads better than Ruby's exclamation point
: (foo.method!), because of the analogy with other mutating operators.

Well, I'd like to reserve postfix:! for factorial in any event. :-)

The basic problem with .= shows up when you do put the spaces in:

@foo .= sort()

That makes it look as though sort is a subroutine, and it's not.
That's a direct result of the fact that C<.> is not really a binary
operator. Rather, it's a kind of "operator sigil" that introduces
a unary postfix operator. Method calls are really unary postfix
operators that happen to be able to take extra arguments.

And because the op= syntax is really built for binary operators, it
doesn't totally work for unary operators. Take another unary postfix
operator, for instance, an array subscript:

@array[$x]

you can't just up and say

@array[=$x]

to mean

@array = @array[$x]

to turn it into a mutating operator, because the [$x] wants to
function as a unit, and the = breaks that up. Similarly, ".sort"
wants to function as a unit, but the = breaks that up, visually and
semantically.

However, having said all that, it turns out that A12 will also introduce
other "dot" variants:

$obj.?method # call method if exists, or return undef (0 or 1)
$obj.*method # call all base class methods of that name (0 or more)
$obj.+method # call all base class methods of that name (1 or more)

So a .=method syntax is not so farfetched. It analogies to +=, but it's
really still just a prefix to a unary postfix operator, like the other
dot variants. The interesting question with all of these "dots" is
where spaces are allowed or disallowed. One could make a case that
people will want to write

my Car $obj .= new()

rather than being forced to write

my Car $obj .=new()

It could even be argued that, in the case of this particular operator,
the = is functioning as part of the name, as the ! does in Ruby. So
if (hypothetically) we allow a space after the ordinary dot

@array . sort

then we could also allow things like:

@array . =sort
$obj . *initialize
$obj . ?maybe

But I dislike

$variable . meth()

for the same reason I dislike

$variable .= meth()

because it makes meth look like a subroutine call when it isn't. Regardless
of how fancy they get, method calls are still postfix operators. So I'm
inclined to say that the space is only optional before the dot, and you have
to say

@array .sort
@array .=sort
$obj .*initialize
$obj .?maybe

But that still makes

my Cat $tom .=new()

pretty ugly. Unfortunately we can't just use topicalization to say

my Cat $tom = .new()

because most people won't expect simple assignment to break their
current topic.

So another option is to replace = with something that I<does> set the
topic for the right side. If we used .= for that, then you'd have
to write

@array .= .sort
my Cat $tom .= .new()

Doubtless the first would get shortened to

@array.=.sort

That does admit to constructs like

$foo .= .*bar

which would assign $foo a list of all the return values of $foo.*bar, or

$foo .= .?maybe

which would presumably replace $foo with an undefined value if
it couldn't find $foo.maybe. Those don't seem terribly useful as
mutators though. They'd be much clearer written out long.

Another approach would be to have some kind of "microtopic" that
represented the left side of an ordinary assignment. Suppose for
the sake of argument that the microtopic is ^. Then you could write

@array = ^.sort;

and a constructor would be

my Kanga $roo = ^.new()

But that introduces a new concept that doesn't really generalize well.
So forget that.

Yet another approach is to *replace* dot with something that mutates:

@array!sort
@array?sort

Either of those would work syntactically in that case, since neither !
nor ? is expected as a binary operator. However, the unary cases
don't work:

!sort means "not sort"
?sort means "did sort work?"

We could prefix *those* with a dot, but .? is already taken. That leaves

@array.!sort

which is sort of inside-out Ruby. But then the constructor doesn't
read so well:

my Dino $dinah is fossilized .!new()

Constructors really, really want = for visual reasons...

We could do something *really* crazy and say that if the assignment
operator is immediately followed by a dot, that dot topicalizes to
the left side of the equals rather than the current topic. That
gives us

@array=.sort

and

my Dino $dinah is fossilized = .new()

That would mean that if you really wanted the current topic, you'd have
to say things like

@array = $_.sort
my Dino $dinah is fossilized = (.new())

I think that would be a bad thing to do to the = operator.

Or we could introduce an =. operator. In which case the mutators
look like

@array=.sort
my Dino $dinah is fossilized =.new()

and the regular $_ topicalized ones look like

@array = .sort
my Dino $dinah is fossilized = .new()

But the problem is that those look far too much alike.

So I think we're left with .= as an analog of .* and .?:

@array .=sort
my Dino $dinah is fossilized .=new()

Perhaps it's not too bad to allow spaces after the compound dot operators:

@array . sort
@array .= sort
$obj .? maybe
$obj .* initialize
$obj .+ initialize

After all, the computer won't get confused that a methodname is required
next. Except that we also have to figure out what these mean, if anything:

$obj .$x # indirect method name like Perl 5?
$obj .=$x # indirect mutating operator
$obj .?$x # indirect optional method
$obj .*$x # indirect all method
$obj .+$x # indirect one or more method

&obj .($x) # sub call on code reference
&obj .=($x) # ???
&obj .?($x) # ???
&obj .*($x) # ???
&obj .+($x) # ???

@obj .[$x] # subscript on array reference
@obj .=[$x] # replace array with slice of array
@obj .?[$x] # ???
@obj .*[$x] # ???
@obj .+[$x] # ???

%obj .{$x} # subscript on hash reference
%obj .={$x} # replace hash with slice of hash
%obj .?{$x} # ???
%obj .*{$x} # ???
%obj .+{$x} # ???

and whether a space is allowed after those dotty operators. The whole
reason for .(), .[] and .{} in the first place was to make them look
like postfix ops rather than terms. Allowing space after the dot works
against that. I suspect all the ones marked ??? are simply disallowed
in any event. So we could probably get away with allowing space after .=
as a special case. But maybe we want to discourage that too.

: Please excuse me if this or something like this has already been taken

: care of - I've searched for messages about it, but haven't found
: anything.

It was discussed a long time ago, but nothing substantial came of it.
It certainly needs to be nailed down for A12 though.

Larry

[Larry Wall]

On Wed, Mar 10, 2004 at 11:19:52AM -0800, Brent Dax Royal-Gordon wrote:
: Luke Palmer wrote:
: >The reason we couldn't just decalre it with C<infix:.=> is because its
: >right hand side is not a usual expression.
:
: Isn't that what macros are for?
:
: macro infix:.= ($lhs, $rhs) is parsed(/<method_name>/) {

Methods are really postfix operators, so that would probably be
something more like:

macro postfix:.= ($lhs, $parsetree)
is parsed(/<ws>? <?method_name> <?method_args>/) {

That's presuming we allow whitespace after the . and .= ops.

(Also, these days you have to say <?foo> to collect the results into $0.)

Larry

[Luke Palmer]

Hooray! That was something I had been worried about.

But C<?> doesn't seem to fit visually. What's "questionable" about
that?

I can think of a couple that I like better:

<^foo>
<*foo>

<^foo> is my favorite at the moment (even though <*foo> is more
visually pleasing), because it looks like it's transferring the
information ^up^ in the parse tree.

Luke

[Damian Conway]

Luke Palmer wrote:

> Hooray! That was something I had been worried about.
>
> But C<?> doesn't seem to fit visually. What's "questionable" about
> that?

Nothing questionable, but
everything hypothetical:

<?foo> captures to the
$?foo hypothetical variable

Damian

[Larry Wall]

On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
: > (Also, these days you have to say <?foo> to collect the results into $0.)

:
: Hooray! That was something I had been worried about.
:
: But C<?> doesn't seem to fit visually. What's "questionable" about
: that?

It's questionable insofar as it's hypothetical. It maps to $?foo,
which is the name of the (current value of the) capture within any
interior closure:

/<?foo> { say "Guessing $?foo for the moment..." <bar> } /

: I can think of a couple that I like better:

:
: <^foo>
: <*foo>
:
: <^foo> is my favorite at the moment (even though <*foo> is more
: visually pleasing), because it looks like it's transferring the
: information ^up^ in the parse tree.

But $^foo and $*foo mean very different things from hypotheticals.

And in a real sense $?foo is passing guessed information *down*
the match. The guesses only turn out "right" if you get all the way
to the bottom successfully. (That's from the point of view that
you recurse deeper to check anything to the right in a regex, even
when syntactically it's shallower.)

Larry

[Luke Palmer]

Hmm... that makes sense.

It doesn't feel right, though. After all, we don't say:

($minutes, $seconds) = m/ (? \d\d ) : (? \d\d ) /;

Even though they only stay matched if they get to the end without
backtracking. Capturing (this is really just a clever notation for
captures) is usually about communicating information I<outside> of the
match: to the parent rule, to the the calling scope.

As you showed in your reply about C<.=>:

macro postfix:.= ($lhs, $parsetree)
is parsed(/<ws>? <?method_name> <?method_args>/)

{ ... }

There's nothing about C<?> that makes me think that these are being
stored.

I understand the association with C<$?foo>. But most of the time, when
I'm writing a grammar, I'm catching these rules in order to stick them
in the parse tree, not to do tests on them later on in the rule. The
very essence of rules is hypotheticality, where nothing is permanent
until it gets to the end. I don't think we need a special marker that
says "these do that, too."

Luke

[Damian Conway]

Luke Palmer wrote:

> I understand the association with C<$?foo>. But most of the time, when
> I'm writing a grammar, I'm catching these rules in order to stick them
> in the parse tree, not to do tests on them later on in the rule. The
> very essence of rules is hypotheticality, where nothing is permanent
> until it gets to the end. I don't think we need a special marker that
> says "these do that, too."

We need the marker to distinguish between hypothetical captures to internal
variables:

/ $?foo:=(abc) $?bar:=(def) /

and non-hypothetical captures to external variable:

/ $foo:=(abc) $bar:=(def) /

And since subrules that capture always capture to hypotheticals, we need the
same marker there.

Damian

[Brent "Dax" Royal-Gordon]

Damian Conway wrote:
> / $foo:=(abc) $bar:=(def) /

Am I misreading, or are you suggesting that $foo may contain 'abc' after
running this example, even if the match wasn't successful?

[Damian Conway]

Brent "Dax" Royal-Gordon wrote:

>> / $foo:=(abc) $bar:=(def) /
>
> Am I misreading, or are you suggesting that $foo may contain 'abc' after
> running this example, even if the match wasn't successful?

No. I re-checked with Larry this morning and he confirmed that all bindings in
rules only "stick" if the rule as a whole succeeds.

What I was trying (obviously rather ineptly ;-) to point out is that we have
to be able to differentiate between the the match object's own internal
hypothetical variables ($?foo, $?bar, @?baz) and any
external-but-temporarily-hypothesized variables ($foo, $bar, @baz).

The syntax we've chosen to do that requires the use of "?" as a secondary
sigil on internal variables. So, since named subrules that capture always
capture to internal variables, it's natural and consistent to use "?" to
indicate capturing subrules as well.

Damian

[Matt]

I was thinking along the lines of...

String $foo = "hello";
$foo.scramble!
print "$foo\n";
$foo = "hello"
print $foo.scramble ~ "\n";
print $foo;

OUTPUT (or close):
elhlo
hloel
hello

Also, along these same things.. is there a way to apply a method to all
variables/objects of a certain type (e.g. String, Num, etc)? Taking the
above example.. being able to write a method called "Scramble" that can be
called as a method from any String type.

[Larry Wall]

On Wed, Mar 10, 2004 at 10:46:05PM -0500, matt wrote:
: I was thinking along the lines of...

:
: String $foo = "hello";
: $foo.scramble!

That would be $foo.=scramble in the current scheme of things.

: print "$foo\n";

: $foo = "hello"
: print $foo.scramble ~ "\n";
: print $foo;
:
: OUTPUT (or close):
: elhlo
: hloel
: hello
:
: Also, along these same things.. is there a way to apply a method to all
: variables/objects of a certain type (e.g. String, Num, etc)? Taking the
: above example.. being able to write a method called "Scramble" that can be
: called as a method from any String type.

Two ways, actually. You can 'reopen" the String class and add the method:

class String is extended {
method scramble () returns String {...}
}

or if you consider that underhanded, you can define a multi-sub:

multi sub *scramble (String $s) returns String {...}

If you call that as a method, and there is no ordinary scramble method,
it will "fail soft" to looking for a scramble multimethod, and end up
calling your definition. Or you can just call it directly as a function:

scramble("hello")

Larry

[Austin Hastings]

Isn't this backwards?

That is, from the above I get the impression that $?foo is TRANSIENT, while
capturing to $foo will (eventually) be PERMANENT.

So <?foo> is just a shorthand way of saying

$?foo := <foo>

right?

Is hypo-space a flat entity, or do hypothetical scopes nest? If so, do we
have to use repeated ?'s, or will just one suffice?

That is:

rule bar {...}
rule baz {...}
rule foo {...bar...baz...}

if / <?foo> ... <?baz> ... { $?foo.?baz ... $?baz } .../
OR
if / <?foo> ... <?baz> ... { $?foo.baz ... $?baz } .../
OR
if / <?foo> ... <?baz> ... { $?baz ... $?otherbaz } .../

=Austin

[Larry Wall]

On Thu, Mar 11, 2004 at 01:09:59AM -0500, Austin Hastings wrote:
:
:
: > -----Original Message-----

: > From: Damian Conway [mailto:dam...@conway.org]
: > Sent: Wednesday, 10 March, 2004 09:48 PM
: > To: perl6-l...@perl.org
: > Subject: Re: Mutating methods
: >
: >
: > Brent "Dax" Royal-Gordon wrote:
: >
: > >> / $foo:=(abc) $bar:=(def) /
: > >
: > > Am I misreading, or are you suggesting that $foo may contain
: > 'abc' after
: > > running this example, even if the match wasn't successful?
: >
: > No. I re-checked with Larry this morning and he confirmed that
: > all bindings in
: > rules only "stick" if the rule as a whole succeeds.
: >
: > What I was trying (obviously rather ineptly ;-) to point out is
: > that we have
: > to be able to differentiate between the the match object's own internal
: > hypothetical variables ($?foo, $?bar, @?baz) and any
: > external-but-temporarily-hypothesized variables ($foo, $bar, @baz).
: >
: > The syntax we've chosen to do that requires the use of "?" as a secondary
: > sigil on internal variables. So, since named subrules that capture always
: > capture to internal variables, it's natural and consistent to use "?" to
: > indicate capturing subrules as well.
:
: Isn't this backwards?
:
: That is, from the above I get the impression that $?foo is TRANSIENT, while
: capturing to $foo will (eventually) be PERMANENT.

$?foo is exactly as transient as the $0 in which it resides. So it
really depends on how long $0 lives outside the regex. In the case
of a returned parse tree it could live a very long time.

: So <?foo> is just a shorthand way of saying
:
: $?foo := <foo>
:
: right?

Yes. The ? is actually serving as a scope marker telling Perl not
to scan outside of the current regex for a variable of that name.
If you consider each rule to be its own package, it's kind of an "our"
declaration within the rule.

: Is hypo-space a flat entity, or do hypothetical scopes nest?

Um, the namespace inside a particular rule is flat, just as the
namespace inside a package is flat. That doesn't mean that your code
won't visit those variables in whatever order it jolly well pleases.
Dynamically speaking, every assertion in a regex is recursively matched "inside"
the results of previous successful assertions, regardless of the
lexical structure of the rule. You're often in situations where dynamically
you're going down recursively, while in terms of where you are in the
match, you're going out of brackets or parens. It has to be that way,
or you could never backtrack into a set of brackets or parents.

But once a subrule is matched, all its ? names are bundled up into
a hash in the single "$0"-ish object that becomes aliased (at least
temporarily) to the $?foo in the outer rule. The keys of that hash are
flat for all the names in the particular rule, though of course some
of the values may be nested $0 results from subrules. So effectively
you end up with a hash of hash of hash of hash.... representing the
entire syntax tree. But any given rule can't produce more than one
level of hash (without doing something freaky like rewriting your
hash entries inside a closure).

: If so, do we

: have to use repeated ?'s, or will just one suffice?
:
: That is:
:
: rule bar {...}
: rule baz {...}
: rule foo {...bar...baz...}
:
: if / <?foo> ... <?baz> ... { $?foo.?baz ... $?baz } .../
: OR
: if / <?foo> ... <?baz> ... { $?foo.baz ... $?baz } .../
: OR
: if / <?foo> ... <?baz> ... { $?baz ... $?otherbaz } .../

Well, you don't need "?" to go down the syntax tree, since each $0
can behave as a hash. You don't subscript hashes using "." either.
You subscript hashes with {...} historically, or these days, «...»,
when you want constant subscripts. So what you're looking for is
something like:

if / <?foo> ... <?baz> ... { $?foo{'baz'} ... $?baz } .../

or

if / <?foo> ... <?baz> ... { $?foo«baz» ... $?baz } .../

or even:

if / <?foo> ... <?baz> ... { $0«foo»«baz» ... $0«baz» } .../

Oh, and since the current $0 is actually the topic of any closure,
you can also probably say

if / <?foo> ... <?baz> ... { .«foo»«baz» ... .«baz» } .../

as an analog to

if / <?foo> ... <?baz> ... { .{'foo'}{'baz'} ... .{'baz'} } .../

That's presuming we keep the rule that scalars don't have to include
the sigils. For an array you'd still have to say:

if / @?things:=[ (<ident>) ,? ]+ { ... $0«@?things» ... } /

or

if / @?things:=[ (<ident>) ,? ]+ { ... .«@?things» ... } /

But then it's usually easier just to say

if / @?things:=[ (<ident>) ,? ]+ { ... @?things ... } /

which means exactly the same thing.

Larry

[Andy Wardley]

Larry Wall wrote:
> multi sub *scramble (String $s) returns String {...}

[...]

> Or you can just call it directly as a function:
> scramble("hello")

Can you also call scramble as a class method?

class String is extended {
method scramble { ..etc... }
}

String.scramble("hello")

A

[Andy Wardley]

Larry Wall wrote:
> Yet another approach is to *replace* dot with something that mutates:
>
> @array!sort
> @array?sort
>
> Either of those would work syntactically in that case, since neither !
> nor ? is expected as a binary operator.

What about ? is as a ternary operator:

@foo?bar:baz;

Or am I missing.something?

A

[Uri Guttman]

>>>>> "AW" == Andy Wardley <a...@andywardley.com> writes:

AW> What about ? is as a ternary operator:

AW> @foo?bar:baz;

IIRC, that was changed to ?? :: because larry wanted the single ? for
more important uses. also doubling the ? made it more like &&, || which
are related logical ops.

and ?? as the oneshot regex match is totally out.

uri

--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

[Gregor N. Purdy]

Larry --

So, will "mutatingness" be a context we'll be able to inquire on
in the implementation of a called routine? Or, could we provide
a specialized distinct implementation for mutating that would get
called if .=X() is used? If we are performing some operation on
large data, and we know the end result is going to clobber the
current object, we could avoid making an extra copy.

I suppose there is some danger here. What if I write a class
that I intend to have value semantics. That is, once an instance's
value is set at construction time, it never changes, although you
can get new instances by invoking its methods. BigInt would
work this way. I can imagine a Point class working this way - you
don't (necessarily) want two objects hanging on to a point, and one
of them to mutate it into a different value out from under the other
one. You wouldn't expect that behavior from other value objects such
as built-in strings.

This points at mutatingness being aimed at the reference (variable)
not the referrent (value), unless it can be different in the case
of value-objects and container-objects...

So, if we had a BigDataContainer class for which it *was* reasonable
to mutate it in place, and we wanted that behavior to trigger on .=
to do an in-place modification:

$bigData .=applyBlockCipher($cipher, $key);

would there be a way to do that without the extra copy implied in:

$bigData = $bigData.applyBlockCipher($cipher, $key);

while leaving

$foo .=someOtherMethod();

equivalent to

$foo = $foo.someOtherMethod();

when $foo's class or someOtherMethod() implementation doesn't do
anything special?

Regards,

-- Gregor

--
Gregor Purdy gre...@focusresearch.com
Focus Research, Inc. http://www.focusresearch.com/

[Larry Wall]

Not unless you write a class method that takes an extra argument.
Otherwise you're passing a class where it expects a string, and a
string where it expects nothing. However, much like in Perl 5 you
can always force which class's method to call with

"hello".String::scramble();

Larry

[Larry Wall]

On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
: So, will "mutatingness" be a context we'll be able to inquire on

: in the implementation of a called routine?

Probably not, but it's vaguely possible you could somehow get a
reference to what is being assigned to, if available, and check to see
if $dest =:= $src (where =:= tests to see if two refs point to the
same object). But in general I think most "want" testing is just a
way of making code run slow, because it forces tests to be done at run
time that should be done at compile time or dispatch time. It's better
for the optimizer if you can give it enough type hints and signature
hints to decide things earlier than the body of the sub or method.

: Or, could we provide a specialized distinct implementation

: for mutating that would get called if .=X() is used?

That is much more likely. In general if you don't define both an <op>
and an <op>= then Perl can autogenerate or emulate the missing one for you.

Now in the specific case of . and .= we don't exactly have a normal
binary operator, because the right side is not an expression. So we
may have to provide a way of marking a normal method as a mutator.
Possibly we end up with

method =sort (Array @ary) returns Array {...} # inplace
method sort (Array @ary) returns Array {...} # cloning

That works nicely with the .= vs . distinction, visually speaking.

On the other hand, you might want to do the same with multi subs:

multi sub =sort (Array @ary) returns Array {...} # inplace
multi sub sort (Array @ary) returns Array {...} # cloning

and then it gets a little more problematic syntactically because
multis are called like subroutines:

=sort(@array);

We would have to allow an initial = at the beginning of a term. So far
I've resisted doing that because I don't want

@obj.meth=foo();

to become ambiguous, in case I decide to make the parentheses optional
on method calls with arguments. If I did decide that, and we have
terms beginning with =, it would not be clear whether the above meant

@obj.meth(=foo());

or

@obj.meth=(foo());

The = prefix notation also doesn't work very well for talking about the
name of a routine:

&=sort

That looks an awful lot like a junctive assignment operator...

From a C++-ish perspective, the right thing to do is to differentiate
not by the name but by the declared mutability of the invocant:

multi sub sort (Array @ary is rw) returns Array {...} # inplace
multi sub sort (Array @ary) returns Array {...} # cloning

Or I suppose a case could be made for something that specifically
declares you're returning one of the arguments:

multi sub sort (Array @ary is rw) returns @ary {...} # inplace

After all, it's possible to write a method that mutates its invocant
but *doesn't* return it like a well-behaved mutator should. You don't
always call a mutator in a void context--sometimes you want
to be able to stack mutators:

@array.=sort.=uniq;

So you have to be able to return the mutant as well as mutate it in place.

On the other hand, I'm deeply suspicious of a return signature that
mentions a specific variable. What if the body says to return something
else? Is that just ignored? Do we check it to see if it's the same
item?

So my guess is that it's probably better to have something more specific
for the mutator "template". I think, actually, that I've convinced myself
that a mutator should be marked in its name, and that it should generally
be defined as a standard method rather than a multi sub:

method =sort (Array @ary is rw) {...} # inplace

This would automatically arrange to return the invocant.
It would be illegal to use C<return> in such a routine. And I guess,
since it's an ordinary method, we can leave out the invocant:

method =sort () {...} # inplace

with the assumption that the default invocant on a mutator would
automatically be assumed "rw".

If you do happen to want to define a multi sub mutator, then the
syntax for calling it could be

&«=sort»(@array)

However, we really don't have to special case the = prefix syntax if
we make it something like:

method postfix:.=sort () {...} # inplace
multi sub postfix:.=sort () {...} # inplace

That's getting way up there on the ugliness factor. Might be worth
a new operator category:

method mutate:sort () {...} # inplace
multi sub mutate:sort () {...} # inplace

or

method inplace:sort () {...} # inplace
multi sub inplace:sort () {...} # inplace

or

method rw:sort () {...} # inplace
multi sub rw:sort () {...} # inplace

or

method self:sort () {...} # inplace
multi sub self:sort () {...} # inplace

On the final hand, if people fall in love with both self:sort and =sort, we
could have =sort be a shorthand for self:sort where it's unambiguous.

On the (n+1)st hand, that says we could write it either as

@array.=sort.=uniq

or

@array.self:sort.self:uniq

Perhaps that's okay under TMTOWTDI. I actually find the shorter one
more readable. But then calling it as a sub would always just be

self:sort(@array);

And then,

.self:sort

might or might not be preferred over

.=sort

: If we are performing some operation on

: large data, and we know the end result is going to clobber the
: current object, we could avoid making an extra copy.

Yes, computer performance is desirable. but I think the biggest goal
of the mutating operators is mental performance. The fact is that

$a += 1;

is much easier to understand than

$a = $a + 1;

: I suppose there is some danger here. What if I write a class

: that I intend to have value semantics. That is, once an instance's
: value is set at construction time, it never changes, although you
: can get new instances by invoking its methods. BigInt would
: work this way. I can imagine a Point class working this way - you
: don't (necessarily) want two objects hanging on to a point, and one
: of them to mutate it into a different value out from under the other
: one. You wouldn't expect that behavior from other value objects such
: as built-in strings.
:
: This points at mutatingness being aimed at the reference (variable)
: not the referrent (value), unless it can be different in the case
: of value-objects and container-objects...
:
: So, if we had a BigDataContainer class for which it *was* reasonable
: to mutate it in place, and we wanted that behavior to trigger on .=
: to do an in-place modification:
:
: $bigData .=applyBlockCipher($cipher, $key);
:
: would there be a way to do that without the extra copy implied in:
:
: $bigData = $bigData.applyBlockCipher($cipher, $key);
:
: while leaving
:
: $foo .=someOtherMethod();
:
: equivalent to
:
: $foo = $foo.someOtherMethod();
:
: when $foo's class or someOtherMethod() implementation doesn't do
: anything special?

We can autogenerate routines however we like as long as the metadata
is there to decide how to do it. In this case any autogenerated <op>=
is going to call the (presumably cloning) <op> and then assign the
resulting reference back to the source. So the default would do what
you want, I think.

Going the other way, if you only define <op>=, then an autogenerated
<op> would presumably .clone the object before doing the <op>= on it.

It also may be that these can work a little differently if you know
the underlying datatype is copy-on-write.

Larry

[Jonathan Scott Duff]

On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote:
> On the final hand, if people fall in love with both self:sort and =sort, we
> could have =sort be a shorthand for self:sort where it's unambiguous.

Wouldn't =sort potentially muck with POD?

-Scott
--
Jonathan Scott Duff
du...@pobox.com

[Larry Wall]

On Thu, Mar 11, 2004 at 02:05:55PM -0600, Jonathan Scott Duff wrote:

: On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote:
: > On the final hand, if people fall in love with both self:sort and =sort, we
: > could have =sort be a shorthand for self:sort where it's unambiguous.
:
: Wouldn't =sort potentially muck with POD?

Could. Historically pod only pays attention to = on the left margin though.
So you generally wouldn't have any problem unless you were in the habit
of declaring your methods in the C-ish idiom of:

int method
=rotate (int $a is rw) {...}

On the other hand, I suspect most people will end up declaring it

int method
self:rotate (int $a is rw) {...}

in any event, and reserve the =rotate for .=rotate, which can never put
the = on the left margin, even if we let ourselves have whitespace
before POD directives. So maybe we just require self: for the declaration,
and forget about = there. It interacts badly with global names anyway.
Is it "*=sort" or "=*sort"? With "*self:sort" it's more obvious.

Another interesting question, if the "postfix:.=foo" mess is defined
with as self:foo, should infix:+= be defined as self:+ instead?
In other words, should the <op>= syntax really be a metasyntax like
hyperoperators, where you never actually have to define a C<»+«>
operator, but the hyperoperator is always autogenerated from ordinary
C<+>? So basically any infix:<op>= gets remapped to self:<op>.

In that case, C<»+=«> is a double-meta operator that ends up generating
a hyper self:+.

I kinda like this approach because it means you can always get all of

$a !! $b
$a !!= $b
@a »!!« @b
@a »!!=« @b

merely by defining infix:!!. On the other hand, it also means that
someone can say silly things like:

$a cmp= $b
$a ~~= $b

I suppose we could simply disallow meta-= on non-associating operators.
Can anyone come up with a non-associating binary operator that *should*
have an assignment operator? The basic definition of non-associating
seems to be that the type of the arguments is incompatible with the
type produced by the operator. Which is precisely the problem with
something like

$a cmp= $b

insofar as $a is being treated as a string at one moment and as a boolean
at the next.

Larry

[Larry Wall]

On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote:
: Which is precisely the problem with something like

:
: $a cmp= $b
:
: insofar as $a is being treated as a string at one moment and as a boolean
: at the next.

Well, okay, not a boolean. More like a troolean.

Larry

[John Siracusa]

Back in myyyyy daaayyyy, we used to call that a "scalar." And we liked it,
because it was all we had! ;)

-John

[Chromatic]

On Thu, 2004-03-11 at 13:04, Larry Wall wrote:

> Well, okay, not a boolean. More like a troolean.

Unless it's a falselean.

-- c

[Larry Wall]

On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote:

: On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
:
: > Well, okay, not a boolean. More like a troolean.
:
: Unless it's a falselean.

It's more truelean than falselean by a 2/3rds majority. And it's
much more if you include 2, -2, 3, -3,... in the data type. And it's
*very* much more if you include the reals....

Larry

[Matthew Walton]

So that's a (numeric) scalar then...

I'm new to this list, although I've been keeping an eye on Perl 6 for
quite a while now as it's looking like it's going to be an extremely
pleasant language to work with. Seems I joined at the right time as
well, for these mutators are an interesting thing. Please excuse my no
doubt numerous abuses of conventional formatting used here as I don't
know it yet, and I've got a very shaky knowledge of some parts of the
Perl 6 grammar that everyone posting seems to know.

However, it strikes me that notation like

int method =foo(String $bar) {...}

is at risk of causing serious confusion to people coming from other
languages. This may not be a concern, of course (and isn't really one of
mine despite being a C++/Perl 5/Haskell kind of person at the moment).
It seems that

int method self:foo(String $bar) {...}

is clearer and easier to read, but I did actually prefer

int method mutate:foo(String $bar) {...}

or

int method inplace:foo(String $bar) {...}

which seem to have been dismissed in favour of the form using C<self>,
although I can see that it does have a valid interpretation. Perhaps I'm
just too stuck in writing member subs of objects in Perl 5 by saying

sub foo {
my $self = shift;
# something useful here
}

so I always see 'self' as reading something like 'this' does in C++ or
Java (or as 'self' does in Python, if I'm remembering that correctly).
There is undeniable logic in using it to define mutators though, as they
do most certainly act upon 'self' or 'this' or whatever it's called.

One is lead to wonder if the most appropriate definition might not be

int method mutator:foo(String $bar) { ... }

but that's getting very silly, so maybe just ignore everything I said
just now and cheer the introduction of C<self> as the most practical and
least prone to the introduction of finger trouble.

And having said all that, I like .= as invocation syntax for it, even if
I keep thinking it means 'append string'.

Anyway, thankyou for listening, I shall return now to watching in awe.

Matthew

[Damian Conway]

Larry wrote:

> On the other hand, I suspect most people will end up declaring it
>
> int method
> self:rotate (int $a is rw) {...}
>
> in any event, and reserve the =rotate for .=rotate, which can never put
> the = on the left margin, even if we let ourselves have whitespace
> before POD directives. So maybe we just require self: for the declaration,
> and forget about = there.

Yes please!

> It interacts badly with global names anyway.
> Is it "*=sort" or "=*sort"? With "*self:sort" it's more obvious.

Agreed. I'd *very* much prefer to see "reflexive" methods like this declared
C<self:methodname>. From a readability stand-point, if for no other reason.

> Another interesting question, if the "postfix:.=foo" mess is defined
> with as self:foo, should infix:+= be defined as self:+ instead?
> In other words, should the <op>= syntax really be a metasyntax like
> hyperoperators, where you never actually have to define a C<»+«>
> operator, but the hyperoperator is always autogenerated from ordinary
> C<+>? So basically any infix:<op>= gets remapped to self:<op>.

I think that would be cleaner.

> On the other hand, it also means that
> someone can say silly things like:
>
> $a cmp= $b
> $a ~~= $b
>
> I suppose we could simply disallow meta-= on non-associating operators.
> Can anyone come up with a non-associating binary operator that *should*
> have an assignment operator? The basic definition of non-associating
> seems to be that the type of the arguments is incompatible with the
> type produced by the operator. Which is precisely the problem with
> something like
>
> $a cmp= $b
>
> insofar as $a is being treated as a string at one moment and as a boolean
> at the next.

I think it's "merely" a philosophical problem.

After all, we don't complain when people write:

$a = $a cmp $b;

So should we complain when people write exactly the same thing, only as:

$a cmp= $b;

Stylistically, they're equally as abhorrent, but Perl users aren't expecting
the Stylish Inquisition.

The real question is whether the two forms are equally likely to indicate a
logic error. One could argue that anyone who writes the first is more likely
just being (small-l) lazy, whereas writing the second probably indicates a
"thinko". But then one could also argue that it's (small-l) lazier to write
the second than the first, so the second is actually *more* likely to be
(small-l) laziness than error.

There are also cases where something like:

$a ||= $b;

or:

$a += $b;

changes the type of value in $a. Should we flag those too? Currently we do
warn on the second one if $a can't be cleanly coerced to numeric. Would that
be enough for C<cmp=> too, perhaps?

Damian