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.
  • 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 existence that could be reasonably modified to parse Perl 6, which was effectively the state of things when Rakudo started.

      It was in exactly this way that C was created from B as well as B from BCPL.

      This is more properly a criticism of Perl 6 design, not of Rakudo's implementation of it.

      gimmie5 effectively fits this BCPL->B->C model, but the waters are muddled a bit by Perl 5 not being self hosting.

      Actually, gimme5 doesn't really fit the model you describe, because it doesn't start by modifying an existing parser or language. gimme5 is, in fact, a completely new parser built on top of an existing language. This is exactly the same approach that PGE and Rakudo have taken except that PGE was created using PIR instead of Perl 5. (And the decision to write PGE in PIR was based in large part on the advice of very wise, knowledgeable, and experienced language designers who recommended not attempting to use what had already been done in Perl 5.)

      Ultimately, if you want to promote the BCPL->B->C model of language development, that's fine, but I think the language you end up with by using that model isn't going to be Perl 6.

      Pm

      • 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 Per

        • 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 [perl.org]

          • 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?

            -scott