Unexpected parsing

JadeNB has asked for the wisdom of the Perl Monks concerning the following question:

After reading Conditional Operator, and delighting in the potential for unreadable code coming from using a conditional operator as an lvalue, I wondered how far in advance the lvalues have to be declared.

Huh? Well, we know that

my ( $c, $d );
1 ? $c : $d = 'Hi';
[download]

is the same (to B::Deparse) as

my ( $c, $d );
$c = 'Hi';
[download]

but what if you don't want to declare the variables in advance? Well,

my $d;
1 ? my $c : $d = 'Hi';
[download]

is the same as

my $d;
my $c = 'Hi';
[download]

In the other direction, here's a strict-safe program that B::Deparse makes non-strict-safe:

$ perl -MO=Deparse -e 'my $c; 1 ? $c : my $d; $d'
my $c;
$c;
$d;
-e syntax OK
[download]

^*. How about if we declare both variables in the conditional?

$ perl -e '1 ? my $c : my $d'
Invalid separator character '$' in attribute list at -e line 1, near "
+$c : my "
Execution of -e aborted due to compilation errors.
[download]

Now, maybe there's some reason that parsing : my $d as an attribute list is good, or at least expected; but I can't see why 1 ? my $c : my $d would be parsed that way, but 1 ? my $c : $d wouldn't. Would somemonk enlighten me?

UPDATE: ^* Notice that B::Deparse changes the semantics here (but I guess there's always the disclaimer that that might happen). For example,

our $d = 'Out';
{
    1 ? 0 : my $d;
    $d = 'In';
}
say $d;
[download]

prints Out, but is converted by B::Deparse into

our $d = 'Out';
{
    '???';
    $d = 'In';
}
say $d;
[download]

which prints In.
UPDATE: Oh, maybe it's that a colon followed by whitespace and an alphanumeric is always interpreted as the beginning of an attribute list, even if we're waiting for the interstitial colon of a conditional operator. Is this correct? If so, is it the desired behaviour? If so, should the precedence table in perlop be changed to reflect it?

Comment on Unexpected parsing Select or Download Code

Replies are listed 'Best First'.
Re: Unexpected parsing by ikegami (Patriarch) on Dec 16, 2009 at 08:18 UTC
and delighting in the potential for unreadable code coming from using a conditional operator as an lvalue It takes next to nothing to make the cond op unreadable, but using it as an lvalue itself doesn't make it unreadable. `($axis ? $x : $y) += $distance;` [download] I can't see why `1 ? my $c : my $d` would be parsed that way, but `1 ? my $c : $d` wouldn't. It appears to be another case where heuristics enter into play. `my` is a valid attribute name, so `: my` is presumed to be an attribute. `$d` is not a valid attribute name, so `: $d` is taken to be the else expression of the conditional. Untested, but parens should clear that up. `1 ? (my $c : shared) : ... # shared is an attribute -vs- 1 ? (my $c) : shared # shared is func call` [download] `perl -MO=Deparse -e 'my $c; 1 ? $c : my $d; $d'` Note that conditionally executing `my` officially results in undefined behaviour.	[reply] [d/l] [select]
Re^2: Unexpected parsing by JadeNB (Chaplain) on Dec 16, 2009 at 08:30 UTC
`my` is a valid attribute name, so `: my` is presumed to be an attribute. `$d` is not a valid attribute name, so `: $d` is taken to be the else expression of the conditional. Thanks for the explanation! (I eventually figured out that it must be something like that, and updated my post; but probably it was after you had already begun yours.) Since the word ‘attribute’ does not occur in perlop or perlsyn, and since no other punctuation mark requires a visit to perlfunc to figure out how it parses, I wonder if it might be appropriate for the precedence table to mention this unexpected (by me) interaction? Note that conditionally executing `my` is officially undefined behaviour. Good to know, thanks. Is there any unified list of officially undefined things? I know, for example, by luck, that `$i++ + ++$i` can officially do whatever it wants, but I had no idea about this; who knows what other corner cases I'm missing?	[reply] [d/l] [select]
Re^3: Unexpected parsing by JavaFan (Canon) on Dec 16, 2009 at 11:43 UTC
I wonder if it might be appropriate for the precedence table to mention this unexpected (by me) interaction? No, I don't think so. The ':' isn't an operator, so it has nothing to do with precedence. It doesn't belong in a precedence table. Determining whether something is an operator (or part of an operator) or not isn't dealt with with the operator precedence table. Since the word ‘attribute’ does not occur in perlop or perlsyn, and since no other punctuation mark requires a visit to perlfunc to figure out how it parses But you only find something about attributes in perlfunc because my was specially added to `perlfunc`; my isn't a function. The details are in `perlsub`, where you would also go for punctuation as prototypes and some cases of parenthesis. Is there any unified list of officially undefined things? Not that I know of. But by all means, feel free to write up a list and submit is as a patch. Writing documentation doesn't require any coding language, which means most people can do it.	[reply]
Re^4: Unexpected parsing by ikegami (Patriarch) on Dec 16, 2009 at 17:05 UTC
Re^4: Unexpected parsing by JadeNB (Chaplain) on Dec 16, 2009 at 15:47 UTC
Re^5: Unexpected parsing by JavaFan (Canon) on Dec 16, 2009 at 16:04 UTC
Some notes below your chosen depth have not been shown here
Re^5: Unexpected parsing by ikegami (Patriarch) on Dec 16, 2009 at 17:20 UTC
Re^3: Unexpected parsing by ikegami (Patriarch) on Dec 16, 2009 at 16:59 UTC
Is there any unified list of officially undefined things? That's the only one that comes to mind. It's documented (too specifically) in perlsyn under statement modifiers (`my ... if ...;`). I know, for example, by luck, that $i++ + ++$i can officially do whatever it wants That one's simply undocumented. I wonder if it might be appropriate for the precedence table to mention this unexpected (by me) interaction? I don't see why not, although I don't think it'll ever be an issue in legit code (but my brain is too slow to make sure of that right now). Maybe as a warning in the doc for the cond op.	[reply] [d/l]
Re^4: Unexpected parsing by JadeNB (Chaplain) on Dec 16, 2009 at 17:41 UTC
Re: Unexpected parsing by BrowserUk (Patriarch) on Dec 16, 2009 at 07:35 UTC
This is fine: `c:\test>perl -MO=Deparse -e "my $c; 1 ? $c : my( $d ); $d" my $c; $c; $d; -e syntax OK` [download] In your version, it's trying to parse an attribute--like `$c :shared` Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "I'd rather go naked than blow up my ass"	[reply] [d/l] [select]
Re^2: Unexpected parsing by JadeNB (Chaplain) on Dec 16, 2009 at 08:06 UTC
In your version, it's trying to parse an attribute--like `$c :shared` I figured out from the error message what was happening with the parsing, but couldn't tell what was different about the 2 cases involving `my $c` that made them parse differently. I have updated my post with a guess (that it's the whitespace-plus-alphanumeric after the colon), but I'm not sure whether this is the desired behaviour or a bug (or my guess is wrong!).	[reply] [d/l] [select]