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

use Perl Log In

Log In

[ Create a new account ]

Rindolf Specification 0.1.10 Available

posted by KM on 2002.03.10 11:22   Printer-friendly
Shlomi Fish writes "The Rindolf SPEC version 0.1.10 is available. It is not a stable release but is very much finalized. Since the 'use Perl' feature about it, I got an oppurtunity to rethink, expand, and refactor my original conception. Thus, I believe many people will find the new specification much superior to the one presented in the original post."
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 Ovid (2709) on 2002.03.10 19:21 (#5683) Homepage Journal

    Your specification was very interesting reading. I'll be interested to see what comes of this. However, I do have some problems with what you put together. To quote from the specification:

    However, [Perl 6] also breaks a lot of compatibility and so will be hard to port existing Perl 5 code to. Perl 6 may eventually be a wonderful language. ``But it's not going to be Perl''.

    It seems to me that you are laboring under a misapprehension that many Perl programmers seem to face. You have addressed two issues in the above quote. On the first, regarding portability, you are incorrect. The Perl 6 effort has been started from the beginning with the assumption that migration pains from Perl 5 to Perl 6 be minimized. It is intended that there be a "Perl 5 compatibility mode" that will allow Perl 5 programs to run under Perl 6 with little to no modification. If that's not painless, I don't know what is. However, to truly utilize the full power of Perl 6, you'll have to program in Perl 6. Pick up the latest issue of Sys Admin magazine which has "The Perl Journal" supplement. In there you will find an article by Damian Conway entitled "And Now for Something Completely Similar" (a little tweak at our Python friends :). In this article, Dr. Conway shows just how little is changing in Perl. In fact, aside from small changes to the dot operator, the concatenation operator, and how sigils are used, Perl 6 will be virtually identical to Perl 5.

    So, not only does that address the "porting" issue, but this also addresses the question of whether or not Perl will still be Perl. I have to emphatically say "yes". Since virtually none of the core is changing, with the exception of what many would consider to be cosmetic differences (my ex-wife used to dye her hair - I still recognized her), I think there is really very little question as to whether or not Perl will be Perl.

    If there is any point to be learned from Dr. Conway's article, it's this: Perl 6 has seemed overwhelming to many Perl programmers because the Revelations have focused on the new features of Perl 6. They are, by definition, different features, thus leading many people to have a skewed impression of what's going on. Dr. Conway's article was an attempt to correct this.

    Another quote:

    Subsequent versions of [Rindolf] will integrate programming paradigms only after they were proven as mature, useful and appropriate to its general philosophy.

    I strongly urge you to reconsider this. Think about pseudo-hashes in Perl. The failure of pseudo-hashes is testament to the success of Perl. They were an innovative attempt to solve a very real problem. They were cumbersome, often generated weird error messages, and were later proven (by Michael Schwern, if I recall correctly), to negatively impact the performance of regular arrays and hashes, thereby showing that the performance improvement of pseudo-hashes was illusory. This is called "innovation". If you're not willing to take risks, it's tough to get the rewards. If all attempts at innovation were successful, that means we're being too conservative in our approach. If you continue with Rindolf, don't be afraid to take leaps of faith beyond the initial language concept.

    • I blathered:

      Perl 6 will be virtually identical to Perl 5.

      I should have said "the core of Perl 6...". Needless to say, there are so many new things added to the language that while Perl 6 can look almost identical to Perl 5, to utilize its full power, you'll start using strange and wonderful features that Perl 5 simply doesn't have. It's kind of like the "C-style" Perl. Yes, you write Perl in such a way that it resembles C -- the "C-style" for(;;){} loop being the classic example -- but Perl is much m

    • First of all, the "But, it's not going to be Perl" sentence was meant as a reference to a similar comment made on Fortran 90. I seem to have misplaced the place where I've seen this quote. Anyone to the rescue?

      Now regarding the difference between Rindolf and Perl 6: I'm trying to put stuff in Rindolf, without bloating the language too much, as opposed to Perl 6 which, IMO, seems like the LCM of all computer languages possible.

      What is not in Rindolf is equally important as what is in there.

      The o

      • Two major problems I have with this reply.

        1) Rindolf is based on Perl 5 which is very complicated with everything in it. You complain about being too complicated but that is what you are basing your core around.

        2) Perl 6 on the other hand is taking the opposite approach and making the core language very tiny. It achieves the same as Perl 5 and more, but by doing it all in separate libraries. This is key to Perl 6.
        • Therefore, would it not make more sense to derive Rindolf from Perl 6 (when it becomes available) than to try and retrofit features onto the scary Perl 5 code base? 8)
          • One should distinguish between the Perl 5 language and the perl 5.6.1 codebase. The Rindolf SPEC does not talk about how to internals of the interpreter will look like.

            Rindolf hackers may eventually use Parrot as our back-end. Or the original perl 5 one. But then, I heard good things about the Ruby codebase, so who knows. ;-)

            From what I know, the intention of the perl 5 hackers is to eventually implement it above Parrot, as Parrot is a generic VM which should be suitable for many high-level language

    • A Perl 5 compiler for Perl 6 is a stated goal, and surely is honourable. But it's very unlikely to happen in the real world we work in. At least not in any timely fashion. And it's not going to really be a migration path because it's unlikely to allow you to mix both syntaxes in one file (all it will allow you to do (it seems) is to run old Perl 5 modules in your Perl 6 program, which doesn't seem like much of an incentive to update those modules to Perl 6 modules to me).

      There are lots of issues here being
  • If you want to take part in the Rindolf discussions, then you are welcome to join the Rindolf mailing list []. At the moment, I can use any help and commentary that I can get.

    At the moment, the focus is on designing the language itself, but I do not preclude that developing the interpreter's core will start in the near future.
  • Scalar Context ... (Score:3, Insightful)

    by Desmodromic (2828) on 2002.03.11 13:40 (#5739)
    "I don't like scalar context very much ..."

    Ouch. To my mind, that's like getting in a Porsche and saying, "I don't like manual transmission very much." A valid comment, certainly, but one which begs the response, "well, don't drive a Porsche then."

    I suppose my question is: What's the point here, again? Do we really need a subdialect of Perl that is mostly compatible but does things like deprecates scalar context and makes the 'x' operator unambiguous? It seems like a LOT of work that might be better spent doing some of what programming languages are really meant to do: solving real problems, something that the old context-burdened, ambiguous, lacking Python-like class support Perl has been doing for many moons now.

    I realize there are other new features of Rindolf: expanded class support, file primitives, out-of-scope callbacks, etc. But after six years of using Perl and two years of Python, and in light of all the Perl and Perl-like development going on in the world, I can't help but think of this as just a vanity project.