FAQ
# New Ticket Created by Father Chrysostomos
# Please include the string: [perl #128242]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=128242 >


In ticket #127531, Ricardo Signes proposed allowing

     sub foo ($x, \@y, \%z) { ... }

where the \ would result in aliasing.

Since the use of backslashes in signatures is orthogonal to \ after a declarator (there ain’t no declarator in the sub signature), I’m opening a separate ticket.

--

Father Chrysostomos

Search Discussions

  • Father Chrysostomos via RT at May 26, 2016 at 5:27 am

    On Wed May 25 22:16:11 2016, sprout wrote:
    In ticket #127531, Ricardo Signes proposed allowing

    sub foo ($x, \@y, \%z) { ... }

    where the \ would result in aliasing.
    I want to point out that this syntax does not allow any easy way to make ($foo,$bar,$baz) into aliases of @_’s elements. Currently to do that outside of a signature, you can do:

         \my($foo,$bar,$baz) = \(@_);
         # and on the sprout/mywack branch:
         my(\$foo,\$bar,\$baz) = \(@_);

    Notice that either way we have to put a backslash on the rhs. The signature syntax doesn’t give us any room to specify whether the rhs should get a \.

    I notice that in your (Ricardo’s) proposal you did not put a backslash before a scalar. :-)

    We *could* avoid the whole issue by only allowing \@ and \% for now. I don’t like that idea.

    If we are going to do any aliasing at all, we should handle scalars at the outset. And that means deciding

    a) whether \$foo implies a \ on the corresponding @_ element (though an exception for scalars makes the model disjointed) (or perhaps \$foo=\ but that conflicts with default values),

    b) how default values will work (\$foo=3 or \$foo=\3)

    c) whether we need something completely different from a backslash, in which case we might as well use that other notation for arrays and hashes as well.

    Maybe we do (gulp) need to adopt the Perl 6 := thingy, but only in signatures.

    --

    Father Chrysostomos


    ---
    via perlbug: queue: perl5 status: new
    https://rt.perl.org/Ticket/Display.html?id=128242
  • Ricardo Signes at May 26, 2016 at 1:33 pm
    * Father Chrysostomos via RT [2016-05-26T01:27:01]
    I want to point out that this syntax does not allow any easy way to make
    ($foo,$bar,$baz) into aliases of @_’s elements. Currently to do that outside
    of a signature, you can do:
    [...]
    Notice that either way we have to put a backslash on the rhs. The signature
    syntax doesn’t give us any room to specify whether the rhs should get a \.

    I notice that in your (Ricardo’s) proposal you did not put a backslash before
    a scalar. :-)
    Yes, thanks, all good points. I had one specific use case in mind: avoiding
    dereferencing syntax by using aliases instead. In my original original
    example (maybe only in my head), the first arg was actually $self, so I
    definitely didn't want to dereference it.

    You make the point that there is, of course, a *huge* other use case: aliasing
    for the sake of aliasing.

    I'm not sure how to synthesize these two features into something unified. Say
    we add 'by ref':

       sub reticulate ($x by ref, \%arg) { ... }

       my $opts = { bar => 1 };
       reticulate($foo, $opts);

    Now our $x is an alias to $foo, and %arg is a dereference-free way to access
    the hash referenced by $opts.

    I'm not sold, though. If we want to have an alias to $opts itself, we'd write,
    instead:

       sub reticulate ($x by ref, $arg by ref) { ... }

    But these are two orthogonal pieces of syntax, which makes me wonder what the
    heck this means:

       sub reticulate ($x by ref, \%arg by ref) { ... }

    Presumably:

       my \%arg = \$_[1];

    In other words, backwhacking the variable name does just what it would do in
    assignment. "is ref" takes a reference to the element passed in first.

    This should be illegal: sub xyz (%arg by ref) { ... }

    This seems like it will usually be a mistake: sub xyz (@arr by ref) { ... }

    I'm not sure about all this, it's just what came to mind so far.

    --
    rjbs
  • Zefram at May 26, 2016 at 3:07 pm

    Ricardo Signes wrote:
    I'm not sure how to synthesize these two features into something unified. Say
    we add 'by ref':
    I'm not a fan of this syntax. My favourite option atm is some punctuation
    postfixed to the parameter name, alluding to modifying the notional
    assignment operator. For example, ($x:), to suggest that we're doing
    a "my $x := $_[0]" in place of the "my $x = $_[0]" yielded by ($x).
    Maybe the postfix should be a backslash rather than colon. Maybe we
    should actually introduce an aliasing ":=" or "\=" operator.
    But these are two orthogonal pieces of syntax, which makes me wonder what the
    heck this means:

    sub reticulate ($x by ref, \%arg by ref) { ... }

    Presumably:

    my \%arg = \$_[1];
    No. ($arg by ref) means

      my \$arg = \$_[1];

    so adding a backslash to get (\%arg by ref) ought to mean

      my \\%arg = \$_[1];

    which is an error. So (\%arg by ref) should be an error. If it were
    not an error, the only thing it could mean is

      my \%arg = $_[1];

    (obtained by stripping one backslash from each side of the assignment),
    which is the same thing that (\%arg) means.
    This should be illegal: sub xyz (%arg by ref) { ... }

    This seems like it will usually be a mistake: sub xyz (@arr by ref) { ... }
    Hmm. If you interpret these as aliasing a single array/hash, then
    they're both necessarily illegal. Aliasing @_ would not be a sensible
    interpretation for the latter, because the semantics of the signature
    don't inherently refer to @_. They refer to *the argument list*, which
    doesn't have to be reified as an array.

    But if you interpret these as aliasing the elements within the array/hash,
    then both are meaningful and can reasonably be legal. (Obviously the hash
    keys can't be aliased, but the values can be.) If we want to support
    this, the implied list-aliasing behaviour would provide some motivation
    to actually introduce the aliasing operator that I suggested above.
    I'm ambivalent about this. I suppose it'll be useful in a handful of
    cases, but I don't think it's an important feature. It's certainly not
    a priority for signature support.

    -zefram
  • Jim Cromie at May 26, 2016 at 6:03 pm

    But if you interpret these as aliasing the elements within the array/hash,
    then both are meaningful and can reasonably be legal. (Obviously the hash
    keys can't be aliased, but the values can be.) If we want to support
    this, the implied list-aliasing behaviour would provide some motivation
    to actually introduce the aliasing operator that I suggested above.
    I'm ambivalent about this. I suppose it'll be useful in a handful of
    cases, but I don't think it's an important feature. It's certainly not
    a priority for signature support.

    -zefram

    this is also consistent with \($x, $y, $z) being same as (\$x, \$y, \$z)
  • Father Chrysostomos via RT at May 26, 2016 at 7:45 pm

    On Thu May 26 08:07:50 2016, zefram@fysh.org wrote:
    Ricardo Signes wrote:
    This should be illegal: sub xyz (%arg by ref) { ... }

    This seems like it will usually be a mistake: sub xyz (@arr by ref) {
    ... }
    ...
    But if you interpret these as aliasing the elements within the
    array/hash,
    then both are meaningful and can reasonably be legal. (Obviously the
    hash
    keys can't be aliased, but the values can be.)
    I just want to note that \(%hash) = ... is illegal, because the keys cannot be aliased.

    --

    Father Chrysostomos


    ---
    via perlbug: queue: perl5 status: open
    https://rt.perl.org/Ticket/Display.html?id=128242
  • Zefram at May 26, 2016 at 2:46 pm

    Father Chrysostomos via RT wrote:
    a) whether \$foo implies a \ on the corresponding @_ element
    It should not. \$foo should work analogously to \@foo, and for
    consistency with other backslash syntax both of these should alias to
    the thing referenced by the @_ element. Some other signifier should be
    used for aliasing to the @_ element itself.
    b) how default values will work (\$foo=3 or \$foo=\3)
    Logically, the thing on the rhs of the "=" should be the default value to
    use in place of the @_ element, which with the backslash on the lhs must
    be a reference to a thing to alias. So (\@foo = [qw(a b c)]) yielding
    $foo[0] eq "a", for example.

    When aliasing the @_ element itself, the novel signifier for that should
    go on the lhs, and the rhs should still be the default value to use
    in place of the @_ element. So in that case the rhs must be an lvalue
    expression, and the lvalue will be aliased.
    c) whether we need something completely different from a backslash,
    in which case we might as well use that other notation for arrays and
    hashes as well.
    The backslash should be preferred for aliasing to the thing referenced
    by an @_ element, for its inherent logic and for consistency with ref
    alias assignment. Something different is required for aliasing an @_
    element itself.

    -zefram
  • Aristotle Pagaltzis at May 26, 2016 at 8:04 pm

    * Zefram [2016-05-26 19:51]:
    […]
    Thanks for saving me the work of writing the same analysis. :-)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMay 26, '16 at 5:16a
activeMay 26, '16 at 8:04p
posts8
users5
websiteperl.org

People

Translate

site design / logo © 2018 Grokbase