develooper Front page | perl.bootstrap | Postings from July 2000

Re: Perl6 - ROLES

Thread Previous | Thread Next
July 21, 2000 03:09
Re: Perl6 - ROLES
Message ID:
Adam Turoff (lists.bootstrap):
>As Grand Master Gnat has said many times before in many forums, 
>"email is a great conspiracy to waste people's time".

If people don't want email, they shouldn't be on mailing lists.

The mindless bureaucracy of this has already frustrated me too
much. Here are my thoughts. Take them or leave them. No, I can't
be bothered to finish this off.

Good luck.

=head1 A time to build, and a time to tear down what was built

=head2 Some thoughts on Perl 6

I can't make it to the Open Source Convention this year, which is a
great shame. But if I was there, these are the sorts of things I'd be
raving on about right now. Everyone gets their two-pennyworth; I'm going
to throw in the whole pound right away.


Wow, I like saying "infrastructure".

=head2 Modularity

Splitting up the development into a bunch of teams doesn't just help us
with development speed; it also makes it more likely that we'll come up
with a more modular design for Perl.

Strange though it may sound, I've recently been fiddling around with
reorganizing the core. Not rewriting, just reorganizing; putting things
into directories, moving a few functions, and so on. One of the other
things I hack on a little is GNOME, and I've been impressed at the way
they've made use of libraries to encapsulate parts of their
applications. It's a shame that, although CPAN teaches us to be modular,
the core is still - on the whole - monolithic.

Perl has elements it can offer the world, even if they don't want to
take the whole package. My first idea was to extract out Perl's internal
variable types into a separate library, a potential F<libperlvar>. I'd
love to be able to use SVs, arrays and hashes in my C programs! We've
got scoping and reference counting. We've got a darned good regular
expression engine that we could separate out - or maybe there'll be a
better one come along that we can slot in. Let's make the Perl internals
a legacy too, and let's make it easy for ourselves to maintain by having
discrete elements.

This'll have knock-on effects in a bunch of areas. Imagine being able to
remove F<libruntime> and link in F<libcompile>. Imagine 
C<require re 6.0.1>...

=head2 Organisation

Hmm, small I<closed> groups? Well, hm, OK, people need to get work done.
The strength of the Perl community is that it's encouraged a lot of
generalists. We want to avoid pidgeon-holing people if at all possible. 

=head2 Community

=head2 Bug Tracking

=head2 The Wishlist

This is the stuff that'll be mentioned a million times in the next

Safe signals, threading, native compiler, SVs as hash keys, filehandle
types, event loop, optional strong typing, banish typeglobs,
mark-and-sweep GC, lexical subs, named prototypes, re-entrant
everything, autoconf, Configure, Perl bootstrap configuration, localised


It's become clear that we need two types of documentation. The set we've
got is mainly reference, but people want to use it as tutorial as well.
We've seen more and more tutorial style documentation coming out, so
it may well be time to properly separate these out.

In fact, I'd like to see the documentation layout become a lot more
flexible. Let's split up the tools, the functions, the documentation for
the system adminstrator, the documentation for C and XS extensions, and
so on.

=head2 Markup

=head2 Tools

C<man>, oh C<man>. 


=head1 PARSER

=head1 UNICODE

Like it or not, Perl's losing out because of its Unicode support or lack
thereof. Unicode's going to happen. What kind of support are we willing
to give it? 

Having a "Unicode flag" on a variable isn't good, and it's lead to a lot
of real badness in 5.6.0. If we want to handle Unicode properly, B<all>
strings must be handled in Unicode internally.

UTF8 or UTF16? Tricky. UTF16 means everything's twice its current size,
UTF8's harder to manipulate. (Surrogate pairs are just there to make
life interesting.) We should certainly I<support> both, and I'd encourage
the use of UTF16 internally.

We can happily raincheck on UTF32 for a few years, although it makes
sense to be ready for it if and when it does arrive.


Input line disciplines. We looked at this, and we've had some ideas.
It's going to mean a complete rewrite of C<stdio>. Life sucks.


"There are two major products that come out of Berkeley: LSD and UNIX.  We
don't believe this to be a coincidence." - Jeremy S. Anderson

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About