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

use Perl Log In

Log In

[ Create a new account ]

Rindolf - A Perl Dialect

posted by pudge on 2002.02.13 14:55   Printer-friendly
Shlomi Fish writes " I started forming the SPEC for Rindolf - a Perl dialect based on Perl 5. I'm doing it because I found most of the suggestions in the Apocalypses and Exegesis either incomprehensible or redundant. I think Perl 5 is all in all a good language that just needs a little cleaning up. Hence: Rindolf."
I consider Perl as a family of languages rather than a single language. Rindolf aims to be another dialect in this language which will be derived from Perl 5, with some influences from other languages, I am familiar with. The architect of Rindolf is me, but I'll accept suggestions and input from other Perl lovers (or haters). If you are interested join the mailing list which I set up.

What is Rindolf? Rindolf to Perl 5 is like Java is to C++, or Arc is to LISP. I.e: not as much a revolution but rather a re-organization of the language to make it cleaner, more consistent and more fun. Which is good because computer languages generally evolve rather than revolve.

Rindolf will not be backward compatible to Perl 5, because I think some of elements of Perl 5 are frustrating and need a little re-thinking and re-designing. I do hope that most Rindolf code will look like Perl 5 code at first glance, and that most Perl 5 scripts and code would be ported to Rindolf pretty easily.

I told Larry Wall and Damian Conway about Rindolf. Damian said he could not help me too much, but that I can go for designing it in any case. Larry suggested that I should propose the changes to the Perl 5 people, and try to get it there first. However, I see Rindolf as a distinct language and quite a leap forward from Perl 5. If the Perl 5 declares it as the next Perl 5 or accept its most important changes, I may stick to Perl 5. Else, Rindolf will stand on its own.

In the rest of this scope I will bring some highlights from the decisions I have made so far, about cleanups and modifications that will be brought by Rindolf. Note that nothing is implemented yet, they are just proposals "on paper". Also, they are subject to change, because I've only been Rindolfing around for a few days.

1. The -> operators and . will remain the same as in Perl 5.

2. Classes will be declared with a class { ... } construct and several can exist in the same module.

3. An on_destroy() primitive that calls a callback when it is garbage collected

4. Globs will be replaced by return values:

my $I = open("<file.txt"); print $I, "Hello there!\n"; close($I);

5. local is gone. Long live my() and our().

6. Distinction between =< and ,. No more possible hashes mishaps.

7. Re-organization features: easier stubs programming, a better garbage collector that can handle circular references, Full Unicode support.

8. A command-line switch that toggles proper tail recursion on and off.

9. Factories: setting the default behaviour of Perl in an Object-Oriented way. You can keep several same settings at the same time, and they will be de-allocated when they go out of scope.

10. Unambiguous "x" operator:

"hello" x 5 ==> ("hello","hello","hello","hello","hello") join("", "hello" x 5) ==> "hellohellohellohellohello" repeat_string("hello", 5) ==> "hellohellohellohellohello"

11. General Depreciation of the scalar() context. scalar(@a) will be replaced by count(@a). Reversing a string will be performed by a function other than reverse().

There are other changes I have in mind which I'm not too sure about. Like being able to define new operators at the code's compile time. Or a "block" structure with which one can define map, sort and friends in user-land. Or a default integrated literate programming Scheme for either TeX/LaTeX or DocBook.

