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

1892Re: [hackers-il] Perl 5 TNG

Expand Messages
  • Omer Zak
    Feb 11, 2002
      On Mon, 11 Feb 2002, Shlomi Fish wrote:

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

      <TONGUE_IN_CHEEK>
      I can just see you (Shlomi) starting a new flavor of Judaism 10 years from
      now. Based upon your usage of Jewish concepts and quotes, you must now be
      "chozer betshuva". And given your suggestions for all kinds of mutinies,
      after few years of immersion in Jewish life, you'll find a new way to
      reform Judaism.
      </TONGUE_IN_CHEEK>

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

      Then, the first priority will be a mechanism for interlingual binding.
      Something like what they claim that MS .NET claims to support.
      Such a mechanism had better be able to figure out how to call a C++
      procedure just by reading the corresponding header file.

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

      Then, go for $+ (for generalized scalar additions)!
      Array additions can be @+.

      You are building your own variant of Perl, no need to be compatible. At
      worst, develop a script which will translate Perl 5 TNG into standard Perl
      5.

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

      I don't think that it is a bad idea to associate objects with files. Java
      does the same, too. But the idea of on_destroy() is cool. Of course, it
      works cleanly only with automatic variables. With dynamically allocated
      variables (especially in garbage collected environments), destructors are
      awkward - you can't be sure when does the object really get destroyed
      (unless you invoke do_garbage_collection_now()).

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

      I love this idea. How about a gypsum() operator, which freezes a variable
      to the type which it has when operated upon by gypsum()? It would be good
      idea also in other dynamically typed languages. This is the perfect
      trade-off between not wasting time on unessentials like declaring variable
      types when prototyping things, and making software crash-proof when it
      goes out of prototyping and gets feature-stable.

      --- Omer
      There is no IGLU Cabal. Ask my neighbor over there about IGLU Cabal TNG.
      WARNING TO SPAMMERS: see at http://www.zak.co.il/spamwarning.html
    • Show all 14 messages in this topic