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.
Re:Extensions
Elian on 2002-05-13T15:41:26
FWIW, this falls in the realm of "Parrot Questions" rather than "Perl 6 Questions" since you used the magic "C" word.Re:Extensions
djberg96 on 2002-05-13T16:52:55
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.Re:Extensions
Elian on 2002-05-13T17:22:11
Perl 6 extensions in C will depends on the Parrot implementation the same way that perl 5 extensions rely on the perl 5 engine.
Now, if you'd asked "Will I be able to do Inline::C type things in Perl 6 to write C extensions", or "Will I be able to interface to external libraries without all this XS/extension nonsense, then that'd be different. (Which are, themselves, interesting questions)Re:Extensions
samtregar on 2002-05-13T19:02:33
I think I disagree, unless you think that the Parrot team will be designing the new version of XS. To my mind XS is basically a programming language unto itself, and one that is sorely in need of redesign, not just reimplementation.I think it needs to be addressed in the Perl 6 design and not just left to the geeks in the trenches.
-sam
Re:Extensions
samtregar on 2002-05-13T19:03:47
Ugh. PerlMonks has made me soft. I fully expected to be able to continue editing my grammar after clicking [submit]. Oh well.-sam
Re:Extensions
Elian on 2002-05-13T19:08:35
The Parrot team will be designing the new version of XS. It's got to--it is, for all intents and purposes, Parrot's API to the outside world, and thus not really a Perl-6-the-language issue.Re:Extensions
samtregar on 2002-05-13T19:10:30
That's strange - Perl5's API is distinct from XS. Is the XS layer going away?-sam
Re:Extensions
Elian on 2002-05-13T19:14:34
Oh, you're talking about the CODE:/PPCODE:/MODULE stuff? Yeah, that's all going. Parrot extensions will be plain with at best some metainformation in a separate file to drive the linking and possibly the yanking in or autogeneration of some default routines.Re:Extensions
samtregar on 2002-05-13T19:19:34
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
Elian on 2002-05-13T19:25:42
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
samtregar on 2002-05-13T19:31:54
XS exists because programming perl 5 modules in C is so hard. Programming bare against Parrot will be easier than programming with XS.Is there a design spec that can back up this statement? I've heard this said before but I fear that simply wishing won't make it so. In particular, I wonder if the register architecture will be difficult to manipulate at a low level. Stack machines have their faults but they do generally win in accessibility.
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.Color me unconvinced. Perl extenstions typically deal quite closely with Perl data structures and builtin functionality. Much of this will, by its very nature, not be available in other Parrot run-times.
-sam
Re:Extensions
Elian on 2002-05-13T19:37:36
Extensions won't be touching the registers. In general, extensions won't have any knowledge of the workings of the interpreter, since we might, and probably will, at some point do a good-sized reworking of the internals.
As for perl special stuff at the XS level... there isn't much. In fact, there's almost nothing at all. (I'd say nothing, as I can't think of anything perl specific, but there may be something small that I'm missing) Variables, stashes, calling conventions, methods, and all that stuff are language independent.
The differences between the languages are almost entirely syntactic. Semantically, they're darned close to equivalent.Re:Extensions
samtregar on 2002-05-13T20:04:34
So they aren't any specs on this yet, right? Ok. I'll reserve my judgement for a later date.-sam
Re:Extensions
Elian on 2002-05-13T20:10:12
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.
Given this:
Will Perl 6 allow a programmer to distinguish between these within method1 somehow?my $obj = SomeObject->new;
Along those lines, will there be better support for method chaining, along the lines of Robin Houston's 'Want' module?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
In the above example, method1 would return a reference to $self, while method2 would return a value.my $val = $obj->method1->method2; # want_object
Again, along the same lines, will methods modify a receiver in place by default or not?
Re:Objects, context, et al
Trey on 2002-05-13T18:09:06
There is a generalizedwantsbuiltin that will do this.Re:Objects, context, et al
djberg96 on 2002-05-13T18:20:33
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).
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.
Re:Ease of parsing Perl 6
samtregar on 2002-05-13T19:07:14
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
Re:Ease of parsing Perl 6
belg4mit on 2002-05-13T19:11:33
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.Re:Ease of parsing Perl 6
samtregar on 2002-05-13T19:21:58
Well, I don't do too much of that stuff! But it seems like every time I use a here-doc I end up having to reinitialize cperl-mode to get the right colorization...-sam
Re:Ease of parsing Perl 6
torin on 2002-05-14T16:36:00
If you touch a here doc, just doM-x cperl-find-pods-heres<CR>
alarm, fork, flock,
signal handlers etc.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!)
Re:signals, eval, exceptions
pdcawley on 2002-05-13T21:08:04
It looks that way; documented in Apocalypse 4. Except that the syntax becomes:I was a bit weirded out by the way the scoping worked and the uppercaseness, but it makes sense when you think about it.try {
...
CATCH IOError {... }
CATCH {... }
POST {... }
}
Re:signals, eval, exceptions
TimToady on 2002-05-15T18:57:41
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 {... }
}
Re:Tainting, Safe compartments, Security
Matts on 2002-05-14T07:39:44
In regard to BEGIN, I hope to see it work something along the lines of:Of course I'm in no way involved in the designmy $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");;-) Re:Tainting, Safe compartments, Security
TimToady on 2002-05-15T19:02:31
That won't work, since the point of BEGIN blocks is to run even earlier than that. They have to execute while the parse is still in progress or they can't mangle the current grammar by installing subroutine definitions and such.Re:Tainting, Safe compartments, Security
Matts on 2002-05-15T19:41:30
Bah. Make it work. I don't believe it can't work. It's all just a matter of programming.
Re:Pascal-like "in" operator?
autrijus on 2002-05-14T00:38:16
According to Exegesis 4, that's handled by the smart match operator,=~:
&some_sub if (@some_array =~ "some_string");Re:Pascal-like "in" operator?
rafael on 2002-05-14T07:05:16
And I think the &some_sub syntax will be removed -- or at least reworked so it doesn't pass @_ implicitely.Re:Pascal-like "in" operator?
hrothgar on 2002-05-14T14:44:14
Oh boy! That's been the only syntax I've constantly wished for in Perl5. I can't wait for Perl6. ThanksRe:Pascal-like "in" operator?
mrpeabody on 2002-05-14T09:59:24
You can already do this in Perl 5:
&some_sub if (grep {/some_string/} @some_array);
It has a couple extra keystrokes, sure, but in return you get full re matching. It's not very "Pascal-like", you may construe this as a bug or a feature.
Re:Will it be released this decade?
Matts on 2002-05-14T07:51:21
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!
;-)
It's been the best money I've spent all year and it made me feel the all the warm toasty satisfaction of knowing that it was both going to a good cause and tax deductible.
Re:While you're at it ...
davidh on 2002-05-14T07:32:17
Ug, the donation form is not working for me (using a visa card) - I get a page saying that check donations are not yet supported. Too bad. Will try again later.
--
davidRe:While you're at it ...
kurt on 2002-05-14T15:35:32
There was a problem associated with the recent server move that screwed up credit card acceptance. It is working again. Sorry about any inconvenience.
BTW, do you recall the URL that said check donations were not supported yet? I just confirmed that they were working. That sounds like an old error message from a previous development version of the site.
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.)What benefits will Perl 6 bring to the table, from a management perspective?
Jason
Re:Practical Questions
lini on 2002-05-16T13:36:27
Relating to the question on management, will there be any supported added to allow multiple versions of the same module to be installed?
This would make it easier to roll out a new version without having to regress all of the Perl scripts running on the box.
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)
very often, I notice beginners having problems with interpolation of variables in regexes, especially if there are "strange" chars, e.g:
because they often forgetc:\work> perl -w
$match = "\\";
$string =~/$match/;
^Z
Quantifier follows nothing before HERE mark in regex m/+ << HERE \/ at - line 2.
or the like.\Q$match\E
In my eyes, changing the default-behaviour to no-auto-evaluation it will make it easier for beginners to not writing programs that accitentally work, because just by changing the content of a variable, you might get syntax errors, or much stranger, unicode errors. Perhaps using \E....\Q or the like explicitely for auto-evaluation.
Best regards,
strat @ http://www.fabiani.net/