This week on Perl 6, week ending 2003-01-12

Leopold Tötsch posted a test program showing the effects of PMC
size and timing of garbage collection and allocation and suggested
ways of improving the GC system based on the conclusions he drew from
its results. Leo, Dan and Mitchell N Charity discussed this further
and tried a few different approaches to try and improve performance
(though Mitchell did worry about premature optimization). Work in this
area is ongoing.

Dan asked about the current state of the Perl 6 parser, wanting to
know what was and wasn't implemented, and wondered about adding the
Perl 6 tests into the standard Parrot test suite. Sean O'Rourke and
Joseph F. Ryan both gave a summaries of where things stood. Joseph
also suggested a few refactorings of the parser to deal with the
fluidity of the current spec (almost all the operators have changed
symbols since the parser was first written for instance).

Last week, I said that Robert Spier had 'started work on getting a
browseable, cross-referenced version of the Parrot source up on
perl.org.' What actually happened was that Robert asked Zach Lipton to
do the work. This week, Zach delivered the goods, which, I must say,
look fabulous.

I'm sure that if someone were to extend LXR so it had a better
understanding of .pasm, .pmc, .ops and other special Parrot source
types, then the community would be very grateful indeed. I know I would.

Piers Cawley offered what he thought might be a new approach to
dealing with the infant mortality problem that got efficiently shot
down by Leo Tötsch. This led to further discussion of possible
answers, and it looks like Leo's proposed solution involving a small
amount of code reordering and early anchoring will be the one that's
tried next. All being well, it won't require walking the C stack and
hardware register set, which can only be a good thing.

Later, Leo asked whether it'd be OK to check in his work so far on
redoing the GC because he was up to 15 affected files and was starting
to worry about integration hell. Steve Fink wasn't sure about one of
his changes, so Leo checked in everything else.

Last week, I mentioned that Leon Brocard's wish list for the next Parrot
iteration included Objects. This week, Dan posted his first draft of
what Parrot Objects would and wouldn't be able to do. The 11th
entry on Dan's list (Objects are all orange) seemed to be custom-made
to please Leon. There was a fair amount of discussion (of course), but
the consensus was positive.

Nicholas Clark crossposted to p5p and perl6-internals to discuss the
problems of benchmarking Parrot against Perl 5. One of parrot's aims
is, of course, to go faster than Perl 5. The problem is, how do you
measure 'faster'? Nicholas has been working on making Perl 5 go faster
and was distressed to find out that using 'perlbench,' a patch of his
went 5 percent faster, 1 percent slower, zero and 1 percent faster, depending on what
machine/compiler combination he ran the benchmark on. Leo Tötsch
commented that he'd found performance varying by more than 50 percent in a JIT
test, depending on the position of a loop in memory. Andreas Koenig
commented that he'd come to the conclusion that bugs in glibc meant
that there was little point in benchmarking Perl at all if it was
built with a glibc older than version 2.3 (apparently malloc/free
proved to be gloriously erratic...) I'm afraid not much was actually
resolved though.

The discussion of Variable types versus Value types continued from the
previous week. Dan opined that Arrays weren't necessarily objects,
which brought forth squawks from Piers Cawley who pointed out that
being able to do:

class PersistentList is Array {
method FETCH ($index) {
...
}
...
}

would be much nicer than tying a value in the Perl 5ish fashion. Dan
reckoned that delegation would probably be enough which, IMHO, seemed
to miss the point. Various other people chimed in to, essentially,
tell Dan that he was wrong, but I'm not sure Dan agreed with them.

Meanwhile, in a subthread sprouting lower on the thread tree, Damian
pointed out that there were two types associated with any Perl
variable -- the 'storage type' and the 'implementation type.' (See his
post for details) Essentially the storage type is the type
associated with the contents of a variable and the implementation type
is the type of the 'thing' that does the storing -- usually one of
SCALAR, HASH or ARRAY -- i.e., related to the variable's sigil. Specifying a different implementation type will probably be how Perl 6
does tying.)

In a thread that spilt over from the previous discussion about
whether arrays were objects, Michael Lazzaro put up a list of
examples that seem to imply rather strongly that arrays are
either objects or indistinguishable from them, and there was general
muttering that being able to overload tied Perl containers in this way
was a neat way of implementing tie semantics. Mr Nobody attempted to
restart the left-to-right versus right-to-left argument. There was also some discussion of the sickness of my Foo
@foo is Foo (which, in Perl 5ish parlance creates a tied array -- using Foo as the tying class -- which can only contain objects in class
Foo.) Damian agreed that this was definitely sick, and that he for one
would be making use of it.

Argh! No! It's back and this time it means business. The dreaded
left->right versus right->left thing came back, and this time it was
Damian applying the electrodes to the corpse. Of course, it being
Damian, he was instantly forgiven as he came up with the very cool,
very low precedence ~> and <~ operators, allowing you to
write

@out = @a ~> grep {...} ~> map {...} ~> sort;

