[Pdl-porters] Mimick Sentinel for proper "=" behavior

[David Mertens]

Hey everyone,

The Perl documentation on lvalue subs mentions Sentinel
<https://metacpan.org/pod/Sentinel>, a CPAN distribution which provides a
simple mechanism for controlling modification of an lvalue by "="
assignment. This is the simplest module I have seen to date with this
behavior. It achieves this behavior by overriding the get and set magic
methods (and the free magic method, for cleanup of course) for the scalar.
I would bet that if we set the same magic methods in our core pdl creation
method(s), we could get "=" assignment to Just Work. (Side note: this would
work regardless of how we do lvalue handling.)

The only trick then would be to make sure that somebody could reuse the
same $variable_name to refer to completely different piddles, rather than
croaking on mismatched thread dimensions.

I have considered the silent, unintended failure of "=" to be a wart in
PDL. It should at least warn, in a way that I can control.

Thoughts?
David

[Chris Marshall]

Neat! Is there a standard way to implement an '='
overload that does what we want for PDL? I.e., is
there some sort of flowchart for a "proper" implementation
(perhaps from another OO language)?

--Chris

Post by David Mertens
Hey everyone,
The Perl documentation on lvalue subs mentions Sentinel, a CPAN distribution
which provides a simple mechanism for controlling modification of an lvalue
by "=" assignment. This is the simplest module I have seen to date with this
behavior. It achieves this behavior by overriding the get and set magic
methods (and the free magic method, for cleanup of course) for the scalar. I
would bet that if we set the same magic methods in our core pdl creation
method(s), we could get "=" assignment to Just Work. (Side note: this would
work regardless of how we do lvalue handling.)
The only trick then would be to make sure that somebody could reuse the same
$variable_name to refer to completely different piddles, rather than
croaking on mismatched thread dimensions.
I have considered the silent, unintended failure of "=" to be a wart in PDL.
It should at least warn, in a way that I can control.
Thoughts?
David
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[David Mertens]

Argh,

Having thought about this some more, I realized that my initial idea won't
work, not exactly. The thing is that the "get" magic for "=" is assigned to
the *scalar*, not the *scalar* *reference*. That is, if I have

my $data = pdl(@stuff);

then $data is the scalar, and it is a reference to the opaque PDL object.
We need change $data. Even if pdl() returns a scalar with get and set
magic, Perl will copy that scalar reference in the assignment to $data.

To test out this theory, I simply played a bit with basic tied scalars.
Here is my research:

----%<----

use strict;
use warnings;

package PDL::Sentinel;

sub TIESCALAR {
my ($class, $pdl) = @_;
return bless \$pdl, $class;
}

sub FETCH { return ${$_[0]} }

sub STORE {
my ($self, $new_data) = @_;
$$self .= $new_data;
return $self;
}

package main;

### Basic usage with direct tie works

use PDL;
my $data = sequence(10);
my $nice;
tie $nice, 'PDL::Sentinel', $data;
$nice = 5;

# Prints [5 5 5 5 5 5 5 5 5 5]
print "data is $nice\n";


### Can I return a tie'd scalar?

sub return_assignable {
my $new_data = sequence(10);
my $to_return;
tie $to_return, 'PDL::Sentinel', $new_data;
return $to_return;
}

my $new_thing = return_assignable;
print "new thing was $new_thing\n";
$new_thing = 0;

# Nope: prints 0
print "Now, new thing is $new_thing\n";


### Can I make the process of tie'ing as easy as possible?

sub PDL::make_assignable {
my $data = $_[0];
tie $_[0], 'PDL::Sentinel', $data;
}

my $third_try = grandom(10);
print "Third try is initially $third_try\n";
$third_try->make_assignable;
$third_try = 5;

# Works! Get [5 5 5 5 5 5 5 5 5 5]
print "Now, third try is $third_try\n";

---->%----

