Front page | perl.perl5.porters |
Postings from July 2006
On Tue, Jul 04, 2006 at 06:37:36PM +0000, Scott Walters wrote:
> > Also, are there any areas in core perl that could be usefully improved, for
> > which it is possible to give reliable, bounded estimates of the work
> > involved?
> >
> > Nicholas Clark
>
> This I don't feel like I have any guage on the community, and anticipating what
> people will like is difficult (what people think they want and what they actually
> want are two very different things -- ask any consultant). But here's an on-the-
> spot personal wishlist:
>
> * ByteLoader speed up such that bytecode compiled modules, such as those compiled
> with Pugs, dumped with the P5 backend, and then dumped to bytecode, load much
> more quickly than parsing P5 from source.
I think that 2 prerequisites of that are:
1: Make the byte compiler actually work with 100% of perl code
2: Make it efficient in only saving bytecode for the module/subroutine under
compilation
And for the first, I doubt that anyone can give a reliable estimate on how
long that would take to complete. So that falls foul of my "bounded" caveat
> * Coro support in core, including the large scale refactorings needed to make it
> clean. Even if Coro isn't core, I'd like to see tree structured stacks so
> that it can be cleanly plugged in. In general, anything that makes P5 a more
> viable P6 backend, I'm gung ho for.
I asked Marc what core support Coro would ideally need, which is what prompted
him to mail p5p some months back (and bad me for not commenting on thread).
I don't think that Coro necessarily should go in (and the pre-requisite of
"support" needs to be addressed as described in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-06/msg00946.html )
but I'm very keen on adding core hooks to support innovative modules, as the
flexibility of hooks allows future CPAN authors the flexibility to create
things we'd not even thought of.
I've no idea of the amount of effort needed to switch to tree structured
stacks, but it may be that someone else does.
> * What the hell -- clean up OO a bit. Add a 'method' that, if nothing else,
> shifts off $self. Put it in $_. Or something. Make a 'has' that does
> some Data::Alias-like trickery, such that C<< has $foo >> would do essentially
> C<< alias my $foo = $self->{foo} >>, and C<< has @foo >> would do
> C<< alias my @foo = @{ $self->{foo} } >>. It's easy to argue that Perl doesn't
> need yet-another-OO-hack, but it keeps getting more and more anyway. While I
> welcome Perl 6, I'm still planning on spending Chrismas with my family. Good
> things could come from P6 syntaxisms with some, but not all, of the P6 semantics.
I think that the more general lexical aliases proposal in perltodo would
go a long way to this. The suggested syntax would be
my \$foo = \$self->{foo};
which isn't as terse as your has suggestion, but avoids creating another
keyword, and avoids any implicit C<$self>
Nicholas Clark