BrowserUk has recently written this article which brought to my knowledge the most interesting thing I've read since I'm at the Monastery. That is, that you can keep (multiple) lvalue refs of substr return values and manipulate them.

Just to be sure, I tried 

$ perl -le 'print ref \substr "foo", 1'
LVALUE

[download]
and so... wow! it seems that we really have a LVALUE datatype. Now, that's cool; OTOH we have lvalue-able subs, but what about them? 
$ perl -le 'my $u; sub u :lvalue {$u} print ref \u'
SCALAR

[download]
Huh, no, it's just a plain old SCALAR. Which raises this meditation: lvalue subs can be cool, but can I imitate substr's action at distance behaviour to do something potentially more interesting? Well, it turns out that I can: 
#!/usr/bin/perl -l

use strict;
use warnings;

package Append;

sub TIESCALAR { bless \$_[1], $_[0] }
sub FETCH { ${${ $_[0] }} }
sub STORE { ${${ $_[0] }} .= $_[1] }

package main;

sub append :lvalue {
    tie my $v, 'Append', \$_[0];
    $v;
}

my $u='Foo';
(append $u)='Bar';
print $u;

__END__

[download]
Incidentally, if I substitute 
(append $u)='Bar';
print $u;

[download]
with 
print +(append 'Foo')='Bar';

[download]
it still works, whereas I would have expected it to raise an error about an attempt to modify a read-only value. Why doesn't it?
Whatever, this is at best tricky. And this is an oversimpliflied example. It could get too complex in a more serious attempt.

So getting back to the lvref topic hinted to at the beginning of this post, the matter is: the above could be doable in an easier way if

  1. lvalue subs were so as to return a blessed reference into the LVALUE package,
  2. this package provided a, say, STORE method to override standard assignment,
so that the above may be simply: 
sub append :lvalue {
    local *LVALUE::STORE = sub {
        my $self=shift;
        $$self .= $_[0];
    }
    $_[0];
}

[download]
What about this idea? (Or some variation thereof!)

Replies are listed 'Best First'.
Re: lvalues and action at distance
by BrowserUk (Patriarch) on Oct 11, 2005 at 18:59 UTC

    Sorry to be a damp squib, but please be very careful what you try to use lvalue refs for.

    They have one or two uses for which they're indispensible, mostly to do with large volumes of fixed record length, usually binary data.

    There are other uses, but they can easily start to produce confusing results if you make small mistakes, and that is when you know what you have, and are dealing with. I think blessing them and passing them to others to manipulate is not a good idea.

    One of the problems is that they will allow you to replace a substring with either more or less characters than it originally held (just as substr will), but once you have done this, working out what substring the lvref now points to is confusing and will rarely be what you will expect. This is going to get better at some point in the future.

    However, if you have two or more lvref pointing to the same string, and one is used to alter the length of overall string, then the substring addressed by the other may or may not change, sometimes in quite radical and confusing ways, depending upon the relationship between the original two. This is not going to change.

    Best saved for very localised use, for very specific purposes I think.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
      They have one or two uses for which they're indispensible, mostly to do with large volumes of fixed record length, usually binary data.

      They have one or two uses for which they're indispensible, mostly to do with large volumes of fixed record length, usually binary data.

      Thank you for the "caveat".

      Indeed I was thinking of this kind of (what I'd call) "addomesticated" action at distance more in terms of a syntactically and semantically cool possibility to yield yet more WTDI: I was and I am intrigued by the concept and the idea; I was not talking of an actual "need".

      All in all I realise that my own example may have conveyed the impression that my primary interest was focused on dealing with strings, but that is not the case. It's focused on the implications of (extending) the semantics of "lvalues as something into which you can inject something else to perform some kind of reasonably addomesticated action at distance". (At your own risk and peril, but if you're messing with this kinda stuff, then you're supposed to know what you're doing...)

[reply]
Re: lvalues and action at distance
by japhy (Canon) on Oct 11, 2005 at 14:40 UTC
    Too much work. You can do this without tying: 
    sub append :lvalue {
  no warnings 'uninitialized';
  substr($_[0], length $_[0]);
}

my $x;
for (1 .. 5) { append($x) = $_ }
print $x;

    [download]
    Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
    How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart
[reply]
[d/l]
      Well, but that still uses substr's magic. I took appending to a string as an example, but it was meant to illustrate a more general issue...
[reply]
Re: lvalues and action at distance
by ysth (Canon) on Oct 11, 2005 at 18:44 UTC
    Incidentally, if I substitute 
    (append $u)='Bar';
print $u;

    [download]
    with 
    print +(append 'Foo')='Bar';

    [download]
    it still works, whereas I would have expected it to raise an error about an attempt to modify a read-only value. Why doesn't it?
    When you take a reference to a passed constant (e.g. \$_[0]), perl silently copies the constant and makes a reference to the copy instead, starting with 5.8.4/5.9.1. It's not clear to me that this was an intentional change. Simple test case: 
    perl -we'sub { print \$_[0]==\${\$_[0]}&&"no ","copy $]" }->("Bar")'

    [download]
    The copy takes place in the SvPADTMP case in pp.c:S_refto.

    Update: I may be wrong about the versions; it is making a copy on all the threaded perls I have and not making a copy on unthreaded perls.

[reply]
[d/l]
[select]
Re: lvalues and action at distance
by perrin (Chancellor) on Oct 11, 2005 at 17:57 UTC
    Usually when people mention action-at-a-distance, it's because they are trying to avoid it. It's generally seen as something that leads to confusing code that is hard to debug. What are you hoping to do with it?
[reply]
      You are right about the nature of action-at-a-distance as something that one generally wants to avoid. I was thinking of "addomesticated" action at distance, the rationale being that if one wants to mess with such stuff he is supposed to know what that he/she is doing. Since it wouldn't be sensible to repeat too much, you can find more details in my reply to BrowserUk's one.
[reply]
Re: lvalues and action at distance
by sauoq (Abbot) on Oct 12, 2005 at 02:59 UTC

    Just by the way...

    Now, that's cool; OTOH we have lvalue-able subs, but what about them? 
    $ perl -le 'my $u; sub u :lvalue {$u} print ref \u'
SCALAR

    [download]
    Huh, no, it's just a plain old SCALAR.

    You didn't print a reference to the lvalue sub u(). If you had, you would have gotten CODE. 

    $ perl -le 'my $u; sub u :lvalue {$u} print ref \&u'
CODE

    [download]
    You printed a reference to the return value of a call to u(). That's the same thing as a reference to $u itself.

    $ perl -le 'my $u; sub u :lvalue {$u} print ref \u; print \u; print \$
+u'
SCALAR
SCALAR(0x812dd80)
SCALAR(0x812dd80)

    [download]

    Update: On second reading, I guess maybe I missed your point. Nevermind me. Move along.

    -sauoq
"My two cents aren't worth a dime.";
[reply]
[d/l]
[select]

Back to Meditations