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 ]

· use.perl.org
· Perl
· Dan
· Parrot questions
· More on Perl 6
· Also by pudge

Ask Perl 6

posted by pudge on 2002.05.13 9:19   Printer-friendly
Perl 6
Dan writes "It's time to pose your questions about Perl 6 to our crack Perl 6 design team. The ten highest-moderated questions will be passed on to Damian Conway, Larry Wall, and a cast of several for answering. The questions will be gathered up Thursday afternoon, with the answers scheduled for posting on Monday, May 20th." Remember, Perl 6 is not Parrot, so if you have Parrot questions, hold on to them for the next time.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Ask Perl 6 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Extensions (Score:3, Interesting)

    by djberg96 (2603) on 2002.05.13 10:30 (#8297) Journal
    How will writing C extensions in Perl 6 compare to Perl 5 (XS)? Will it be easier?
      • Hmmm...so, what you're saying is that Perl 6 extensions will depend on the Parrot implementation? Ok - I guess I'm a little confused where one starts and the other ends, then.
              • That sounds pretty bare-metal to me. Maybe the Parrot guys design this layer and then the Perl 6 designers add something on top?

                It's possible to build "plain" Perl 5 modules too, but who would want to? XS exists to make programming Perl 5 modules in C easier. Is there good reason to think that Perl 6 won't need something similar?

                -sam

                • Re:Extensions (Score:2, Interesting)

                  by Elian (119)
                  XS exists because programming perl 5 modules in C is so hard. Programming bare against Parrot will be easier than programming with XS.

                  Don't forget that the same standard also needs to be there for any other language hosted on Parrot--a C extension should look the same for Perl as it does for Ruby, Python, Scheme, or BASIC. That puts the responsibility of how it looks and works on the shoulders of the Parrot folks, not the Perl language design folks.

                    • Re:Extensions (Score:2, Interesting)

                      by Elian (119)
                      Yup, no specs yet. High up on the biggish todo list, if only because I need to speak about them at TPC. :)

                      Should have a preliminary spec within a week, I think.

  • Objects, context, et al (Score:3, Interesting)

    by djberg96 (2603) on 2002.05.13 12:01 (#8305) Journal
    Ok - new question

    Given this:

    my $obj = SomeObject->new;
    Will Perl 6 allow a programmer to distinguish between these within method1 somehow?
    my $val = $obj->method1; # want_scalar
    my @val = $obj->method1; # want_array
    my %val = $obj->method1; # want_hash

    my $val2 = [];
    my $val3 = {};

    $val2 = $obj->method1; # want_anon_array
    $val3 = $obj->method1; # want_anon_hash
    Along those lines, will there be better support for method chaining, along the lines of Robin Houston's 'Want' module?
    my $val = $obj->method1->method2; # want_object
    In the above example, method1 would return a reference to $self, while method2 would return a value.

    Again, along the same lines, will methods modify a receiver in place by default or not?

      • Well, I knew the answer to part of my own question, but I wasn't sure about the hash ref or array ref context. I included everything for completeness (and for the benefit of others).

  • Extensions - rephrased (Score:3, Interesting)

    by djberg96 (2603) on 2002.05.13 13:22 (#8312) Journal
    Will I be able to interface to external libraries without all this XS/extension stuff?

  • The (true) comment is often made about Perl 5, "Only Perl can parse Perl". It appears Perl 6 will also have many nice DWIM-y features, some of which depend on interpreting input flexibly. I like that a lot, but I also wonder how much weight is being given to making Perl 6 easy to parse; without resorting to tightly coupling the scanner and parser, for example.

    • Very little as far as I can tell! I think working too hard in this direction would very quickly run up against the "let Perl stay Perl dictum." The stuff that's generally the hardest for the non-perl parser I use (Emacs cperl-mode) - regexes, quote operators and here docs - don't appear to be changing much at all.

      -sam

      • Funny, none of that stuff breaks it for
        me. Hashes (esp. nsted anonymous hashes),
        blocks, and gratutitous use of block forms
        of grep, map, and eval do cause it to croak though.
        --
        Were that I say, pancakes?
  • Some core functionality of Perl is OS related. alarm, fork, flock, signal handlers etc.
    i.e. with Perl 5, they aren't fully implemented on the Win32 platform. It is argued that this is because of insufficiencies in the OS, but they are part of the language, and I'd argue that they should work as much as possible on all platforms.

    With Perl 6, will these be natively implemented within the language (e.g. within the capabilities of Parrot I suppose)? Or would they be transparently wrapped? Or will Win32 etc. users still have to make do with the non- or partially- implemented versions?

    (I'm hoping of course that we will be able to play with the big boys soon!)

    --

    osfameron

  • Is the SIG{__DIE__} and SIG{__WARN__} & eval issue worked out? Or will that whole mechanism be replaced with a try/catch/throw/finally approach?
    • It looks that way; documented in Apocalypse 4. Except that the syntax becomes:
      try {
        ...
        CATCH IOError { ... }
        CATCH { ... }
        POST { ... }
      }
      I was a bit weirded out by the way the scoping worked and the uppercaseness, but it makes sense when you think about it.
      • You can only have one CATCH, but you can use a switch inside it. And LAST is the equivalent of finally:

        try {
          ...
          CATCH {
            when IOError { ... }
            default      { ... }
          }
          LAST { ... }
        }

  • Tainting, Safe compartments, Security (Score:4, Interesting)

    by ziggy (25) on 2002.05.13 17:44 (#8335) Journal
    A few questions, all somewhat interrelated.

    1. What big changes are in store with tainting in Perl6? Will there be new builtins to handle tainting/untainting of data? (And does forceful untainting of data really make sense, anyway?)
    2. Ruby handles tainting by starting a restricted thread (Safe compartment), and allowing the thread to fail if the requested operations would fail. Will the taint model for Perl6 be like the current Perl5 model, something different that we've seen before (like the Ruby hack), or something totally new (with the appropriate amount of backwards-compatibility pixie dust)?
    3. Is Perl6 going to offer "safe compartments" to execute questionable code, or (source|byte) code that came from outside the currently running program? Will modules be loaded in a safe compartment (when desired)?
    4. Is there going to be a point where things like BEGIN blocks can be intercepted before they're executed, or will they continue to be executed prior to "runtime"?
    5. Will there be hooks in Perl6 to adapt/retro-fit a Java-like security model so that foreign source/bytecode can be checked for some measure of safety before it's integrated into the runtime environment?
    • In regard to BEGIN, I hope to see it work something along the lines of:
      my $parrot = Perl.parse_string($code); # returns object of type Parrot
      $parrot.begin; # executes BEGIN blocks
      $parrot.run; # (will execute BEGIN blocks if not already done)
      $parrot.end; # executes END blocks
      # optionally:
      $parrot.store("/tmp/code");
      Of course I'm in no way involved in the design ;-)
  • It may be too late for this, but will there be a Pascal-style "in" operator? It would be nice to be able to do this:

    &some_sub if ("some_string" in @some_array);

    Thanks
    --
    Cameron
  • I'm curious how long a time frame people forsee for Perl 6. I know that any such schedule is probably totally optimistic and guesswork, but it'd be nice to have some idea what the people in the know forsee. When might the Larry's specs be done? When might we start to see early implementations of those specs? When might a release candidate come out? This would be an even more fun process if everybody jotted down their own answers without consulting the others.
    • Larry intends to produce "one Apocalypse for each Chapter [of the camel3]". The average time between Apocalypses has been 3 or 4 months. Let's be kind and cut the length of the Camel from 33 chapters to 20 chapters. Extrapolating that out and you get a finished design somewhere between 2006 and 2008.

      Then we just have to write the parser, and we're all done!

      ;-)

  • Favorite? (Score:3, Interesting)

    by ChrisDolan (2855) on 2002.05.14 1:13 (#8346) Homepage Journal
    To what change are YOU most looking forward?
  • In perl 5, source filters will only work if the modules they apply to are used during the initial startup phase of Perl's execution. If you do a runtime require of a module then its source filters don't get applied. This is somewhat annoying. (And that's putting it mildly; the whole BEGIN/CHECK/INIT cycle only works at perl start time, which makes delayed loading of all sorts of modules impossible.)

    So, assuming perl 6 retains BEGIN/CHECK/INIT and source filters (and I hope it does), will these now work for
  • Is POD still going to be around? Are there any plans to add a javadoc style documentor to perl 6 that can do introspection on your perl modules?

  • Perl design goals (Score:3, Insightful)

    by lini (3154) on 2002.05.16 8:43 (#8467)

    Other than "Do What I Mean", removing the cruftiness from past Perl implementations, and adding new cool stuff, can you describe the basic design goals underlying the design of Perl 6?

    Although the Apocalypses are good at organizing the changes into specific areas, I feel like I'm missing the overall picture -- what objectives are planned for the language redesign of big-P Perl? (as opposed the compiler/virtual machine redesign in small-p perl)

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.