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

1900Re: Re: Perl 5 TNG

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

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

      Actually, there is a CPAN module that allows the users to call DLL
      functions directly. I don't know how versatile it is. The problem is that
      C is very different form Perl - it has pointers, null-terminated strings,
      etc. Creating a completely user-land C -> Perl glue is very hard.

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

      I don't understand you - what's wrong with "," for array concatenation?
      AFAICT @+ will try to sum two arrays element by element.

      I.e:

      @a + @b ===> an error
      @a @+ @b or @a ^+ @b (whatever) ==>
      map { $a[$_] + $b[$_] } (0 .. min($#a,$#b))


      > Regular + or $+ would perform
      > element-by-element additions.
      >

      This will turn Perl into a full-fledged Matlab clone with dollars. ;-) I'd
      rather the operators make some basic type checking and that a regular +
      will not add an entire array.

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

      My problem with this approach is that Perl's data structures are nested
      data-structures and not really tensors like Matlab's. I'd rather make sure
      an API that supports tensors has a good foundation (i.e: enough operators
      or it can define new ones), than start doing an element by element
      addition of a perl data structure.

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

      A ha. Well, a rose by any other names will smell just as sweet. However, I
      usually prefer names that are meaningful, traditional, and assuming it is
      a commonly used idiom - not too long.

      Regards,

      Shlomi Fish

      > --- 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
      >
      >
      >
      > To unsubscribe from this group, send an email to:
      > hackers-il-unsubscribe@egroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >



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