So it looks like we can create a PDL method that can be invoked on an
already existing scalar which turns the scalar into a tied scalar. A
typical usage scenario would be

my $data = get_pdl_data();
$data->make_assignable;
...
$data = some_new_values;
...

However, it will be far from perfect. For example, this won't work:

my $data = get_pdl_data()->make_assignable;

We could still modify the scalars that are returned from slice operations
so that "=" assignment works:

$data->slice("5:10") = 4;


So, overall, we would have this:

# can work if we return tied scalars
$data->slice("5:10") = 4;

# Won't work
$data = get_piddle();
$data = 4;

# Can work if we provide the method
$data = get_piddle();
$data->make_assignable;
$data = 4;

The failure of the middle scenario is what bugs me most of all.

Those are my thoughts for the moment. I just had an idea, though, and might
have a workaround for it. I'll post back with more in a bit.

David

Post by Chris Marshall
Neat! Is there a standard way to implement an '='
overload that does what we want for PDL? I.e., is
there some sort of flowchart for a "proper" implementation
(perhaps from another OO language)?
--Chris

Post by David Mertens
Hey everyone,
The Perl documentation on lvalue subs mentions Sentinel, a CPAN

distribution

Post by David Mertens
which provides a simple mechanism for controlling modification of an

lvalue

Post by David Mertens
by "=" assignment. This is the simplest module I have seen to date with

this

Post by David Mertens
behavior. It achieves this behavior by overriding the get and set magic
methods (and the free magic method, for cleanup of course) for the

scalar. I

Post by David Mertens
would bet that if we set the same magic methods in our core pdl creation
method(s), we could get "=" assignment to Just Work. (Side note: this

would

Post by David Mertens
work regardless of how we do lvalue handling.)
The only trick then would be to make sure that somebody could reuse the

same

Post by David Mertens
$variable_name to refer to completely different piddles, rather than
croaking on mismatched thread dimensions.
I have considered the silent, unintended failure of "=" to be a wart in

PDL.

Post by David Mertens
It should at least warn, in a way that I can control.
Thoughts?
David
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[David Mertens]

Nope, my other idea didn't work. That's the best I've got for now.

David

Post by David Mertens
Argh,
Having thought about this some more, I realized that my initial idea won't
work, not exactly. The thing is that the "get" magic for "=" is assigned to
the *scalar*, not the *scalar* *reference*. That is, if I have
then $data is the scalar, and it is a reference to the opaque PDL object.
We need change $data. Even if pdl() returns a scalar with get and set
magic, Perl will copy that scalar reference in the assignment to $data.
To test out this theory, I simply played a bit with basic tied scalars.
----%<----
use strict;
use warnings;
package PDL::Sentinel;
sub TIESCALAR {
return bless \$pdl, $class;
}
sub FETCH { return ${$_[0]} }
sub STORE {
$$self .= $new_data;
return $self;
}
package main;
### Basic usage with direct tie works
use PDL;
my $data = sequence(10);
my $nice;
tie $nice, 'PDL::Sentinel', $data;
$nice = 5;
# Prints [5 5 5 5 5 5 5 5 5 5]
print "data is $nice\n";
### Can I return a tie'd scalar?
sub return_assignable {
my $new_data = sequence(10);
my $to_return;
tie $to_return, 'PDL::Sentinel', $new_data;
return $to_return;
}
my $new_thing = return_assignable;
print "new thing was $new_thing\n";
$new_thing = 0;
# Nope: prints 0
print "Now, new thing is $new_thing\n";
### Can I make the process of tie'ing as easy as possible?
sub PDL::make_assignable {
my $data = $_[0];
tie $_[0], 'PDL::Sentinel', $data;
}
my $third_try = grandom(10);
print "Third try is initially $third_try\n";
$third_try->make_assignable;
$third_try = 5;
# Works! Get [5 5 5 5 5 5 5 5 5 5]
print "Now, third try is $third_try\n";
---->%----
So it looks like we can create a PDL method that can be invoked on an
already existing scalar which turns the scalar into a tied scalar. A
typical usage scenario would be
my $data = get_pdl_data();
$data->make_assignable;
...
$data = some_new_values;
...
my $data = get_pdl_data()->make_assignable;
We could still modify the scalars that are returned from slice operations
$data->slice("5:10") = 4;
# can work if we return tied scalars
$data->slice("5:10") = 4;
# Won't work
$data = get_piddle();
$data = 4;
# Can work if we provide the method
$data = get_piddle();
$data->make_assignable;
$data = 4;
The failure of the middle scenario is what bugs me most of all.
Those are my thoughts for the moment. I just had an idea, though, and
might have a workaround for it. I'll post back with more in a bit.
David

