develooper Front page | perl.perl5.porters | Postings from July 2011

Re: Why views are useful, and why their syntax doesn't matter much

Thread Previous | Thread Next
Father Chrysostomos
July 10, 2011 17:15
Re: Why views are useful, and why their syntax doesn't matter much
Message ID:

On Jul 10, 2011, at 1:41 PM, Reverend Chip wrote:

> On 7/10/2011 12:14 PM, Father Chrysostomos wrote:
>> Chip Salzenberg wrote:
>>> What views offer are the ability to add semantics - filters - to the
>>> aliasing.  The only current use case, perhaps the only ever, is adding
>>> read-only-ness.  So after something like
>>>   view const $v, $original;
>>> or whatever the syntax might be, then:
>>>   \$v == \$original         # true
>>>   $original=1; print $v     # "1"
>>>   $v=1                      # throws exception
>> I don’t really see the point of this feature, but don’t let that deter you. (On the other hand, I thought the same thing about smart match and consequently ignored it, so maybe that’s a red flag; then again, maybe not.)
> Intuition counts, but needs balance.
> The point of this feature is specifically so that   method foo ($a)
> {...}   can have $a not be a copy (this is for speed), but also prevent
> accidentally modifying the original (this is for safety).  It's
> "read-only aliasing", the default mode of parameter passing in Perl 6. 
> Shirley having to choose between slow names and fast and unsafe @_ is a
> situation that needs fixing.
> Does that help?

It just made me think more and come up with other observations:

I thought the whole point of function signatures was to avoid having to write:

sub foo {
  for my $x (shift) {
    for my $y (shift) {
      for my $z (shift) {

If you make them read-only it defeats the purpose of having an alias.

If you want something more efficient than copying, we have copy-on-write for strings. Can we make perl use that more often? And isn’t copying an RV or a number just as fast as making a view?

I can’t speak for Perl 6, but making something read-only in Perl 5 just feels un-Perl-5-ish. After all, we allow $^X assignment.

And if someone *really* wants them read-only, a copy can be made so.

>> In any case, do views work with the no-common-vars optimisation?
>> I.e., what will be assigned to $something_else in this case? Not 3, I hope.
>> $original = 7;
>> ($original,$something_else) = (3,$v);
>> This is already a problem for aliased package vars...
> The no-common-vars optimization works strictly by name?  Feh.  Perhaps
> you're right about the pragma, or perhaps we can just have users use do

I meant not a pragma in the sense of ‘use whatever’, but for the hint to be turned on automatically. But that won’t help if a reference to a bound scalar is returned to a scope without that hint. However, now we have a use for ‘use less "buginess"’.

> BLOCK as a workaround since it makes temp copies that can have their
> contents stolen, reducing the waste:
>    ($original,$something_else) = do { 3,$v };

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About