{ prototype / parsing issues }
I fail to see your point here. There's nothing implicite going on here. sin takes an argument, and hence
what follows is parsed as an expression (so the slash is the start of a regex). time doesn't take an argument, hence what follows is parsed as an operator (so the slash is a division).
Confusing for people who can't deal with context sensitive tokenizers, but that has nothing to do with implicite things.
Why is it OK to use implicite arguments for shift?
Because it isn't ambiguous.
Not putting a 'return' before the last statement of a subroutine isn't ambiguous either. The last expression executed in a subroutine will be the value returned from that subroutine. Always. Without exception.
It seems to me that you think Perl gives one too much rope to hang yourself. That's ok. I think Perl does that for the majority of the coders. But I also think that if you find Perl too scary, or that if you want to limit yourself to a small subset of Perl because there are many features you find confusing or unclear, you should stop programming in Perl, because your mindset just doesn't fit Perls. Nothing wrong with that, there are many other languages that will fit you better.
| [reply] |
Don't kid yourself, nothing is ambiguous in a computer language. For some constructs, the outcome is just impossible to predict without running the code. :-)
Here's my rant.
{ prototype / parsing issues }
I fail to see your point here. There's nothing implicite going on here. sin takes an argument, and hence what follows is parsed as an expression (so the slash is the start of a regex). time doesn't take an argument, hence what follows is parsed as an operator (so the slash is a division).
The problem here, is that while perl is perfectly capable of interpreting these statements unambiguously, humans find it much harder. If you don't know sin() takes a single argument and time() takes none and that they're prototyped as such, you can run in to really weird and hard to find bugs. Now, for the core language, this isn't all that hard, because you can learn the built-ins you regulary use in a reasonable amount of time, and they're all pretty well documented.
If, on the other hand, you're dealing with user-defined functions, you really do not want to have to think about prototyping. IMO if a function has a prototype, it had better have a good reason for it, documented in the provided pod (and commented at the definition itself, if the pod is located somewhere else). The only reason I've ever used a prototype in serious code is to be able to do away with explicit sub { } declarations when passing an anonymous sub as an argument, and even then it's debatable,
Using shift() without arguments - it's used so much for reading subroutine arguments, that any reasonable perl programmer should know what it does. This doesn't mean I like it though; IMO shift() = shift(@_) is too much of a kludge (and inefficient, too) for something that's used so much (positional parameters).
As for "dropping" values off a subroutine - I agree with you there - it's a consistent, simple rule and perl programmers should know that subs return the value of the last expression. They'd get in trouble if they thought otherwise anyway.
| [reply] |
| [reply] |
The last expression executed in a subroutine will be the value returned from that subroutine. Always. Without exception.
Moreover, Perl is not the only language that supports that particular idiom. Both Scheme and ML do as well if my memory serves me correctly. It makes somewhat more sense in those languages where a "block" is just a sequence of expressions and there's no real notion of a "statement." OTOH, it's consistent with the behavior of do and eval in block syntax (not to mention map and grep, though some posters in this thread seem opposed to this usage), where it is required because those BLOCKs are not subroutines.
| [reply]
[d/l]
[select] |
