Front page | perl.perl5.porters |
Postings from July 2012
Re: [perl #113554] my() with empty list causes weird error
Thread Previous
|
Thread Next
From:
Darin McBride
Date:
July 8, 2012 07:13
Subject:
Re: [perl #113554] my() with empty list causes weird error
Message ID:
1649739.oBM1SKbjo1@naboo
On Sunday July 8 2012 8:02:21 AM Aristotle Pagaltzis wrote:
> * Darin McBride <dmcbride@cpan.org> [2012-07-08 06:50]:
> > On Sunday July 8 2012 6:42:58 AM Aristotle Pagaltzis wrote:
> > > Why would the last example here be the odd one out? What makes an
> > > empty list so abhorrent in the vicinity of `my` that unlike anywhere
> > > else in Perl, there it has to be forbidden?
> >
> > Personal opinion, but "my ()" makes no semantic sense even if it makes
> > syntactical sense.
>
> What about its semantics is nonsensical? It seems perfectly well-defined
> to me, the concept of “zero” is not exactly novel.
Well-defined != sensical.
Basically, you're saying that its syntax makes sense (well-defined), and using
that to question my claim that it makes no semantic sense when I already
conceded that it may make syntactical sense.
> (Do you mean it makes no intentional sense? I would agree with that. But
> there are many other things you can do in a programming language that
> are pointless: multiplying by 1,
$x * 1 -- makes sense as a a numification, like +0, but with different
precedence. In C, not so much sense.
$x * $y where $y happens to be 1? Completely different, perfectly sensible.
> concatenating with the empty string,
$x . "" makes sense in the same way - forcing stringification. It actually
does something. In C? The concept doesn't exist. In C++, again, foo + ""
makes about as much sense as in Perl, depends on what the + operator does
here. C<$z = $x . ""> means something entirely different from C<$z = $x>.
Sometimes. :-)
$x . $y where $y happens to be an empty string? Again, completely different,
perfectly sensible.
(I don't think you were referring to the $y cases above, but I just wanted to
draw the parallels.)
> a statement consisting solely of an expression with no side effects,
> etc. That doesn’t mean it’s a good idea to disallow them.)
Well, the previous examples aren't statements consisting solely of an
expression with no side effects ;-)
foo() for ();
This statement doesn't make much sense. However, it's simply the same as:
foo() for (@list)
where @list is empty. The my keyword just doesn't have the same need for
fallback. With my, the variables it operates over are right there in the
code. There's no expansion. C< my (@list) > doesn't create 0 or more lexical
variables, it creates exactly one lexical array. Whereas C< for (@list) >
will loop 0 or more times. The "zero" concept in for () comes from that
potentially empty list, but my uses a hard-coded list, and that's where things
are different in my mind.
And, to be honest, I'd think that if I had C< foo() for () > in my code
literally, it's probably something that could be warned. As in, I probably
forgot something. Arguably, however, since it has been allowed for so long
("hysterical raisins" I believe it's called), the explicit C< () > could be
construed as "I am doing this on purpose", though I think that's a fairly weak
line of argument.
And, Eric, not that I have much say in the matter, but I'd find a simple
comment "# no arguments" or even an empty prototype, to be a clearer way to
document a lack of arguments ;-) Though I do understand that an empty
prototype significantly changes other things. Also, if you did want to
document your lack of arguments in code, omitting the my, C<() = @_>, would
still work. I do understand, however, that in the rare case where you start
with a documented "no arguments" scenario and then you later change it to
"some argument(s)", you'd have to add the my as well as the variable names.
I'm not convinced this syntactical sugar is worth the semantic issue (from my
perspective) with a lack of parameters to my.
Thread Previous
|
Thread Next