I was being serious. But first, a plea:
This is much harder than doing the Perl 5 summaries, because I have to
watch over a lot more things. I'd appreciate some help; if you feel this
is a useful exercise and you can spare about an hour a week, please get
in touch with me and I'll tell you how you can help me. Alternatively, I
seem to recall that there was some idea that the working group chairs
would produce their own summaries of what we're doing. Is this still
meant to happen, or was that just for the RFC phase?
Ask, Dave, you may host this where you want; I retain copyright, and grant
you a non-exclusive right to publish. The HTML edition will be placed
at
http://www.simon-cozens.org/perl6/THISWEEK-MMDD.html
That is, this week's will be at
http://www.simon-cozens.org/perl6/THISWEEK-20010211.html
Please let me know what you're going to do with it, so I can point news sites
at your version.
Anyway, on with the show.
--
This week on perl6 (04--11 Feb 2001)
Notes
Please send corrections and additions to
[EMAIL PROTECTED] where MM is the current
year and month.
This week was reasonably quiet, seeing around 350 messages in all the
groups. For a change, most of the traffic was on perl6-language.
Autoloading Modules
Last week, Dan asked people to think about ways to autoload modules
when a function was used; the idea being that you'd be able to say,
for instance:
socket(SOCK, PF_INET, SOCK_STREAM, $proto);
(or moral equivalent) and Perl would load in all the socket functions.
This is actually what Perl 5 already does for glob and some of the
Unicode functionality. Some people went off on a bit of a tangent and
started discussing ways to autoload modules more generally, by having
modules declare what functionality they're providing.
One big question for both sub-discussions was how we key the functions
to code. Jarkko said:
A gut feeling that I have is we can't simply go by interface
'names', be they just simple names of funtions/methods or their
full 'signatures' (let us not even start on (1) how difficult with
Perl's type system and functions it is to define signatures (2) the
difficulty in defining an ontology/vocabulary), either would not
really be enough.
What I think is needed is some sort of opaque tag: the name of the
'contract' the API claims to fulfill. The name can be the name of
the standard, the name of the company, the name of the individual.
Branden suggested that a URI should be used, leading to the inevitable
but still horribly scary notion of
use autoload { Bar = 'http://www.cpan.org/modules/Bar' },
{ Baz = 'ftp://my.local.domain/perl-modules/Baz', VERSION
= 2 };
Various people pointed out that this might not be secure.
Packaging
The autoloaded core functions idea got slightly left by the wayside,
as the discussion finally veered off onto how to package up modules
and programs to satisfy dependencies and make things easy for the
user. A setup similar to Java's "jar"s was suggested. Dan came up with
the very simple and neat idea of simply shipping a bytecode compiled
version of a program instead. Schwern was a bit concerned that this
would lose source code and would separate out documentation; Dan's
brilliant answer was:
Not unless you strip the bytecode. I want to optionally package the
source in the bytecode, since otherwise you can't do some
optimizations after the fact on the generated bytecode stream.
He also suggested a text segment in bytecode so that, for instance,
you can still get POD embedded in code.
That's something that may well happen anyway, but Branden came back on
the packaging issue. He noted that Dan's suggestion wouldn't help for
modules with C extensions, and also said:
Actually, I think the archive approach is more general, because it
wouldn't have this kind of problems and would allow other resources
to be deployed together with the code, like documentation, perhaps
even text files and images used by a Perl/Tk application
Comparisons were made between this and the currently-existing PPM.
Branden produced a [1]draft PDD for his ideas.
Vtables
At long last, Dan produced the second PDD, specifying [2]the vtable
API. As expected, this exposed a lot of hidden confusion about what
vtables are for and how they're going to be handled. Tim piped up with
a few questions and corrections, including a discussion about how
string handling is going to work, especially string encoding. Dan said
he deliberately left UTF8 off, because dealing with variable-length
data is horrid. Most people disagreed, saying that UTF32 was too big
for most people, and UTF8
