Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • disclaimer: I like where perl6 is going, but I certainly respect your dislike of that direction. These comments are intended only to help you clarify your opinion, not to de-value your opinion.

            > a number of changes are being made for the
            > sake of change. Things that we use a _lot_
            > in Perl 5, like '.' for concatenating, and
            > the dereference operator are going to change

    The fa
    • by Matts (1087) on 2001.10.25 8:35 (#1665) Journal
      OK, one thing that people have seemed to completely miss in my discussion of this is my fundamental objection: Perl 6 won't parse Perl 5.

      I accept a lot of your points and take them on board. My point about the file test operators wasn't that I dislike the new syntax - I think it's *much* better than doing tests on the magic underscore. I just dislike the file test operators altogether :-)

      You ask if I'd like to see slice and grep moved into a module. Well no, I wouldn't, because they are functions that operate on Perl's fundamental data types. But I *would* like to see things like the networking functions moved into modules.

      And you're right, I don't like the idea of using eval() either. It's a hack. I was being overly picky about that. However I didn't find the closure syntax confusing at all. Maybe it's just me :-)

      I do think you missed the point about the := being used. Let's look at the code:

      &assert_with_comparator := {
              unless ($^comparator.($^a, $^b)) {
                  throw Exception::FailedComparison :
                      comparator => $^comparator,
                      result     => $^a,
                      target     => $^b
              }
          }

      That's the code I meant, not the assignment code below that. Here we see a block being assigned to the function "assert_with_comparator". So why not use sub assert_with_comparator? Is it just for obfuscation? Secondly, where does the code block get its parameters from? There's no parameters declaration section, so the params appear to be magical. I mean, I know there's no interpreter yet, and so Piers maybe just made a boob on the above, so I'd like to know.
      • Ah... I think I understand what you mean now. The reason that I can't just do

             sub assert_with_comparator {
                 ...
             }

        Is because I need the automatic currying behaviour, which comes from $^comparator, $^a & $^b ($^foo introduces a named currying parameter, in the same way as $^_)

        Maybe

            sub (&comparator, $a, $b) is curried {
                ...
            }

        will become a valid way of declaring a cur