This question pertains to the hard copy of the first English
edition, printed July 2005, chapter 9, pages
182 - 183, the "Named Arguments" section. I have checked the on-line
errata lists and there are no corrections or alterations for these
pages.

The discussion of "named arguments" contrasts building an
anonymous hash of name/parameter pairs in the argument list
of a function call with directly assigning the argument list
(i.e., @_) to a hash within the body of the function.

With respect to building an anonymous hash of named arguments,
page 183, second paragraph, states that errors
"... will be reported (usually at compile time)
in the caller's context ..." (emphasis added),
but I don't see that this is so.
(However, everything else works as advertised: the anonymous hash
version of named arguments produces a warning at the point of
the function invocation.)

Certainly, a malformed function call like func({ one => 'uno', two => 'dos', three => });
from the example code below does compile and only warns at run time.
Can anyone give an example of a compile time error (or
warning) associated with this invocation technique, or any
explanation or example of what TheDamian was referring to?

>perl np_ah_vs_ha_1.pl
program running
anon hash: one translates to uno
anon hash: one translates to uno
anon hash: one translates to uno
anon hash: one translates to uno
anon hash: one translates to uno
anon hash: one translates to uno
hash assign: two translates to zwei
hash assign: two translates to zwei
hash assign: two translates to zwei
hash assign: two translates to zwei
hash assign: two translates to zwei
hash assign: two translates to zwei
Odd number of elements in anonymous hash at np_ah_vs_ha_1.pl line 71.
anon hash: one translates to uno
Odd number of elements in anonymous hash at np_ah_vs_ha_1.pl line 72.
anon hash: one translates to uno
Odd number of elements in hash assignment at np_ah_vs_ha_1.pl line 85.
hash assign: two translates to zwei
Odd number of elements in hash assignment at np_ah_vs_ha_1.pl line 85.
hash assign: two translates to zwei
program done

In the above examples, both of the costly structures for %hash and $hashref are allocated at the pad of the current scope and populated at run time. In the last example, that structures are set up and teared down at every call to frobnitz() :

"It's something that would be easy to test at compile-time, ergo it must be tested at compile-time".

Maybe the edge case that it's not possible to decide at compile-time if this hash %h = ( key => @arr ) has a well-formed list at RHS with an even number of elements (how many elements will @arr have ???) makes it not so easy to test it generally at compile-time?

A good work-around might be to throw a warning if arrays are used as hash-values after a fat comma... I would really like it this way, since list-flattening in values really seems too "odd" to me!