Loading ...
Sorry, an error occurred while loading the content.

1878Perl 5 TNG

Expand Messages
  • Shlomi Fish
    Feb 11, 2002
    • 0 Attachment
      Yet another mutiny, but rather language fork that I start. Forgot to
      mention proper Garbage Collection and proper tail recursion (in the nice
      to haves), but I'll fix it.

      Regards,

      Shlomi Fish



      I asked my good friend and fellow Linuxer Mulix if he reads
      the Apocalypses and Exegesis of Perl 6. He said he does but
      he do not understand them. Strangely enough, I realized that
      I don't understand everything there anything. Apocalypse 4
      was the worst - so many constructs which I could not understand
      or care for too much.

      I believe most good languages in use today were based on a previous
      language: BCPL begot B which begot C which begot ANSI C which begot C++
      which begot Standard C++. LISP and ALGOL and Lambda Calculus begot Scheme.
      Pascal was based on ALGOL, too. Python was intended as a better Perl, and
      Ruby was derived from Python, Perl and Ruby. Likewise, Perl 1 was based
      on C, Sed, Awk and Shell. The other perls were based on the others until
      Perl 5 came out.

      Now there's Perl 6 which aims to be derived on Perl 5, but also on over
      300 RFCes which suggest every feature imaginable or existent today. From
      what I read until now, Perl 6 would be to Common Lisp what Common Lisp is
      to Scheme. I.e: a complex, complexifiying and complexifiyied language. There
      is a saying in Hebrew: "Tafastha Merube Lo Tafastha", which means : "If you
      try to catch a lot you catch nothing at all".

      There are many possible features which can be thrown into Perl, but Perl
      has its particular niche, and cannot be expected to be the best language
      in all cases. To quote Chen Shapira: "How can one expect to be a
      programming language that will be suitable in all cases, if people
      can't even make such a screwdriver". All the other languages I know fail
      in some cases, and cannot be expected to be useful for 100% of the problems.
      I don't think the next version of Perl should be the same.

      Luckily, being an Objectivist and a Jew, I tend to be an individualist and
      doubt the external authority of anyone, including language designers. I decided
      to start a mutiny, and start to design a language dubbed "Perl 5 TNG"
      (short for "The Next Generation") which will:

      1. Be based on Perl 5 with a few cleanups.
      2. Be a better Perl.
      3. Not be much bloated than Perl 5.x.

      I do not claim to be familiar or expert with half the computer languages (much
      less half the human languages) that Larry Wall is, but I do know quite a few.
      (look at my resume). Therefore, I think I know where perl 5 is flawed, and
      what needs to be done to fix it.

      Here goes:

      1. The -> operator and the . operator will remain the same.

      "." may be the industry standard in Java, Python, etc., but I believe -> as
      an accessor is more cognitively sound. I.e: it make you realize that the left
      hand side is a reference (or pointer in some languages terminology). It very
      shape makes it so.

      "." may be a strange choice for string concatenation, but "_" is worse, since
      it can be part of an identifier. My personal favourite for a string
      concatenation operator is "$+", which I think is a special variable in perl 5.
      I suggest we stick to ".", because it's as good a choice as any.

      2. Several Objects in the same file:

      Associating Objects with modules was a bad idea. I plan Perl 5 to have
      a fully non-magical object system, which one can implement in user-land. (CLOS
      anyone?). The only "magical" element would be a special function named
      "on_destroy" (name can be negotiable) that will accept a reference to a
      function and return a special reference that will call it when it gets
      out of scope. E.g:

      sub hello
      {
      my $num = 100;
      my $p = sub {
      for(my $i=0;$i<$num;$i++)
      {
      print "Hello\n";
      }
      };

      my $destructor = on_destroy($p);
      $num = 5;
      }

      Will print "Hello" 5 times. on_destory() will be used for implementing class
      destructors.

      Perl 5 TNG will have a default object system, so the situation of Scheme where
      there are several proprietary and non-compatible ones will not repeat
      themselves. Nevertheless, the user will be able to hack something on his own,
      in case he does not like it too much.

      3. In file namespaces.

      I suggest adding a "namespace mynamespace { ... }" or similar construct to perl
      or to be able to define "sub Hello::World{ ... }" whereever. It will
      make symbol lookup a bit harder, but will be able to create scripts that
      are self contained.

      4. Globs are dead. Don't miss them. Don't miss them.

      The new syntax for open would be "my $I = open("<file.txt");". and of course,
      "print {$I} "Hello there!\n"." It would be nice if people won't type
      "print $I;" and get an ugly reference dump on the screen. Perhaps, file handles
      can be magical objects that will throw an exception if printed.

      5. local is gone.

      Long live my() and our()! Enough said?

      6. Distinction between => and ,

      At the moment creating hashes is bug prone, because => and , are exactly
      the same thing. I suggest to distinct them and use => for a key+value atom.

      7. Better and easier Bindings language and integration glue.

      Parrot is probably going to be a solution, assuming it is designed right. I
      don't mind it being the back-end of Perl 5 TNG, since it aims to be such a
      back-end.

      ---------

      Then there are nice to have things, which I don't need but may like:

      1. Binding a variable to a type.

      Perl is a dynamically typed language, but obviously some people will find
      it nice if it will behave somewhat statically-typed sometimes. This will
      be a problem with having more than one such type in a combined expression:
      "$myint + $mystring" or "$myint . $mystring".

      2. Defining new infix/prefix/suffix operators a la Haskell.

      Will make parsing much harder, but would be a very cool feature. Can be
      used to rationalize bulk operations on array. I.e: "@c = @a @+ @b;" would
      be just syntactic sugar to:

      <<<
      @c = (map { $a[$_] + $b[$_] } (0 .. min($#a,$#b)))
      >>>

      It may be optimized for further speed.

      3. Bulk operations on arrays:

      Due to the fact that I'm an Electrical Engineering student, I know that
      Matlab contains an inflation of operators to work with matrixes and tensors.
      I'm not seeing Perl replacing Matlab as far as Engineers are concerned (at
      least not until PDL becomes mature enough). Then there's APL, which I'm not
      familiar with but whose programs look like operator line noise. (Matlab is
      actually quite readable, usually)

      Do we need Matrix multiplication? (not just @@*) Or a sin/tan/log function
      that will take all the values of a tensor that is passed to it at once?
      The user may actually pass it as an accident. One can distinguish it with @^sin
      or @^^log of course.

      If you want PDL like functionality to be an integral part of Perl 5 TNG and
      its syntax, go for it. I on my part am neutral, because I like to use Matlab
      were appropriate and Perl were it is.

      ---------------

      Do you know of any other urgent problems in Perl 5 that need to be addressed
      in Perl 5 TNG? If so let me know.

      But I don't want it to be a catch all (= catch none - ;-)) language that
      Perl 6 seems to be. If I don't understand those features now that I read
      them, how can I understand them when I have to comprehend other people's
      code?

      The philosophy of Perl 5 TNG is to take Perl 5 and clean it up so it will
      be more consistent, trustworthy and usable. I don't want it to be a language
      that will integrate all possible features from every other language
      in the world.

      Like I said, languages should evolve, rather than revolve. Obviously, in
      one day, someone may find some other features that need to be addressed
      in Perl 5 TNG. At which point I or whoever make choose to make a language
      that is derived from it. But Perl 6 will have too many features that I find
      redundant and don't need.

      Yes, Haskell's lazy lists are cool ([(i*i) | i <- [0 .. ]] anyone?), but
      I could live without them anyday. I'd rather have Perl without lazy evaluation
      than Perl with lazy lists. And naturally, most of the other suggestions that
      Larry put in Perl fall into that decision too.

      Regards and think about it,

      Shlomi Fish

      "All language designers are arrogant. Comes with the territory".

      Larry Wall





      ----------------------------------------------------------------------
      Shlomi Fish shlomif@...
      Home Page: http://t2.technion.ac.il/~shlomif/
      Home E-mail: shlomif@...

      "Let's suppose you have a table with 2^n cups..."
      "Wait a second - is n a natural number?"
    • Show all 14 messages in this topic