I'll concentrate on the mistakes. If I were to criticise all the other many weird formulations and expressions in this guide which make it hard to unambiguously understand what the author meant, I would still sit and be typing here tomorrow.<p>----<p>> A code comment in Perl begins with a hash #<p>Hashes are already something different in Perl. Avoid ambiguity, use the common name of that character: number sign.<p>> procedure<p>This word is used through-out, but the official Perl documentation does not mention it. Use the word subroutine (or just sub for short) instead.<p>> The $ prefix references a variable as a scalar<p>> Array variables use the prefix @<p>This is the wrong explanation. The sigil denotes the mode of access, @ indicating the expression evaluating to a list value, $ indicating a single value. This becomes clear when one examines slices of a compound data structure.<p><pre><code> @arr = ("foo","bar","baz");
$arr[1]; # "bar"
@arr[2,3]; # ("bar", "baz")
%hash = ("foo", 1, "bar", 2);
$hash{"foo"}; # 1
@hash{"foo", "bar"}; # (1, 2)
</code></pre>
The guide mentions the change from @ to $ or from % to $ only in passing without explanation, and does not mention slices at all.<p>> Hash variables expect an array for initialization.<p>No, a list.<p>> three contexts in which an expression may be evaluated:<p>> 1. scalar<p>> 2. array<p>> 3. void<p>No, the second is list context.<p>> Is localtime() returning a scalar, or an array?<p>No, a scalar or a list.<p>> By default, the arguments to a procedure are in the array context, which means that the comma operator expects both of its operands to be arrays. It promotes them to single-element arrays if they are scalars.<p>> It seems that the function call still flattened out the arrays (and hashes) when making the call.<p>This is completely misleading. A sub takes always a list. What is described here has nothing to do with arguments, but is the consequence of the specifics of how values are evaluated into a list. This also happens, for example, on list assignment.<p>> all of the following are equivalent procedure calls:<p>> print3 (1,2,3) ;<p>> &print3 (1,2,3) ;<p>This is wrong, there is a difference, it just did not show up in the example.<p>> In fact, the argument isn’t even hash, despite what the specifier says<p>Refer to the documentation: when not backslashed, % is defined to behave like @.<p>> sub use_hash (%) {<p>> print $_[0]{"foo"} ;<p>> print $_{"foo"} ;<p>> print @_{"foo"} ;<p>> }<p>> use_hash ("foo" => 1701) ; # prints nothing<p>No wonder. The code is broken.<p>@_ contains a plain list value. To access it with a hash subscript, turn it into a hashref first.<p><pre><code> print +{ @_ }->{"foo"};
print ${ {@_} }{"foo"};
</code></pre>
> The specifier & expects to receive a function<p>Not function, coderef is the appropriate word.<p>> To accept a bareword filehandle as an argument, it becomes necessary to use the rarely used * prototype specifier<p>Simply passing *F is also possible, no prototype involved.<p>> The repetition operator x repeats a string or an array,<p>No, it repeats single or list values. Scalars are coerced into their string representation, and lists are simply repeated unchanged.<p>----<p>Closing words: This is amateur hour, not worthy of a professor. Advice for next time: consult domain experts and have them proof-read before publishing, and also always give your documents a last-modification date and version history, or at least a version identifier.