Sometimes there are contradictions. What applies to a list (list value), perhaps does not apply to a list (list value constructor)
Can you show some examples?
In the documentation often list is used for both list value and list value constructor. This make it difficult to understand the documentation. ... The list concept and for all flattening should be described more clearly in the Perl documentation. ... The risk to lose a Positional argument should be explicit clarified
I don't disagree that Perl's concept of lists can take some getting used to, and clarifying documentation is always useful. I should note though that, while Perl's documentation is often used as a reference, it's not always perfect, and I would suggest also looking into The Camel and similar books (e.g. Learning Perl, Modern Perl) to see if they help explain it better. In any case, documentation patches are usually a good thing; in my own experience, one might have to revise them a couple of times after feedback from P5P, but that should only help improve them.
Here I use: In a subroutine call the arguments are passed/bound to the parameters (formal argument) in the subroutine definition. The arguments for a call are evaluated, and the resulting values are passed to the corresponding parameters. I have always though, that the commas in a call to a subroutine, separate the argument list in sequence of values each corresponding to a parameter. call('P1', 'P2', 'P3'). There can be Positional parameters in a subroutine definition.
To me this seems to be the core of your question, and I have to say that what you write here is actually not Perl's concept. You quoted it yourself:
The Perl model for function call and return values is simple: all functions are passed as parameters one single flat list of scalars, and all functions likewise return to their caller one single flat list of scalars. Any arrays or hashes in these call and return lists will collapse, losing their identities ...
You're saying that in test( 'P1', nop1, 'P3' );, nop1 is a positional parameter, but the way Perl sees it is after evaluation. You may also note that perlsub makes no mention of "positional" (except in the section on the still-experimental signatures).
In conservative programming, there should be no subroutine calls in the argument list!?
It's something to be careful with, definitely; there have even been serious security issues related to this. There are workarounds though: Perl's scalar can be used to force a single scalar value, and there are extensions like PerlX::Maybe for pairs of arguments (which are like named parameters, though), and of course there's parameter validation using e.g. Type::Params. (I hesitate to mention it, because they should be used very sparingly and only when one knows what one is doing, but Prototypes can also be used to force scalar context on arguments.)
Split look like a subroutine but does not behave like one.
Correct, there are a few Perl functions that are exceptions and parsed differently from the rest. As LanX mentioned, they can generally be identified by prototype returning undef. The EXPR form of map and grep and similar (the BLOCK forms can be created using the & prototype). Note that split does behave like there is an implicit qr// on the pattern.
The meaning of the slashes in /PATTERN/ should be explained.
I'm not sure about this one, since it's just a regular expression like any other (perlop, perlretut, perlre). (Okay, one exception that I can think of off the top of my head: the empty pattern // is treated differently.)
In reply to Re: Split does not behave like a subroutine
by haukex
in thread Split does not behave like a subroutine
by bojinlund
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |