in reply to winter games, perl, ice and bling

Thanks for the comments.

I found the comments about shielding $/ to be interesting. Presumably, the code is made to be standalone, or else all of the solutions should have wrapped and closed all of their variables in namespaces and functions less the first few lines of the PerlBuzz solution open the (eek) dangers of global variables! 
use warnings;
use strict;

my %averages;

[download]
On another note, I feel bad about including the obfuse looking bits near the top (I assure you they were not intentionally so), since the latter half seems to have gone unnoticed!

That is, what about *challenging* parsing. Surely the people at scriptnet seem to have omitted any challening problems...

Here's a question: are there any really challenging parsing problems out there?

Replies are listed 'Best First'.
Re^2: winter games, perl, ice and bling
by BrowserUk (Patriarch) on Mar 27, 2008 at 00:27 UTC
[reply]
Re^2: winter games, perl, ice and bling
by kyle (Abbot) on Mar 27, 2008 at 00:16 UTC

    are there any really challenging parsing problems out there?

    Yes.

    Surely the people at scriptnet seem to have omitted any challening problems...

    In an earlier discussion, I think the monks agreed that the games would not be any challenge for professional programmers. The target audience seems to be students.

[reply]
Re^2: winter games, perl, ice and bling
by perrin (Chancellor) on Mar 27, 2008 at 02:24 UTC
    Global variables are nowhere near as dangerous as modifying $/. If you used any module from this code, and it opened a file but didn't set $/, all hell would break loose. I'm telling you this from personal experience, not from theory.
[reply]

      Then raise a bug or a patch against the module(s).

      Unless the modules explicitly documents that it uses whatever value you assign to $/ or $\, eg. Tie::File, then no module author has the right to either rely upon some default value, or modify them except for local use. That right belongs exclusively to that author of main::main.

      Even if you scope and localise modifications to these variables, if you also need to call a module's functions or methods within that scope, you will break them if they make assumptions.

      Module authors should never make assumptions about or permanently change the environment they will inherit. That privilege remains the exclusive preserve of the author of main.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        What you're suggesting is a return to The Bad Old Days, when module authors couldn't even count on arrays starting at 0 because you might have changed $[. That sort of thing is frowned on these days, because it made writing modules totally unmanageable. A module author has every right to expect that magic variables like $/ will be at their default values and a programmer who fails to localize changes in these variables is the one at fault for the trouble caused.

        For reference, see MJD's Sins of Perl Revisited.

[reply]

In Section Seekers of Perl Wisdom