Post by Chris Marshall
Neat! Is there a standard way to implement an '='
overload that does what we want for PDL? I.e., is
there some sort of flowchart for a "proper" implementation
(perhaps from another OO language)?
--Chris

Post by David Mertens
Hey everyone,
The Perl documentation on lvalue subs mentions Sentinel, a CPAN

distribution

Post by David Mertens
which provides a simple mechanism for controlling modification of an

lvalue

Post by David Mertens
by "=" assignment. This is the simplest module I have seen to date with

this

Post by David Mertens
behavior. It achieves this behavior by overriding the get and set magic
methods (and the free magic method, for cleanup of course) for the

scalar. I

Post by David Mertens
would bet that if we set the same magic methods in our core pdl creation
method(s), we could get "=" assignment to Just Work. (Side note: this

would

Post by David Mertens
work regardless of how we do lvalue handling.)
The only trick then would be to make sure that somebody could reuse the

same

Post by David Mertens
$variable_name to refer to completely different piddles, rather than
croaking on mismatched thread dimensions.
I have considered the silent, unintended failure of "=" to be a wart in

PDL.

Post by David Mertens
It should at least warn, in a way that I can control.
Thoughts?
David
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

[Chris Marshall]

On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)

--Chris

[David Mertens]

Although we can't universally override "=" assignment, it does let us catch
the most annoying bug. Since lvalue subs control the actual scalar that
they return, we could do something helpful when the user does this:

$data->slice_function = $something_else;

We could certainly warn or croak on this, which would be a win by all
accounts, I suspect. We could even make the warning something the user
could turn off, i.e. make it possible to do elementwise assignment for
slices like this if the user opts-in.

User-level functions that compute some complicated slice and return that
would have to be specially crafted to get the same behavior, but that could
easily be documented.

Alright, I've almost convinced myself to implement this. :-)

David

Post by Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris

[Ingo Schmid]

Hi,

just saying I'd love to see that improvement. The following, at least to
me, is completely unintuitive and awkward, but I haven't found a better
solution.

(my $nix=sln($a,x=>0,y=>1)).=33;

ln($a,x=>0,y=>1).=33; # does not work!

sln is a function that returns a slice, not a slice string.

Ingo

Post by David Mertens
Although we can't universally override "=" assignment, it does let us
catch the most annoying bug. Since lvalue subs control the actual
scalar that they return, we could do something helpful when the user
$data->slice_function = $something_else;
We could certainly warn or croak on this, which would be a win by all
accounts, I suspect. We could even make the warning something the user
could turn off, i.e. make it possible to do elementwise assignment for
slices like this if the user opts-in.
User-level functions that compute some complicated slice and return
that would have to be specially crafted to get the same behavior, but
that could easily be documented.
Alright, I've almost convinced myself to implement this. :-)
David
On Sat, Oct 4, 2014 at 10:51 AM, Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Chris Marshall]

Is sln an lvalue sub?

Hi,
just saying I'd love to see that improvement. The following, at least to me,
is completely unintuitive and awkward, but I haven't found a better
solution.
(my $nix=sln($a,x=>0,y=>1)).=33;
ln($a,x=>0,y=>1).=33; # does not work!
sln is a function that returns a slice, not a slice string.
Ingo
Although we can't universally override "=" assignment, it does let us catch
the most annoying bug. Since lvalue subs control the actual scalar that they
$data->slice_function = $something_else;
We could certainly warn or croak on this, which would be a win by all
accounts, I suspect. We could even make the warning something the user could
turn off, i.e. make it possible to do elementwise assignment for slices like
this if the user opts-in.
User-level functions that compute some complicated slice and return that
would have to be specially crafted to get the same behavior, but that could
easily be documented.
Alright, I've almost convinced myself to implement this. :-)
David

Post by Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[David Mertens]

No. It *could* be, if it were implemented with full dataflow support... but
I'm really shaky on just how that would be implemented. The implementation
of rotate() might provide a means for turning sin into a dataflow method.

It seems slightly off topic to me. :-)

David

Post by Chris Marshall
Is sln an lvalue sub?

Post by Ingo Schmid
Hi,
just saying I'd love to see that improvement. The following, at least to

me,

Post by Ingo Schmid
is completely unintuitive and awkward, but I haven't found a better
solution.
(my $nix=sln($a,x=>0,y=>1)).=33;
ln($a,x=>0,y=>1).=33; # does not work!
sln is a function that returns a slice, not a slice string.
Ingo
Although we can't universally override "=" assignment, it does let us

catch

Post by Ingo Schmid
the most annoying bug. Since lvalue subs control the actual scalar that

they

Post by Ingo Schmid
$data->slice_function = $something_else;
We could certainly warn or croak on this, which would be a win by all
accounts, I suspect. We could even make the warning something the user

could

Post by Ingo Schmid
turn off, i.e. make it possible to do elementwise assignment for slices

like

Post by Ingo Schmid
this if the user opts-in.
User-level functions that compute some complicated slice and return that
would have to be specially crafted to get the same behavior, but that

could

Post by Ingo Schmid
easily be documented.
Alright, I've almost convinced myself to implement this. :-)
David

Post by Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

[Ingo Schmid]

David,

it's sln, not sin (SLicining by Name), just a function/method which
returns a slice based on arguments, and it's not an lvalue function.
Sorry if I confused you, my point was just a thanks for looking into the
whole matter.
Ingo

Post by David Mertens
No. It *could* be, if it were implemented with full dataflow
support... but I'm really shaky on just how that would be implemented.
The implementation of rotate() might provide a means for turning sin
into a dataflow method.
It seems slightly off topic to me. :-)
David
Is sln an lvalue sub?

Post by Ingo Schmid
Hi,
just saying I'd love to see that improvement. The following, at

least to me,

Post by Ingo Schmid
is completely unintuitive and awkward, but I haven't found a better
solution.
(my $nix=sln($a,x=>0,y=>1)).=33;
ln($a,x=>0,y=>1).=33; # does not work!
sln is a function that returns a slice, not a slice string.
Ingo
Although we can't universally override "=" assignment, it does

let us catch

Post by Ingo Schmid
the most annoying bug. Since lvalue subs control the actual

scalar that they

Post by Ingo Schmid
$data->slice_function = $something_else;
We could certainly warn or croak on this, which would be a win

by all

Post by Ingo Schmid
accounts, I suspect. We could even make the warning something

the user could

Post by Ingo Schmid
turn off, i.e. make it possible to do elementwise assignment for

slices like

Post by Ingo Schmid
this if the user opts-in.
User-level functions that compute some complicated slice and

return that

Post by Ingo Schmid
would have to be specially crafted to get the same behavior, but

that could

Post by Ingo Schmid
easily be documented.
Alright, I've almost convinced myself to implement this. :-)
David
On Sat, Oct 4, 2014 at 10:51 AM, Chris Marshall

Post by Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

[David Mertens]

Oh, oops. Sorry for misreading. To echo what Chris was saying, you should
be able to get sln() to work the way you want be declaring it an :lvalue
sub. Do you have it available somewhere so I could poke around with it?

David

Post by Ingo Schmid
David,
it's sln, not sin (SLicining by Name), just a function/method which
returns a slice based on arguments, and it's not an lvalue function.
Sorry if I confused you, my point was just a thanks for looking into the
whole matter.
Ingo
No. It *could* be, if it were implemented with full dataflow support...
but I'm really shaky on just how that would be implemented. The
implementation of rotate() might provide a means for turning sin into a
dataflow method.
It seems slightly off topic to me. :-)
David

Post by Chris Marshall
Is sln an lvalue sub?

Post by Ingo Schmid
Hi,
just saying I'd love to see that improvement. The following, at least

to me,

Post by Ingo Schmid
is completely unintuitive and awkward, but I haven't found a better
solution.
(my $nix=sln($a,x=>0,y=>1)).=33;
ln($a,x=>0,y=>1).=33; # does not work!
sln is a function that returns a slice, not a slice string.
Ingo
Although we can't universally override "=" assignment, it does let us

catch

Post by Ingo Schmid
the most annoying bug. Since lvalue subs control the actual scalar that

they

Post by Ingo Schmid
$data->slice_function = $something_else;
We could certainly warn or croak on this, which would be a win by all
accounts, I suspect. We could even make the warning something the user

could

Post by Ingo Schmid
turn off, i.e. make it possible to do elementwise assignment for slices

like

Post by Ingo Schmid
this if the user opts-in.
User-level functions that compute some complicated slice and return that
would have to be specially crafted to get the same behavior, but that

could

Post by Ingo Schmid
easily be documented.
Alright, I've almost convinced myself to implement this. :-)
David

Post by Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

[David Mertens]

Found it here:
http://search.cpan.org/~fantasma/PDL-Dims-0.004/lib/PDL/Dims.pm

Ingo, if you declare sln as :lvalue, and simply end the function with $ret
rather than returning it, then your function should be assignable with .=

And, when I implement warnings and "=" assignment for lvalue slices, I'll
be sure to document how you would turn your lvalue into something that does
the same sort of behavior.

@Chris, for this work, should I create a fork based on the master?

David

P. S. Sourceforge finally has easy forking as well as merge requests!
Awesome!

Post by David Mertens
Oh, oops. Sorry for misreading. To echo what Chris was saying, you should
be able to get sln() to work the way you want be declaring it an :lvalue
sub. Do you have it available somewhere so I could poke around with it?
David

Post by Ingo Schmid
David,
it's sln, not sin (SLicining by Name), just a function/method which
returns a slice based on arguments, and it's not an lvalue function.
Sorry if I confused you, my point was just a thanks for looking into the
whole matter.
Ingo
No. It *could* be, if it were implemented with full dataflow support...
but I'm really shaky on just how that would be implemented. The
implementation of rotate() might provide a means for turning sin into a
dataflow method.
It seems slightly off topic to me. :-)
David

Post by Chris Marshall
Is sln an lvalue sub?

Post by Ingo Schmid
Hi,
just saying I'd love to see that improvement. The following, at least

to me,

Post by Ingo Schmid
is completely unintuitive and awkward, but I haven't found a better
solution.
(my $nix=sln($a,x=>0,y=>1)).=33;
ln($a,x=>0,y=>1).=33; # does not work!
sln is a function that returns a slice, not a slice string.
Ingo
Although we can't universally override "=" assignment, it does let us

catch

Post by Ingo Schmid
the most annoying bug. Since lvalue subs control the actual scalar

that they

Post by Ingo Schmid
$data->slice_function = $something_else;
We could certainly warn or croak on this, which would be a win by all
accounts, I suspect. We could even make the warning something the user

could

Post by Ingo Schmid
turn off, i.e. make it possible to do elementwise assignment for

slices like

