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

1897Re: [hackers-il] Re: Perl 5 TNG

Expand Messages
  • Omer Zak
    Feb 11, 2002
    • 0 Attachment
      On Tue, 12 Feb 2002, Shlomi Fish wrote:

      > > 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.
      > >
      >
      > Parrot (http://www.parrotcode.org/) will have a common way to define
      > bindings to it. That does not mean those bindings will be suitable or
      > well-formed for any language front-end implemented above it, but they will
      > be usable. Assuming Perl 5 TNG will use Parrot (which I don't see a reason
      > why it should not), It will enjoy this binding stuff.

      But will this mechanism be friendly to users?
      Suppose I find that COOL library, and it has only C language bindings (in
      the form of header files). How can I bind to it from my new Perl 5 TNG
      scripts without doing things more complicated than writing declarations
      like:

      foreignlibrary "/usr/include/coollibrary/CoolLibrary.h";

      > That's not what I aim for. No, I don't want P5TNG to be fully compatible
      > with Perl 5, but I do want it to look and behave much the same. Naturally,
      > assuming it will have bulk operations on arrays, than if $+ is for string
      > concatenation, and @+ is for array addition, the array string concation
      > should be something like @$+. According to the apocalypses array stuffs
      > are no ^+, ^^+, etc, but I can specify that they are @+ if I want.

      The meaning of regular '+' is that if it is given string arguments, it
      tries to convert them into integers and then sum them. $+ would convert
      any integers into strings before addition. For example:

      1 + 1 == 2
      1 $+ 1 == "11"
      "1" + "2" == 3
      "1" $+ "2" == "12"

      @+ would, similarly, convert its arguments into arrays (if necessary)
      before concatenating them. Regular + or $+ would perform
      element-by-element additions.

      > Another issue is accumolators. If anybody is familiar with matlab, he
      > knows that sum, max, min and other accumolators operate on one dimension
      > of a tensor. Should we have sum($my_tensor, 2) to sum its second
      > dimension? As you know a multi-dim array in perl may be something like:
      >
      > [ [1,2,3,4,5,6], [3,4,5], [2,9], [1,2,3,4,5] ]
      >
      > I.e: not of the same length. I'm not sure I'd like to put PDL right in the
      > core language.

      Yes, use sum(@my_tensor,2) and the like. For any missing elements (due to
      short rows), substitute the null value and use whatever value defined for
      addition of null values.

      Also, generalize the notation (I don't have a suggestion at the moment) to
      other operators, which can be applied to tensor elements.

      > > > 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.
      > >
      >
      > Sounds nice. Actually, I decided that statically-typed variables are not a
      > top priority, but I'll keep this gypsum idea in mind. But why not call it
      > freeze_type() ?

      Due to the same reason people grep strings, rather than search_matches
      strings. Use "unexpected" words, to spice up the language.
      --- Omer
      There is no IGLU Cabal. This has been a goal not worth pursuing.
      WARNING TO SPAMMERS: see at http://www.zak.co.il/spamwarning.html
    • Show all 14 messages in this topic