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-YYYYMMDD.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 YYYYMM 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 was a good compromise for most data. It was
generally agreed that an abstracted string handling layer would make
most of the problem go away.
Edwin Steiner asked whether the vtable API should be made up of
macros; I pointed out that this was the road that Perl 5 went down,
and look what happened to that. Dan also said that there wouldn't be
an "API" for vtables - they're to be used by the Perl guts only.
There was still a lot of confusion as to how overloading and aliasing
would be accomplished. Branden came up with an alternative suggestion
for how to handle vtables, which seemed to be rather more high-level.
The current vtable PDD wants to make many core ops a single vtable
call if possible. There seemed to be much confusion about how the key
field worked, and what operation was being carried out on what. No
doubt further revisions of the PDD will clear this up. Dan also said
that once the PDD has matured a little more, he wants to start writing
code for the base classes. We're nearly there, guys.
Subroutine return values
There was a lot of light but very little heat in the continuing saga
of assigning to a magic return value variable. Some people seem to
want to do this:
sub foo {
foo = 10;
}
instead of return 10, just like Pascal, Algol and all those other
failed, now-dead languages.
A (slightly) better suggestion was a magic variable to hold the return
value, similar to what Parse::RecDescent (and of course, yacc) does.
The names $__ and $^R were suggested, but there was no consensus on
whether or not it would even be a good idea.
End of Scope Actions
A far better idea came out when people stopped looking at what they
wanted and started looking at why they wanted it. A lot of the value
in having a assignable return value is in the situation of subroutines
which set something up, compute, and then turn it down again. Another
way of looking at that was to stipulate a block executed at the end of
the scope, like this:
sub lines {
open IN, $_ or die $!;
return scalar();
}
post lines { # This is executed on return
close IN;
}
Damian had, of course, thought ahead, and this is covered by his
[3]RFC 271. However, he agreed that post-block actions should be
allowed everywhere, not just on subroutines. The always keyword was
agreed upon as a good way of doing this, although POST was also
suggested. This lead to the semi-inevitable rehash of the try- catch
exception handling debate. According to John Porter,
There is no try, there is only do. :-)
Garbage Collection
Jamie Zawinski published his [4]rant about Java, which caused certain
sensible people to ponder how to make sure Perl avoids the same
mistakes. A few of the things mentioned included platform
independence, the size of SVs, locking, but the discussion settled
down to garbage collection, as rather a lot of discussions on
perl6-internals are wont to do. (Oh, this was on perl6-language. Ho
hum.)
The trigger was a question from Branden:
I actually don't understand how traversing a graph can be faster
than incrementing/decrementing/testing for zero on a refcount. I
believe you, but I just don't understand. Could you point me to
some URLs that talk about this?
and a masterful answer from Piers:
There's a jolly good book on this called (would you believe)
'Garbage Collection'. The crux of the matter would appear to be
that with refcounts you have to do a pretty small amount of work
very, very often. With a well designed GC system you do a largish
amount of work much less frequently. The total amount of work done
tends to come out higher in the refcounting scenario.
This was coupled with a [5]more comprehensive answer from Ken Fox. Dan
said he wanted to put GC-related data at the end of a variable, so
that it didn't always get loaded into memory. He also pointed out that
The less memory you chew through the faster your code will probably
be (or at least you'll have less overhead). Reuse is generally
faster and less resource-intensive than recycling. What's true for
tin cans is true for memory.
and hinted that Perl 6 is likely to be using a generational semi-space
garbage collection scheme.
kdb
Joshua Pritikin mentioned [6]kdb, but had to be tortured before he
would explain why. It eventually became clear he was talking about the
K language and its interesting data model; he says:
Whether K is ultimately a failure or not, i find it to be an
interesting mix of design trade-offs. Of course i'd have to use it
in a real project to offer a detailed report of its weaknesses.
ESR on Perl 6
Eric Raymond released two more chapters of his on-line book [7]The Art
of Unix Programming, something Perl 6 people would do well to read.
Unfortunately, he wasn't particularly complimentary about Perl,
claiming that both Perl 5 and Perl 6 are currently stagnant and
stalled. This led to a rather acrimonious discussion about our public
image, and it was resolved that these summaries might help us let the
public know what's going on. So here we are.
And there we were. Until next week I remain, your humble and obedient
servant,
_________________________________________________________________
[8]Simon Cozens
* [9]Notes
* [10]Autoloading Modules
* [11]Packaging
* [12]Vtables
* [13]Subroutine return values
* [14]End of Scope Actions
* [15]Garbage Collection
* [16]kdb
* [17]ESR on Perl 6
References
1. http://archive.develooper.com/perl6-language%40perl.org/msg05694.html
2. http:[EMAIL PROTECTED]/msg02305.html
3. http://dev.perl.org/rfc/271.html
4. http://www.jwz.org/doc/java.html
5. http:[EMAIL PROTECTED]/msg05693.html
6. http://www.kx.com/
7. http://www.tuxedo.org/~esr/writings/taoup
8. mailto:[EMAIL PROTECTED]
9. file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#Notes
10.
file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#Autoloading_Modules
11. file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#Packaging
12. file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#Vtables
13.
file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#Subroutine_return_values
14.
file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#End_of_Scope_Actions
15.
file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#Garbage_Collection
16. file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#kdb
17.
file://localhost/home/simon/work/perl6/summaries/THISWEEK-20010211.html#ESR_on_Perl_6
