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 about some or all of these because I only stop to look at Perl 6 about once a month or so. The next to last one is probably my fault for not looking in the right place.

    • 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

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

          We worked on this at YAPC::EU in Lisbon, I'm currently in the process of writing it up to be somewhat coherent and understandable. Stay tuned.

          A Perl 6 implementation that can't do what the spec says is Perl 6 doesn't seem to be a real release to me.

          The whole point of Rakudo Star is to say "this isn't all of Perl 6". Anyone that gets Rakudo Star and expects all of Perl 6 to be implemente

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

          Patrick and I discussed this at OSCON. Our rough plan is that I'm going to be helping track and communicate what is in Rakudo Star, and what isn't, and how close we are to having those things ready to go.



        • 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

    • Actually, what I want from Rakudo right now is just more speed (like 10-100x the speed it is now) so I can run it and crash it faster/more often :-). I guess to be comparable to Perl5 we need like 1000x times the current speed, but I'm willing to settle for less.