Spec Clarifications

[Ovid]

I'm trying to write a grammar and I'm hitting a variety of edge cases. Typically, grammars express syntax, not semantics, and I'm seeing issues with the latter.

Ambiguous Keys

my { 'a-key', 'b.key' } = $d;       # Short for { 'a-key' => $a_key, 'b.key' => $b_key }
my { 'foo bar' } = $d;              # Short for { "foo bar" => $foo_bar }

Those introduce ambiguities because a-key, a.key, a key and a_key all resolve to the same thing and we no longer have a one-to-one mapping. If we have multiple keys which map to the same variable name, which one is chosen? Given that this is a hash, it would be effectively random.

We could set up precedence rules, such as "exact match first", but after that? Edit distance doesn't work because a key and a-key have the same edit distance.

I suspect this would be a constant source of bugs.

And what about this?

my { '3-key', '-.key', ' key' } = $d;

What variables do we get there?

Sorting

Sorting is mentioned here:

my { $key => $val } = $d;           # Unpack a single pair hash
my { @key => @val } = $d;           # Unpack all keys and values (unzip)
my [ @key => @val ] = $d;           # Unpack all keys and values *sorted*
my { @keys } = $d;                  # Key array of all keys
my [ @keys ] = $d;                  # Key array of all keys *sorted* (RHS must be hashref)
my { @keys => _ } = $d;             #   Same as above
my [ @keys => _ ] = $d;             #   Same as above but *sorted*
my { _ => @vals } = $d;             # Get array of all values

For completeness, we should add:

my [ _ => @vals ] = $dl    # get array of all values *sorted*

That being said, how do we control sorting? By string, numerically, by length, by some property of the value? If anything, I suspect adding sorting should be a post-MVP feature because we'll need to plan that carefully.

I think your "Inline list expressions" will help there.

Operator Assignment

The spec shows this:

[ $a, $b ] //= $d;                  # Only assign undefined variables
[ $a, $b ] .= $d;                   # Append string to every var
[ $a, $b ] += $d;                   # Add number to every var

For the first case, imagine this (note the my):

my $aref = [ 1, undef ];
my [ $a, $b ] //= $d;

In the above, $b will remain undefined. I think you intention is "only overwrite existing values if the corresponding value is undefined". Thus, a prefix with my would be confusing. If we disallow my [ $a ] //= $d but allow my [ $a ] = $d, that's inconsistent with how Perl generally behaves.

Also, what does this do?

my $aref = [ 1, undef, 2 ];
[ $a, $b ] //= $d;

In the above, is $b undefined, or equal to 2?

And someone is going to write this:

{ $a, $b } //= $d;                  # Only assign undefined variables
{ $a, $b } .= $d;                   # Append string to every var
{ $a, $b } += $d;                   # Add number to every var

Is that explicititly disallowed? If not, what does it do?

Regex Captures

You have this:

my [ $match, $cap1, $cap2 ] = $str =~ /…/;

Currently, we can do this:

my @matches = $str =~ $regex;

The only difference, I think, is that the destructured version would assign a boolean to $match indicating success?

Also, destructuring is effectively unpack for data structures. Trying to shoehorn its behavior onto string matching feels like an odd fit.

[gugod]

(On ambiguous keys) With the current spec:

    my { 'a-key', 'a.key' } = $d

This is the same as saying:

   my ($a_key, $a_key) = ( $d->{"a-key"}, $d->{"a.key"} );

Implementation-wise, perl would give just a warning about the 2nd variable masking the 1, and move on. And maybe that's what should be happening (since it already happens in list-assign)

In the context of destructive assigning though, I'd say this is indeed a surprise, but on the other side, since perl developers should eventually learn that . cannot be part of variable identifiers, it is less of a surprise -- they'll know why the term a.key cannot be mapped a var named $a.key. And usually we don't make 2 hash keys that looks this similar in the same hash (hopefully not)

I'd prefer to make such case a runtime error, but since in perl, variable-masking is only a warning, perhaps it makes sense to just warn ? (assign.pm could add additional warning when such naming conflict is detected)