However, I'm also going to consider the overhead of implementing those changes, and make sure the compiler or the back-end would not be too slow that way. Like I said, I think Perl 5 is a great language (probably my favourite for most practical purposes), but I think it could use a little cleaning up and re-organization. So, enter Rindolf...

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.
  • no scalar context, and no local()

    What would you propose as the new idiom for file slurping? (== read an entire small file into a scalar as quickly as possible)

    -matt
    • You could define:

      sub read_entire_file
      {
        my $filename = shift;

        my $f = open(");
        close($f);
        return $text;
      }

      I can put it in a standard module, if that is
      what bothers you.
      • Please preview your comments before submitting them. It appears that there is some text missing... you probably used literal < and > characters rather than &lt; and &gt;, causing use.perl to discard the unknown "tags"? At any rate, it looks as if $text is not assigned at all, the only thing in the parentheses of the open command is one double-quote character.
        --

        -- 
        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.

        • I did preview but perhaps I missed it. I used
          plaintext mode, but apparently I still have to
          use &lt and &gt.

          Sorry.
          • Yes, that's right. That's because even in plain text you can use tags such as bold or italic (or emphasised and strongly emphasised). I suppose the only difference is that returns are replaced with <br> in "Plain Old Text" mode while with "HTML Formatted" you have to do it yourself with <p>...</p>.
            --

            -- 
            Esli epei eto cumprenan, shris soa Sfaha.
            Aettot ibrec epesecoth, spakhea scrifeteis.

      • Re:hmmm.... (Score:2, Insightful)

        I think what bothers people is losing the freedom and ability to do it simply without going to such a function.

        What is the target audience for this new language? Do you expect people to use it instead of Perl 5 or Perl 6? That is, do you expect people to say "I hate typeglobs and scalar context so much that I am willing to use a language that has very little support instead of the very well-supported Perl 5 or Perl 6"? Or do you expect there to be a large developer following for it? Or is this mainly
    • Re:hmmm.... (Score:2, Informative)

      Well, I usually use "read FH, $data, -s FH", which is supposed to be pretty fast. That would work even without local, $/, or scalar vs. list context.

      --

      -- 
      Esli epei eto cumprenan, shris soa Sfaha.
      Aettot ibrec epesecoth, spakhea scrifeteis.

  • I too am not looking forwards to
    several Perl 6 changes, particulary
    the . operator. Nad you rougly had me
    up until #3.

    I don't much care either way for 2 or 3
    (I do little OO).

    I dislike #4, it drastically changes
    the return valuer system in place
    to no good ends. I'll grant typeglobs
    are at best weird, at worst dysfuinctional,
    but there must be a better way than this.

    As somebody else pointed out local serves
    a purpose that neither my nor our can serve.
    That is unless you allow my on special variables.
    --
    Were that I say, pancakes?
    • From `perldoc -f reverse`:

      • In scalar context, concatenates the elements of LIST and returns a string value with all characters in the opposite order.

      .g
    • Quite a long post, I say, but I address every issue in
      a separate post.

      I had a typo regarding => and , (I used = $b) would be an atomic
      key/value pair, and not the same thing as ($a,$b).

      A hash will need to be intialized with
      join(",", /($a => $b)*/) (pardon the notation). I.e:
      saying %myhash = ($a, $b); will generate a compile
      time or run-time error.
      • Please re-submit, this time with preview to make sure nothing is cut off.
        --

        -- 
        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.

    • I don't like "global" special variables one. They
      are a bit hard to understand and can wreak havoc in
      multi-threaded programs. I'd like to thing of a better
      solution that will eliminate most of them, while keeping
      the important ones of $_, $@, @_, etc. in a thread
      safe, possibly lexically-scoped manner.

      At the moment my best solution is Rindolf factories,
      which I probably did not explain too well. Here is
      a snippet of code from my "Ideas" file:

      new();
      $f->set_line_delimiter("\n\n");

      sub myfunc
      {
      • Please re-submit this text; there is something missing. Probably because you used literal less-than signs which were interpreted as beginning an HTML tag.

        At any rate, my $fh = $local_fh->open("open("readline(); looks like seriously wrong syntax to me.
        --

        -- 
        Esli epei eto cumprenan, shris soa Sfaha.
        Aettot ibrec epesecoth, spakhea scrifeteis.

      • I don't like "global" special variables one. They
        are a bit hard to understand and can wreak havoc in
        multi-threaded programs. I'd like to thing of a better
        solution that will eliminate most of them, while keeping
        the important ones of $_, $@, @_, etc. in a thread
        safe, possibly lexically-scoped manner.

        At the moment my best solution is Rindolf factories,
        which I probably did not explain too well. Here is
        a snippet of code from my "Ideas" file:

        <<<
        my $f = Rindolf::Factory->new();
        $f->set_
  • Reservations (Score:4, Interesting)

    by Ovid (2709) on 2002.02.13 19:19 (#4463) Homepage Journal

    Rindolf to Perl 5 is like Java is to C++

    Are you saying that you want to take a Byzantine language and create a dumber, slightly broken implementation? :)

    1. The -> operators and . will remain the same as in Perl 5.

    I like dropping the arrow in favor of the dot. I didn't at first, but I see no reason to raise the barrier of entry to Perl by not using what is almost an industry standard syntax. I can't think of any reason not to switch to the dot as this will help to eliminate one of the most prevalent (and ridiculous) objections about Perl.

    3. An on_destroy() primitive that calls a callback when it is garbage collected

    Well, how is garbage collection going to be handled? Perl's GC is essentially in a random order and this can cause some subtle bugs. I've had database transactions fail to commit because an object containing a reference to the db handle was reaped prior to my committing a transaction (that was using DESTROY as a fallback). Very annoying. You mention later that you want a better garbage collector, so I'm curious to see how you'll do that.

    5. local is gone. Long live my() and our().

    I hope you weren't serious about "long live ... our". I think our was a mistake. Lexically scoped globals? If that doesn't cause the occasional BrainMelt, I don't know what will. "use vars" is better.

    10. Unambiguous "x" operator:

    This is not a serious design issue that would merit the rewrite of a language. It might be an appropriate thing to change (I dunno, I have no problem with how "x" currently works), but it seems a bit trivial in comparison to what else you have here.

    11. General Depreciation of the scalar() context. scalar(@a) will be replaced by count(@a).

    I like scalar context. In fact, I sometimes use it with "x" to assign defaults to a hash:

    my %hash;
    @hash{ @array } = (1) x @array; # :)

    The question that I have to ask is: why is this better than Perl5? Further, the changes in Perl6 are so exciting (well, to me at least), that I think you're better off building on Perl6 than Perl5, if you want to clean things up. I have no problem with anyone coming along trying to create something new, but I want to be sold on why it's better than what we already have. I don't see that here, but I'd like to hear more.

    • There is no reason to prefer a dot over an arrow
      for member accesses, just because it is the
      "industry standard". I think the arrow is a
      cognitively-sound choice, because that's how
      people think about references and data-structures.

      Check the following URL:

      http://groups.yahoo.com/group/hackers-il/message/1878

      for more information
    • I'm not too familiar with our, but I heard it is the same as use vars qw( ... ). In any case, Rindolf will have a similar mechanism to usr vars qw( ... ). I make call it global(@a,$b,%hello), or something else.

      I'll probably keep use vars for compatibility , but it will be depreciated.

  • Are you going to implement all these language changes yourself?

    I'm just wondering, since the Perl5 core isn't that small, and I think it takes quite a while to wrap your head around it in order to be able to make changes.
    --

    -- 
    Esli epei eto cumprenan, shris soa Sfaha.
    Aettot ibrec epesecoth, spakhea scrifeteis.

    • At the moment, I'm not going to implement everything. I'm just going to write and present a SPEC of its changes from Perl 5. After I have a SPEC, I'll see what to do next.

      Making the SPEC is enough hard work as it is because I need to solve the small problems and inconsistencies, and make sure I like it as it is.

      • Best of luck, Shlomi. I'm going the way of Perl 6, but I keep toying with thoughts of "how I would do it." (Zero time to design or implement anything myself. Make that negative time.) Do Rindolf, but do it for yourself. Put what you want in it, and take out what you want. (It's interesting to me to compare the feature set you've chosen with what I would have chosen.)

        Don't let anyone dissuade you, because Rindolf is for you. If you do what you want, you may someday find that people who think like yo

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • No more local? (Score:2, Interesting)

    How do you propose to replace the extremely useful feature of 'local' which allows for changing single elements of hashes or lists only within the current scope. This is very useful in many places, particularly tests:

    e.g.

    my %args = (
      username => 'Foo',
      password => 'Bar',
    }

    {
      local $args{password} = 'Barr'
      # test that login fails
    }

    Tony
  • Personally I dont really think that you have through this very well. To me a number of your points strongly suggest that you havent grokked certain ideas, and that for that reason wish to remove them.

    The two most glaring examples of this are your comments about local() and scalar context.

    local is an absolutely useful feature, (albeit somewhat misnamed) that afaict cant be replaced. Or at least cant be replaced with any degree of elegance without simply renaming the thing.

    Scalar context is through be

    • Me, too. I thought it was a takeoff on Gandalf or something. (Since I haven't read LOTR, I thought it might even be a character.)

      google seems to find only this article and a posting by Shlomi on advogato. Oh, and also someone on the python email lists with an email address of rindolf2@yahoo.com . Same person as Shlomi? If so, I noted another weird intersection of space and time: the same person has posted to mailing lists for the lilypond project, something I'm interested in. (And stayed up hacking

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers