Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Why no warnings for 1 in void context?

by merlyn (Sage)
on Jul 16, 2005 at 17:15 UTC ( #475482=note: print w/replies, xml ) Need Help??

in reply to Why no warnings for 1 in void context?

And just when you think you've got that figured out, check out these:
$ perl -wce '1; "ds"; "di"; "ig"; 0' -e syntax OK $
Then try other two-letter combos, which get the warnings. Why these? (I know!)

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re^2: Why no warnings for 1 in void context?
by tlm (Prior) on Jul 16, 2005 at 17:50 UTC

    Well, also "ignoramus" and "dimwit" (which, BTW, pretty much describe my state right now) sail through without warnings... After some googling, I suspect the special treatment of such strings has something to do with nroff/troff/groff, but I know zilch about these, so I'll have to leave it at that...

    the lowliest monk

      Very good! Yes, it's a little known feature of perl that certain nroff directives are legal in perl, in the sense that they are always recognized, even if not defined. (They will not override or change the meaning of any actual definitions in your code.) The place to begin is in op.c, in function Perl_scalarvoid. Here we learn that any symbol occurring in void context which begins with 'di', 'ds', or 'ig' is given a pass to sail by without warning.

      (In the exact same place, 0 and 1 are defined as non-warning-worthy in void context. merlyn knew that, of course.)

      The code tells us to look in the pink camel [that's Programming Perl 1st ed.], near page 319. This is where two scripts, wrapman and wrapinst, are presented. This is really the best clue to why these nroff directives are special... and what it boils down to is Larry's (clever) attempt to make it easy to document code by making it possible for (some) code to be both legal perl and legal nroff. I think even he would admit that it wasn't terribly successful. But this was in the days before POD.

      No doubt this feature has been exploited in obfu.

        Why not just quote the source?

        // op.c 765 else if (SvPOK(sv)) { /* perl4's way of mixing documentation and code (before the invention of POD) was based a trick to mix nroff and perl code. The trick was built upon these three nroff macros being used in void context. The pink camel has the details in the script wrapman near page 319. */ if (strnEQ(SvPVX(sv), "di", 2) || strnEQ(SvPVX(sv), "ds", 2) || strnEQ(SvPVX(sv), "ig", 2)) useless = 0; }
Re: Why no warnings for 1 in void context?
by jonadab (Parson) on Jul 17, 2005 at 11:31 UTC
    This thread makes me really glad Perl6 is throwing out all that old bathwater.

      Yeah, I've often wondered how much faster Perl 5 would be if it didn't have to support a whole bunch of deprecated and/or obsolete features from previous versions of Perl. (Granted, the support for the feature discussed in this post probably has a minuscule impact on perl's performance, but there may be others that are not so negligible.) 1%? 10%?

      the lowliest monk

        Speed was not my concern, and I certainly wouldn't quibble over a 10% speed issue. (The user generally won't even notice a speed difference until it's at least 50%.)

        The reason I am looking forward to dumping all the legacy Perl4 malarke is because of its impact on coding, especially in terms of unexpected behavior and bugginess.

        Consider, for instance, an issue we recently ran into with SVG::Metadata, as follows: this module had been using XML::Twig to parse the metadata from SVG files. (SVG is an XML format.) Bryce had set it up to use Twig's simplify method to produce a hash-reference structure, which the code in's parse routine was navigating in more or less the usual way, e.g., $metadata->{'rdf'}->{'Work'} and so forth.

        However, as we started dealing with SVG produced by different SVG editors, we found that we were running into namespace issues; some SVG might list those elements as RDF:rdf and cc:Work, for example. So we put in code, similar to the above, but with extra logic like $elt->{'rdf'} || $elt->{'rdf:RDF'} ||$elt->{'RDF'} to check for those. Oops. Do you see the problem? Neither did we, at first.

        What on earth is a pseudohash? Turns out, it's some kind of inane legacy thing from the days of yore before Perl supported references, and as a result, you aren't allowed to test for a hash key containing a colon, if it might not exist. Serious bugs result. We ended up dumping the simplify()'ed hash-reference structure entirely in favor of XML::Twig objects and their methods, like $elt->first_descendant('rdf:RDF') Granted, I'm more comfortable with the methods anyway, now that I have taken the trouble to download about half of XML::Twig's rather lengthy POD into my brain, and it does allow us to dispense with checking for optional intermediate wrapper elements, and the resulting code is probably less buggy too; nevertheless, I spent hours ironing out this issue. I seriously doubt I'm the only one ever to bang into it. Who would have thought that a hash key (which is, after all, just a string) would have issues with containing a colon? Boo, hiss.

        There are other legacy Perl4 things besides the two we've discussed in this thread. They're all going away in Perl6, and I'm glad.

        "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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://475482]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2018-01-16 22:03 GMT
Find Nodes?
    Voting Booth?
    How did you see in the new year?

    Results (192 votes). Check out past polls.