Re: Unifying namespaces of @name and $name... (bare lexicals)

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.

Comment on Re: Unifying namespaces of @name and $name... (bare lexicals) Select or Download Code

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]
Re^3: Unifying namespaces of @name and $name... (bare lexicals) by oiskuu (Hermit) on Mar 28, 2016 at 09:13 UTC
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 ~~hubris~~laziness after all? 2017-04-01 Embarrassing. I think laziness but write hubris, some times. Blame perl!	[reply] [d/l] [select]

Re: Unifying namespaces of @name and $name... (bare lexicals)

UPDATE