Even though it is correct

It is not correct. Your examples prove that you're wrong.

strict's error message is that strict doesn't understand the LIST arguments. Perl understands them just fine. The set error message is that Perl didn't find a set.pm module. Perl understood the LIST arguments just fine.

Please stop posting nonsense. You're wasting time and hurting people who don't know enough to ignore your ignorance.

Update: I reread this and realized the nonsense went even deeper.

The intended declaration of $y did not succeed

Indeed it did. That's why strict complains about the unrecognized tag '666'.

There is probably a “hole” in the BNF grammar within the interpreter.

Utter nonsense, which proves you didn't bother to look at the grammar at all.

First of all, there's no "BNF grammar" in the interpreter. There's a parser and a lexer which you could, if you were enterprising enough, potentially represent in Backus-Naur Form, but it's not expressed as such anywhere within the Perl source code, and there is no singular representation of grammar within the Perl source.

Second of all, you're expressing surprise that assignment is an expression. In other words, by your logic, the fact that $x = $y = $z works is an unanticipated accident of implementation that should be fixed. Similarly, (my $x = $y) =~ s/\A\s+|\s+\Z//g; should not work, in your incorrect interpretation of Perl.

Arguably, you could be complaining that lexical declaration should not be allowed in expressions, which is still a silly point given the en-passant assignment and substitution technique of the previous snippet, but witness:

sub main {
    foo(my $x = 1);
    say $x;
    return 0;
}

sub foo {
    say ++$_[0] . ' in foo';
}
[download]

... or:

sub main {
    bar(my $x);
    say $x;
    return 0;
}

sub bar {
    $_[0] = 'assigned in bar';
}
[download]

Should you write code like that? I think we all know the answer—but let's not delude ourselves into pretending that this is some unintentional side effect of implementation. Assignment-as-expression semantics, along with compile time variable declaration, are well established in Perl. Misunderstand them at your own peril.

Oh, man. When chromatic slaps you down, you know you're past due for some serious introspection.

Oh, man. When chromatic slaps you down, you know you're past due for some serious introspection.

obvious self deception is obvious

Simpler examples of declaration inside of an expression:

open(my $fh, ...)
[download]

( my $x = $y ) =~ s/.../.../;
[download]

Arguably it should be disallowed

Why? LIST here is the standard argument passing mechanism. Making an exception for a my expression in an argument list or making an exception for expressions in import lists would be complicated and break symmetry of syntax, semantics, and implementation.

This is the piece that sundial's missing. It's a confusing combination of existing Perl behavior because it's uncommon and relatively useless, but it's valid syntax because of the way Perl works.

Actually, I agree with you -- I didn't say I would be the one to make that argument ;-)

Maybe I should have suggested that it could arguably be a warning. Perl warns on all kinds of things that are valid but "potentially confusing," and there seems to be a fair amount of back-and-forth about what those things are.