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.
  • The top five things holding me back from using Rakudo for anything but experimental playing with Perl 6 are (in order of imporatance):

    1. lack of lazy evaluation
    2. s/// is not implemented
    3. it cannot be installed ("removing or moving the build tree will cause the binary to stop working")
    4. I cannot easily tell what parts of the spec are implemented and which are not
    5. The REPL has executes every line in its own scope making lexical variables (and therefore the REPL itself) next to useless.

    I may be wrong abou

    • All of these issues are slated to be resolved by the time Rakudo Star is released. Indeed, I expect that all of them except for #4 will be resolved by the September 2009 compiler release.

      #2 can already be done in current versions of Rakudo, just use .subst() instead of s///. The s/// form should be available when we start using the parser in Rakudo, currently planned for December 2009.


      • That makes me happy. It would be nice if there were an article about what is planned to be (or not be, if that is shorter) in Rakudo Star. Of course, it is entirely possible there is already a road map on a public site that I have not seen yet, and there is still a lot of time until Spring.

        I am not worried about the spec (and therefore the implementations) changing or growing; I am worried about how much of what is currently spec'ed will be implemented by the deadline. A Perl 6 implementation that can't

        • I see it as being promised Perl 5, but having to settle for Perl 4.

          Even Perl 5 isn't "finished" though. If the original Perl 5 had been the ultimate destination then everyone would have been sat in the same place for the last 15 years.

          Perhaps it's better to imagine the Perl 6 spec as being analogous to what people might have envisioned for, say, Perl 5.10. The original Perl 5 didn't implement all the features from that "spec" (like given/when, or say), but it was still usable. The Perl 6 spec will inevitably evolve in the same way that the Perl 5 implementation has, and by its very nature a spec is always going to be a step or three ahead of its implementations.

          Whether that leaves Rakudo Star as analogous to Perl 5.0 or to some 5.0 pre-release I don't know. Provided that it's clear enough what Rakudo Star does and does not do then I don't see a problem. The only difference from Perl 5 is the existence of that spec, which just means that we have better fore-knowledge of where we might be going.