in reply to Re^8: Ansi Perl
in thread Ansi Perl

You're making my point for me. All of your examples (ab)use the same sorts of nooks and crannies of the language that the OP readily admits have to be avoided by C programmers in order to avoid breakage.

The first example combines autoloading with typeglobs in a way that the Camel book doesn't even think about addressing. As you point out yourself, the questions you ask cannot be answered from the documentation and the Camel, which implies that the code represents undefined behavior. How is this any different from the undefined behavior in C, if you program outside the ANSI spec by targetting a specific compiler and OS?

The second example plays games with aliasing, again in an obscure and AFAIK undocumented corner of the language.

The third example tries to abuse barewords, which have been heavily deprecated since the Perl4 days and have been throwing warnings since 5.003 at least. Anybody who writes something like that in production code deserves whatever he gets, and it is trivial to find similar examples of nonstandard code breaking in C due to something as minor as compiling for a differently-endian hardware, to say nothing of switching compilers.

If you write your code based on the information in the 2nd edition Camel book, it will work in all Perl versions from 5.003 forward; if there is even a single counterexample to this, I am not aware of it. (Feel free to point it out...) Needing to avoid the undocumented nooks and crannies is no worse in Perl than it is in C. When issues like endianness are considered, I maintain my previous assertion: Perl is more standardized than ANSI C.

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

Replies are listed 'Best First'.
Re^2: Ansi Perl
by Anonymous Monk on Dec 28, 2004 at 10:16 UTC
    The first example combines autoloading with typeglobs in a way that the Camel book doesn't even think about addressing.

    But the Camel discusses autoloading, and it discusses typeglobs. Sure, it doesn't discuss combining them, but it doesn't discuss combining autoloading and splicing either. Does that mean the use of splice inside an autoload routine is "undefined behaviour"? If not, then what determines which undiscussed combination of discussed techniques is "undefined" behaviour, and what isn't?

    The second example plays games with aliasing, again in an obscure and AFAIK undocumented corner of the language.

    Bzzzt! Thank you for playing.

    From the 5.005_03 perlfunc manual page: 

    values HASH
        Returns a list consisting of all the values of the named hash.
        (In a scalar context, returns the number of values.)  The
        values are returned in an apparently random order.  The actual
        random order is subject to change in future versions of perl,
        but it is guaranteed to be the same order as either the keys()
        or each() function would produce on the same (unmodified) hash.
 
        Note that you cannot modify the values of a hash this way,
        because the returned list is just a copy.  You need to use a
        hash slice for that, since it's lvaluable in a way that
        values() is not.
 
            for (values %hash)      { s/foo/bar/g }   # FAILS!
            for (@hash{keys %hash}) { s/foo/bar/g }   # ok
 
        As a side effect, calling values() resets the HASH's internal
        iterator.  See also keys(), each(), and sort().
    (Emphasis mine). But from the 5.8.x manual: 
    values HASH
        Returns a list consisting of all the values of the named hash.
        (In a scalar context, returns the number of values.)
 
        The values are returned in an apparently random order.  The
        actual random order is subject to change in future versions of
        perl, but it is guaranteed to be the same order as either the
        "keys" or "each" function would produce on the same (unmodi-
        fied) hash.  Since Perl 5.8.1 the ordering is different even
        between different runs of Perl for security reasons (see "Algo-
        rithmic Complexity Attacks" in perlsec).

        As a side effect, calling values() resets the HASH's internal
        iterator, see "each". (In particular, calling values() in void
        context resets the iterator with no other overhead.)
 
        Note that the values are not copied, which means modifying them
        will modify the contents of the hash:
 
            for (values %hash)      { s/foo/bar/g }   # modifies %hash values
            for (@hash{keys %hash}) { s/foo/bar/g }   # same
        
        See also "keys", "each", and "sort".

    The third example tries to abuse barewords, which have been heavily deprecated since the Perl4 days and have been throwing warnings since 5.003 at least.

    Did you actually look at the code? Here's it again: 

    print 80.101.114.108;

    [download]
    No bare words in this piece of code, and no version of Perl issues a warning. 
    $ perl5.00503 -wle 'print $]; print 80.101.114.108'
5.00503
80.101114.108
$  perl5.8.6 -wle 'print $]; print 80.101.114.108'
5.008006
Perl

    [download]
    See, no warnings. And for your information, in 5.005_03, 80.101.114.108 isn't a bareword. It's the concatenation of two floating point numbers. In 5.8.6, it's a v-string (which as shown are in another thread, are on their way out, so the program above is probably not going to print "Perl" in 5.10 or 5.12).
[reply]
[d/l]
[select]
      Note also that the combination of autoloading and aliasing is exactly what AutoLoader.pm is doing. Which is part of the core distribution. And which is documented in the second edition of the Camel. Chapter 7.2.
[reply]

In Section Seekers of Perl Wisdom