Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • by Damian (784) on 2002.06.04 18:27 (#9130)
    24 pages? It's only that long because the "pages" on are so very much shorter than they've ever been before. Perhaps you're responding to user requests for that or trying to distribute your server load differently? But the implication that Apocalypse 5 is unprecedentedly huge is just plain wrong: in line count A5 is within a few percent of A4.

    As for breaking expectations...we sure did! Assuming people expected regexes to continue to be an ad hoc accretion of vaguely incompatible syntaxes, obscure stand-alone features, and special cases. ;-)

    I mean, did people really expect Larry wouldn't take this unique opportunity to drag Perl regexes completely free from the syntactic and semantic mire into which they've slowly been sinking?

    Apocalypse 5 is Perl 6 in microcosm: throwing away the prototype and using the lessons learned to design a system that's integrated, rather than aggregated.

    Of course, there will almost certainly be issues and problems we've overlooked. That's why we'll be relying so heavily on the community's constructive feedback over the next few weeks. But fear, uncertainty, doubt, and xenophobia aren't likely to be helpful in that regard.
    • 24 pages? It's only that long because the "pages" on are so very much shorter than they've ever been before.

      I do wish they had a "printable version" link that'd dump the whole thing as simple HTML all on a single page. But [] works.

    • But the implication that Apocalypse 5 is unprecedentedly huge is just plain wrong: in line count A5 is within a few percent of A4.

      % wc -l a4.pod a5.pod
      2175 a4.pod
      2811 a5.pod

      In word count, about 30% more. In byte code, about 40% more. And A4 wasn't small. Still, it depends on your definition of "a few"...

      • In my view, line counts on marked-up source aren't particularly meaningful. I was reckoning by the counts on the visible text itself:

        % lynx -dump '' > a5.txt
        % lynx -dump '' > a4.txt
        % wc a[45].txt
        2518 16682 104463 a4.txt
        2768 18534 119403 a5.txt

        So in terms of readable content, A5 is 10% bigger by lines, 11% bigger by words, and 14% bigger by bytes. No big deal.
  • by autarch (914) on 2002.06.04 18:42 (#9132) Homepage Journal
    I hope it does not escape people that an awful lot of the syntax looks like something from Parse::RecDescent. Coincidence? I think not!

    Seriously, it all looks very cool. Simple regexes remain simple, while grammars becomes possible. I like it.
  • First Reaction (Score:3, Insightful)

    by samtregar (2699) on 2002.06.04 19:06 (#9133) Homepage Journal
    Nirvana! Parse::RecDescent is dead and re-born in a new and glorious form. For the first time I'm actually anxious to use Perl 6.

    Sure, all the changes will take time to get used to. But the result will be both cleaner and more powerful than what we have now.


      • Re:First Reaction (Score:4, Interesting)

        by Damian (784) on 2002.06.06 2:33 (#9242)
        Actually, having seen A5, you've seen the first draft of the new Parse::FastDescent syntax! Of course, P::FD will provide a large number of additional assertions (replicating P::RD's numerous handy directives), but the syntax and semantics will almost certainly be as close to A5 as possible.

        That way, P::FD can continue P::RD's role as a test-bed for Perl 6 regex/grammar features, as well as providing a migration path from Perl 5 to Perl 6.
          • I certainly hope backward compatibility is not completely lost...

            I'm afraid so.

            ...or at least we're given a way to port P::RD grammars to P::FD semi-automatically.

            Yes. One of the big tests of P::FD is whether I can build a P::RD metagrammar with it.

  • Does anyone see this as potentially confusing given...

    apo4 wrote:
    > An ordinary flattening list assignment:
    > @a = (@b, @c);
    > is equivalent to:
    > *@a := (@b, @c);
    > That's not the same as
    > @a := *(@b, @c);

    I mean, we've got := meaning something outside of regexen and something else (it means =) inside regexen.

    Are there ever going to be cases where one might want to use := (in the apo4 non-regex sense) inside of a regex?

    If so, how would it be typed? As ::= perha
    • I mean, we've got := meaning something outside of regexen and something else (it means =) inside regexen.

      No, it doen't. It means "bind", exactly as it does outside a regex. And what it binds in a regex is a hypothetical variable to a captured value.
  • Regexp objects (Score:3, Interesting)

    by Matts (1087) on 2002.06.05 11:12 (#9179) Journal
    There seems to be no indication of how regexps will behave as first class objects. I'm hoping for something akin to either Ruby or Python's Regexp objects. I think it's as good a time as any to kill regexps built using a custom quote-like operator.
  • I'd just like to say three things:

    1. This is a wonderful Apocalypse. Probably the best so far. Comprehensible, clearly makes things simpler, yet more powerful. And guaranteed to rile some people. Probably quite a few.
    2. Kudos to Damian and Larry --- reading the Apocalypse, it's hard to see where one man's ideas begin and another's end. An elegant synthesis.
    3. I'm just happy I'm not Mr Friedl [], particularly since the new edition [] is coming out quite soon. [I was going to ask when a new edition was coming out
      ---ict / Spoon
  • yummy! (Score:2, Informative)

    mkay, just finished reading...

    My questions/comments above do not reflect my overall
    opinion. They're really just things I didn't get and a
    nit pick or two.

    Overall, although my brain is dripping a bit from one
    ear, I quite like perl6-flavoured regexen :)

    I think I need to watch some mind-numbing TV though...
    my head hurts a wee bit :)


    • Re:Oh shee-it (Score:3, Interesting)

      I like A5, but it is dramatic. It will piss off alot of hum-buggers.

      You really think so? I can't think of any significant way in which Larry's proposal isn't a vast improvement on what we have now: more readable, more consistent, better optimized for the common cases, more powerful. What do you think they'll object to? (That's not a rhetorical question: I'd really like to know.)

      Mostly, it makes me wonder how long it will take to build perl6. Much of my apprehension is allieviated by the thought that pe
      • Re:Oh shee-it (Score:3, Interesting)

        Well, if I were inclined to object, I would object about the fact that it is too different. I don't, in general, like different.

        OK, that's an oversimplification, but I just woke up. In any event, though, I am far more interested in the Perl syntax than the Perl regex syntax. My primary concern with regexes is the learning curve and speed of execution. It's a very dissimilar situation to Perl syntax itself, to my mind: I mean, how many people are really in love with Perl regex syntax, really?
        • Yeah... character classes were also number one on my list of "things that I'll miss knowing how to do in Perl6".

          I know they'll still be there, but the syntax will be different -- and pretty much all other regex languages will still allow [aeiou], only Perl6 will require <[aeiou]> (or perhaps <vowel>?). So I won't be able to carry over my knowledge directly.

          Esli epei eto cumprenan, shris soa Sfaha.
          Aettot ibrec epesecoth, spakhea scrifeteis.

    • As Larry says in the 'poco', /x is the default, meaning you can have inline comments like this:

          / x is the default # so this is a comment
              and this is not a comment /

      At least that's what I remember from yesterday. I wish was up so I could confirm that ;)
        • Well, I checked again and you're wrong.

          Go to page 6 [] and look at the table at the bottom.

          The very first example shows an inline comment.
            • Oops, I didn't read wickline's message carefully enough. I missed the part about not wanting to break the regex into two lines.

              Geez, what a weird nitpick though. I agree that telling people to use inline strings is potentially a problem, but why would you insist on single-line regexes?

              Do you try to keep all of you other code on one line too? ;)
    • So, given that almost all the example patterns use /foo/ and not m/foo/, what is
      happening, and when is it happening?

      /.../ now *always* returns a regex object.
      But a regex object in a void, boolean, string, numeric, or =~ context
      immediately matches against the current topic.

      So you get:

          /pattern/;                 # void context    -> automatch
          if /pattern/ {...}         # boolean context -> au

    • By the time you get into a regex, you're always
      dealing with $_.  Even =~ behaves as a topicalizer
      for its right side.  So, while the $_ inside a
      closure is the search state object, it's always
      related intimately to the outer $_, which is always
      an alias for whatever you're currently searching.
      Any string operations on the inner $_ should be
      delegated to the original string.  Providing an
      explicit method to get at that string should be a
      no-brainer, though if you mess with the string,
      there's no guaran
      • In general, when matching against backreferences, you want to match it literally, not as if it were regex. So you wouldn't want the angles.