Post by Ingo Schmid
this if the user opts-in.
User-level functions that compute some complicated slice and return

that

Post by Ingo Schmid
would have to be specially crafted to get the same behavior, but that

could

Post by Ingo Schmid
easily be documented.
Alright, I've almost convinced myself to implement this. :-)
David
On Sat, Oct 4, 2014 at 10:51 AM, Chris Marshall <

Post by Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

[Ingo Schmid]

David,
cool, and a classic of read the docs! ;) It's all there after typing
help lvalue!

Sorry for not doing that.
Ingo

Post by David Mertens
Found it
here: http://search.cpan.org/~fantasma/PDL-Dims-0.004/lib/PDL/Dims.pm
<http://search.cpan.org/%7Efantasma/PDL-Dims-0.004/lib/PDL/Dims.pm>
Ingo, if you declare sln as :lvalue, and simply end the function with
$ret rather than returning it, then your function should be assignable
with .=
And, when I implement warnings and "=" assignment for lvalue slices,
I'll be sure to document how you would turn your lvalue into something
that does the same sort of behavior.
@Chris, for this work, should I create a fork based on the master?
David
P. S. Sourceforge finally has easy forking as well as merge requests!
Awesome!
On Thu, Oct 9, 2014 at 7:32 AM, David Mertens
Oh, oops. Sorry for misreading. To echo what Chris was saying, you
should be able to get sln() to work the way you want be declaring
it an :lvalue sub. Do you have it available somewhere so I could
poke around with it?
David
David,
it's sln, not sin (SLicining by Name), just a function/method
which returns a slice based on arguments, and it's not an
lvalue function.
Sorry if I confused you, my point was just a thanks for
looking into the whole matter.
Ingo

Post by David Mertens
No. It *could* be, if it were implemented with full dataflow
support... but I'm really shaky on just how that would be
implemented. The implementation of rotate() might provide a
means for turning sin into a dataflow method.
It seems slightly off topic to me. :-)
David
On Wed, Oct 8, 2014 at 8:41 PM, Chris Marshall
Is sln an lvalue sub?
On Wed, Oct 8, 2014 at 1:36 PM, Ingo Schmid

Post by Ingo Schmid
Hi,
just saying I'd love to see that improvement. The

following, at least to me,

Post by Ingo Schmid
is completely unintuitive and awkward, but I haven't

found a better

Post by Ingo Schmid
solution.
(my $nix=sln($a,x=>0,y=>1)).=33;
ln($a,x=>0,y=>1).=33; # does not work!
sln is a function that returns a slice, not a slice string.
Ingo
Although we can't universally override "=" assignment,

it does let us catch

Post by Ingo Schmid
the most annoying bug. Since lvalue subs control the

actual scalar that they

Post by Ingo Schmid
return, we could do something helpful when the user
$data->slice_function = $something_else;
We could certainly warn or croak on this, which would

be a win by all

Post by Ingo Schmid
accounts, I suspect. We could even make the warning

something the user could

Post by Ingo Schmid
turn off, i.e. make it possible to do elementwise

assignment for slices like

Post by Ingo Schmid
this if the user opts-in.
User-level functions that compute some complicated

slice and return that

Post by Ingo Schmid
would have to be specially crafted to get the same

behavior, but that could

Post by Ingo Schmid
easily be documented.
Alright, I've almost convinced myself to implement

this. :-)

Post by Ingo Schmid
David
On Sat, Oct 4, 2014 at 10:51 AM, Chris Marshall

Post by Chris Marshall
On the other hand, .= for element-wise assignment
may be mnemonic for matlab users. :-)
--Chris

--
"Debugging is twice as hard as writing the code in the

first place.

Post by Ingo Schmid
Therefore, if you write the code as cleverly as

possible, you are,

Post by Ingo Schmid
by definition, not smart enough to debug it." --

Brian Kernighan

Post by Ingo Schmid
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters

_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan