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.
  • I didn't reply before because I didn't have to contribute what you're looking for, but I was pointed at this again today and you've only got one reply... so... here goes.

    The Exegesis and so on are pretty good. It's hard to say how complete they are until people have been using an implementation of it for a while. That's the nature of the beast. You don't know how much further until you get there, and in this case, that's a function of observing people use what you've made for a while.

    The (I forgot what i

    • Now let's talk about Rakudo. [...] If you have a language, such as BCPL, you change the parser to accept your new language, such as B. Then you slowly start changing the source code of the BCPL compiler to include B as its deemed safe.

      If this is the approach you advocate, then your comment is more properly a criticism of Perl 6, not of Rakudo. I'll note that when Larry wrote his parser for Perl 6, he didn't start by modifying an existing one either. I suspect that's because there weren't any parsers in

      • I'm kind of sad to see you reply. I like to think that my kind of prattling on is completely off the radar of the people actually doing the work.

        It's true that Perl 1 kind of came out of no-where. I don't know the early-early history here. Did Larry peek at awk's grammar and copy bits from it? I don't know.

        I also know the Perl 5 parser is a bit horrifying and the muckiness of all of that is a lot of the catalyst for Perl 6, but, in theory, one approach to writing a Perl 6 grammar would be to hack up Perl 5. I'm not exactly advocating that. I'd be very pleased if that approach were feasible though. In my perfect world, Perl 5 is written in Perl 5 and has several good backends, sort of like HaXe does, and how pugs is trying to, but also like LLVM does. That is, backends targeting JavaScript, the JVM, x86 ABI, etc, etc.

        I accidentally over-polarized the matter. The language written in itself is an ideal. It's not all or nothing -- just one pole. Writing the VM from scratch, programming an intermediate language in that assembly, writing another language in that language, etc, is the opposite pole. And that's the point I should have tried to make. And that's not a criticism of Perl 6 so much as of Parrot, at least in my mind. Pugs leverages other tools and had the goal of bootstrapping first then re-writing the language in itself, similar to the process by which B became C (but obviously not identical). So, according to this one criteria, it's possible to do better. That's not to say that there aren't other criteria and other ideals.

        Hmm. While I have your attention, how closely is Raduko tied to PIL? I'm unclear on some of this -- there's an "not quite Perl 6" language written in PIL, and Raduko is written in that? I'm wondering how feasible it would be to target another platform for Raduko...


        • I think you overestimate the difficulty of writing a parser for a language and greatly underestimate the difficulty of equipping a two-decades-old runtime with evaluation semantics like laziness that it was never designed for. The BCPLBC example is somewhat of a red herring in this because all of the languages are in the “portable assembly” class largely defined by ALGOL, without significant differences in evaluation semantics or memory model.

          I made a very small proposal for 5.12 and it took a []

          • I'm confused. I said that the ideal case of morphing one language into another did not apply to Perl 5 and acknowledged that one of the primary reasons for a rewrite was the Perl 5 core.

            Can you double check that I said what you thought I did?