in reply to Unifying namespaces of @name and $name to simplify dereferencing?

In perl4 you needed sigils on &subs, I think nobody is pining for that feature. I'd welcome the trend to continue to lexicals as well (let's call it perl7 ;-). Lexicals are good. More scoping means better structured code, opportunities for high-level optimizations. Simple variables need no symbolic bindings: compiler could optimize their allocation, etc.

Already there are experimental features: my $foo = sub vs my sub foo. That doesn't quite complete the circle since there's no implicit dereference ($foo() as $foo->()). But what if lexical subs were just sigil-less constant references? Naturally, subs in global scope ought to default to lexicals, unless marked as our.

References tend to encourage good practices (structured data, passing refs vs lists in/out of subs), and they can be easier to understand (array flattening). As it stands, mixing arrays and lists come with many nasty pitfalls. E.g. differences in slicing. E.g. an array-returning routine has a special case: 

sub foo {
#   return @_ ? @_ : @{[7, 76543]};
   return @_ ? @_ : (7, 76543);
}

say "as a list: ", join " ", foo(1, 2, 3);
say "as int: ", int foo(1, 2, 3);

say "as a list: ", join " ", foo();
say "as int: ", int foo();

[download]

I've been thinking the bare lexicals could be reference-anything variables, whereas sigils would place constraints. Sigils might also serve as prototypes in sub declaration. Ah yes, but this is starting to look like reinventing perl... 

my foo = either scalar or reference;

foo[] foo() foo{} foo[](){}[];     # implicit -> and autovivify

[download]
Where subs autovivify means autoloading or weak binding (to core library).

Anyway. Thank you for your thoughts.

Replies are listed 'Best First'.
Re^2: Unifying namespaces of @name and $name... (bare lexicals)
by LanX (Saint) on Mar 25, 2016 at 20:57 UTC
    BTW: there is a subtle difference between @arr=(1,2,3) and $arr=[1,2,3] , the first is reusing the allocated space (eventually expanding) to store the list , the latter assigning a ref to a newly allocated memory location.

    One needs both!

    In a language without sigils you have to invent list mechanisms to implement this.

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

[reply]
[d/l]
[select]
Re^2: Unifying namespaces of @name and $name... (bare lexicals)
by LanX (Saint) on Mar 25, 2016 at 18:23 UTC
    Hello Oiskuu,

    Thanks for meditating! =)

    I like the idea of sigil less variables, but I doubt this is feasible in Perl, cause there are too many cases where context matters, so you can't avoid @ and % to denote it...

    ... like in %settings = (%defaults, %arguments)

    Perl without sigils would be a kind of JavaScript (which isn't bad, just very reduced)

    I always thought of sigils as a way to spare me of Hungarian notation, in order to understand which type a variable has.

    Also sigils help avoiding namespace collisions with builtins, like in $length .

    > As it stands, mixing arrays and lists come with many nasty pitfalls.

    That's why I was meditating about a very simple change, to implicitly replace any my @arr; with my @arr;my $arr = \@arr; .

    This could be implemented easily (e.g. macro mechanism) and the effects are obvious.

    Though I was naive with the vice versa part, because my $var could be any datatype, so aliasing my @var to @$var wouldn't be obvious.

    And one of the most important use cases is passing data structures around, so my $arr = shift would cause a dangerous ambiguity when forcing an automatic alias.

    Though an extended syntax like sub foo { my $arr[] = shift; ... } (or my \@arr = shift ) might solve this and implicitly alias @arr (or $arr respectively).

    UPDATE

    I'm just realizing that something like my $arr[] = shift has an extra benefit of allowing runtime errors if the wrong type is passed to $arr, while writing my $arr = shift would allow to pass whatever you want. :)

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

    PS: As a side note:

    I was once meditating of adding new sigils for €arrrefs and £hashrefs but this is not only problematic with character encodings but also with keyboard designs.

    Just think of The Damians suggestion of appending _ref to each $name. What I do is to prepend $a_... , $h_... , $c_...' . This could be avoided if we had sigils for those references.

[reply]
[d/l]
[select]

      Well, I did not mean to suggest we do away with sigils altogether. These are just too convenient, if only for string interpolation.

      To illustrate the possibilities: let's say we have the statement

      my foo = [ 1, 2, 3 ];
      This shadows all other symbols foo in scope. Further, any $ @ % sigils on foo are just shorthand for ${} @{} %{}. Now you can write
      print @foo;
      ... and have it work DWIM. Or use the bare foo as reference. But the problem is, if foo refers to code you'll need explicit () to make the call. Hmm. And then, is $doh->foo() a method call or autoboxing? There are probably many caveats I can't think of. So you may be right that this feature wouldn't integrate well.

      Anyhow, the more compact syntax would see more use. Isn't this all about hubrislaziness after all?

      2017-04-01 Embarrassing. I think laziness but write hubris, some times. Blame perl!

[reply]
[d/l]
[select]

In Section Meditations