Which is, to these eyes at least, lovely. See Damian's post for the
full details. The general response to this was definitely on the
'lovely' side of the balance, though one detractor did induce a sense
of humor failure on Damian's part. There was also a certain amount of
discussion about whether this was exactly the right syntax to go with
the semantics, but where would perl6-language be without a great deal
of syntactic quibbling? (A good deal easier to summarize). The most
popular alternatives were |> and <|. There was also a
certain amount of discussion of what I can only describe as 'evil'
uses of the syntax, involving arrows going in different directions in
one statement. Rafael Garcia-Suarez earned at least one giggle when he
suggested that we just needed v~^~ and we had our own
flavour of Befunge.

There was a fair amount more discussion, mostly thrashing out details
and edge cases.

John Siracusa wondered whether there would be a perl6ish way of creating
code that was 'the spiritual equivalent of #ifdef, only Perlish.' To
which the answer is, of course, 'yes.' Damian showed off a neat trick
(modulo a couple of pretty typos) with an immediate function that
demonstrated using Perl 6 as its own macro language.

The only thing I set out to do was implement a regular expression
compiler. Along the way, I seem to have implemented hashtables,
patched the configuration system, messed with memory management,
implemented some stuff for IMCC, beefed up the PMC file parser, fixed
some problems with the JIT, and a few other things. Then I got a job
and ran out of time to work on Parrot, so they made me pumpking. And I
still haven't made it that far with the regex compiler.

Computer games, originally. First language, BASIC; second language, 6502
assembly. Then a failed attempt at C, then more successful encounters
with Pascal and 68000 assembly, and then C++. Next, a few more
assembly languages together with SML, NESL, Lisp, Scheme, COBOL, Tcl,
Prolog, and a few others. And, at last, Perl4 and then Perl5. Oh, and
Java, fairly recently. My day job is now in a combination of Perl5 and
C++, as well as C when nobody's looking.

Probably smoothing the path for other developers and keeping them
motivated. My highest priority is applying (and testing) other
people's patches, since the mostly likely reason for someone to lose
interest is to not have their hard work make it into the distribution.
I would also like to somehow make people's contributions more visible
-- anyone who has contributed anything significant should at least be
able to point to something and say "Look! I did that! See my name?!"

Obviously, Leopold Tötsch. Anyone paying an iota of attention
would know that. Particularly someone who's been writing the
summaries, unless you're stupid or something. Leo's amazing; I don't
know how he finds the time. To accomplish that much, I'd need to be
working full-time about 26 hours a day.

No, not really. I was originally thinking of Perl6 when I got
involved, but since then the Parrot VM itself has become more
interesting to me. Although I still wish Perl6 development would pick up --
there's a lot that can be done even with the limited amount of the
language that's been defined. Sean O'Rourke did an excellent job in a
short amount of time, but it looks like real life has drawn him back
into its fold, and nobody seems to have picked up the slack.

Heh. That is the question, isn't it? Making a release is probably the
most concrete measure of how I'm doing as a pumpking, and by that
standard I'm a dismal failure. As soon as we reclaim the tinderbox
(and without dropping any machines off it in order to do so!)
Everything else I wanted to get in is already there.

No, I don't think so. Maybe I'm wrong, but I know that I personally
had to put aside a lot of the actual coding I was working on in order
to concentrate on making sure everyone else's changes were being given
proper consideration. I'd much rather relieve him of that burden, and
let him continue to exercise his demonstrated talent at churning out
quality code.

No. It kind of makes sense, but I remember how I first started by
rewriting a bunch of Dan Sugalski's code, and then seeing most of my
code get rewritten. I used to be disturbed by that, but now I think of
it more as a badge of honor -- it proves that what I wrote was worth
rewriting. Much more so in Dan's case, I suppose, since he stated
up-front that he was merely doing a reference implementation of a
design. Dan's done an amazing job of laying out a design that hasn't
needed to change at its core, and so has been a very dependable guide
to the implementation of the backbone. But even in my case, I can see
a number of ideas that were carried through in the reimplementation,
even if no actual code survived. (Interestingly, my tests did. Which
kind of makes sense if you think about it.)

Another Monday evening, another summary running over into Tuesday
morning. Ah well. Distractions were provided by the usual suspects
(Mike and Sully, our ginger kittens), supplemented this week by a
horrible cold (the compulsion to find a tissue does tend to derail the
train of thought).

Proofreading was once more handled by Aspell and me. This week, we even
made sure that the Who's Who section contains the name of the person
answering the questions rather than making you wait 'til the
acknowledgements section.

Speaking of which, many thanks to Steve Fink for his answers to the
questionnaire (well, to the questions he wanted to answer anyway). The
questionnaire queue is now quite empty so, unless a few more folks in
the Perl 6 community send me some answers soon then the Who's Who
section may be going on hiatus. Send your answers (or request the
'correct' question list from) 5Ws@bofh.org.uk.

If you didn't like this summary, then how did you get this far? If you did
like it, then please consider one or more of the following options: