in reply to Re^5: Unifying namespaces of @name and $name to simplify dereferencing? (declaration of typed references)
in thread Unifying namespaces of @name and $name to simplify dereferencing?

> That's not possible, because this means that \@a would not have a constant value for the duration of the program. 

With a tied array it should be feasable to always access @$ref. ( well quite slow but good enough for a showcase.)

> And you can't magic your way out of it 

These variables are scoped and easy to identify (at least lexicals) you can just replace every @arr with @$are at compile time or in a macro substitution.

>  because sometimes only the stringified ref is kept (as the key of a hash).

I doubt that's documented or guaranteed behavior.

At least with stash variables you are free to change the reference by aliasing.

Just try *a=\@b; and see what \@a returns. :)

Cheers Rolf
(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!

update

furthermore this allows changing the underlying reference.

use 5.22.0;
use feature qw/say refaliasing/;
no warnings "experimental::refaliasing";

my @a=(1,2,3);
my @b=(3,2,1);

say \@a;

\@a=\@b;

say \@a;

[download]
  • Comment on Re^6: Unifying namespaces of @name and $name to simplify dereferencing? (declaration of typed references)
  • Select or Download Code

Replies are listed 'Best First'.
Re^7: Unifying namespaces of @name and $name to simplify dereferencing? (declaration of typed references)
by Eily (Monsignor) on Mar 28, 2016 at 12:17 UTC

    I doubt that's documented or guaranteed behavior.
    It's present in the Inside Out objects documentation at least. And the perlref doc states
    Using a reference as a string produces [...] the numeric address expressed in hex.
    Which is used to see if the two references refer to the same location. There's nothing that explictly states that a lexical variable will have a constant address for the duration of its scope though. And I didn't know that this was already broken by the experimental refaliasing, because I would expect that CPAN modules use constructs like process(@a) unless $processed{\@a}; which would break if the address is not constant. At least refaliasing makes it explicit that you are "overwriting the reference", because \@a=\@b; is not valid in "classic perl", so you're either going to guess what it does, or think it's a syntax error. Same goes with your declaration proposition. The declaration syntax wouldn't just be about type security, but rather about new features being a syntax error if used outside their scope.

    I didn't mention globs because while they make it easy to have an array always be the thing a references refers to, they can't be used with lexicals alone. Once again though, this was for lack of knowledge that aliasing is possible between lexicals. I now know that your proposition can be implemented (or at least emulated) using existing features.

    I still like $array being read-only better though, because it would make it possible to have a reference bound to your array for ease of use, without the side effects, or even misleading perl newcomers into believing that $array = [1..3]; overwrites the values of the array instead of creating a brand new one.

    Edit: tr/$/&/ in html escape :)

[reply]
[d/l]
[select]

In Section Meditations