Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^6: Evaluation Order again.

by oiskuu (Hermit)
on Jun 01, 2016 at 17:48 UTC ( [id://1164707]=note: print w/replies, xml ) Need Help??


in reply to Re^5: Evaluation Order again.
in thread Evaluation Order again.

Now you're splitting hairs. "Arguments to subroutines are evaluated in list order: from left to right." Is that better?

Remember, documentation is not written for a person who already knows everything. (I need the clarity to stop imagining unwarranted parallels.)


Update. ikegami: human language affords its speakers some latitude. In this case, "arguments" can refer to elements on stack (a technical view); it can refer to tokens of source code (parsing context); or it can refer to the expressions that end up as arguments. All three interpretations (and possibly more) are used in perl documentation. How would you describe f($a, $b, $c)? A function supplied with three expressions?

Replies are listed 'Best First'.
Re^7: Evaluation Order again.
by ikegami (Patriarch) on Jun 01, 2016 at 18:25 UTC

    No, it's still wrong, and for the same reason. Arguments aren't evaluated. Arguments are values, not code.

    You are probably referring to the argument list expression, but it's not necessary evaluated from left-to-right either.

    Here's an example that's right-to-left:

    $ perl -E' sub L :lvalue { say "L"; $L } sub R { say "R"; $R } sub { }->( L() = R() ); ' R L

    Here's an example that's neither:

    $ perl -E' sub X1 :lvalue { say "X1"; $X1 } sub X2 { say "X2"; $X2 } sub X3 { say "X3"; $X3 } sub { }->( X1() = X2() || X3() ); ' X2 X3 X1

      I must concur that this argument about your pedantic definition of the word "argument" is neither helpful nor enlightening.

      On my first try, I found:

      A value or reference passed to a function, procedure, subroutine, command or program, by the caller. For example, in the function definition

      square(x) = x * x

      x is the formal argument or "parameter", and in the call

      y = square(3+4)

      3+4 is the actual argument.

      Clearly, "3+4" is not a value, it is an expression.

      Yes, in the case of Perl 5, things get a little more muddled and one way to conceptualize things in an attempt to unmuddle them is to declare that the invocation of a Perl sub does not take a list of "actual arguments", but instead, a single expression that might result in multiple values and thus the presence of a comma is not really separating (actual) argument (expression)s.

      But talking about Perl sub arguments in the standard manner doesn't run into problems in the majority of cases. And even when it does, there are other ways to unmuddle things that don't require throwing out the familiar model and language just because it doesn't quite fit for some cases.

      So stop insisting people are wrong just because they choose to use one word in a traditional and widely-understood manner.

      I actually believe that Perl's comma operator is just a descendant of the use of comma to separate actual argument (expression)s in function calls. And the list-flattening behavior really isn't enough reason to insist that everybody abandon that way of understanding them and talking about them.

      Shell scripts have an analogous situation but my copy of "man bash" deals with that without your pedantic gymnastics:

      Unquoted implicit null arguments, resulting from the expansion of parameters that have no values, are removed.

      and

      yank-nth-arg (M-C-y)
      Insert the first argument to the previous command (usually the second word on the previous line) at point.

      You see, they don't feel ashamed to occasionally talk about an expression as an "argument" even though, based on their definition, it strictly (pedantically) isn't:

      The words that are not variable assignments or redirections are expanded. If any words remain after expansion, the first word is taken to be the name of the command and the remaining words are the arguments.

      - tye        

        Writing clear documentation is an exercise in pedantry. If someone is argue that the documentation should be changed, I consider the choice of words in the proposed revision to be very important. In this case, it could easily be fixed by replacing "the arguments" with "the argument list". I don't why there's no much resistance to this. It's silly that so much fuss is being made about this since the point I was making is that proposed statement is still wrong when you fix the wording.

        If you argue that "3+4" is the actual argument in "f(3+4)", then you get in the ridiculous situation where you say that "@a" is the actual argument in "f(@a)".

      You are probably referring to the argument list expression

      That sub only has one argument; the result of evaluating a single expression.

      So, no "list" involved, and your argument is pure pedantic fallaciousness.

      Pretty much your trademark. Make an unsupportable statement and then defend it to the death by cloaking the issue in a string of non sequiturs.

        Please ignore the parent post. It's completely wrong.

        • They are lying about me saying there was more than one argument.
        • They are lying when he said it's not an argument list. I got the name from perlsub. I called it the "expression that follows the call" before that. The name isn't even relevant!
        • They are lying about my claim is indefensible. You can run the code yourself to ascertain that the expression that follows the call (which perlsub calls the argument list) isn't always evaluated from left to right.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1164707]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2024-03-29 09:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found