The Perl 6 Summary for the week ending 20030323
Assuming I can tear myself away from stroking the cat who has just
magically appeared on my chest and is even now trying to wipe his dags
on my nose, welcome one and all to another Perl 6 summary, which should
go a lot quicker now that Sully has moved off and let me see the screen.
He'll be back though. But before that happens we'll start with
perl6-internals.
Speed question: save/restore vs push/pop
Benjamin Goldberg wondered about how many "save"s it takes to be slower
than one "pushx". Steve Fink pointed out that "save" and "pushx" are not
interchangeable as they push things onto totally different stacks
("save" pushes onto the generic user stack, "pushx" push onto type
specific register frame stacks). Leo Tötsch ignored this difference
(which Ben was apparently aware of) and did some tests which showed
that, on his local architecture and core, 2 saves were slower than one
push. On Dan's machine, it took 3 saves to be slower than one push. Dan
also pointed out that, on some architectures, there's a subtle win with
saves because a push would dirty the L1 and L2 caches while the save
wouldn't. (On SPARC at least, apparently).
<http://xrl.us/eth>
Baby Steps in porting IO to the PIO architecture
Last week, Leon Brocard posted his implementation of the uniq(1) Unix
utility to PASM. This week, Jürgen Bömmels' ongoing project of moving
Parrot's IO operators from the STDIO library to Parrot's own PIO library
(which is asynchronous and a combination of lovely and scary by all
reports.) broke this because PIO didn't have any read buffering
capabilities, which means that the "readline" op didn't work.
On Monday, Jürgen had write buffering working, which Dan applied with
alacrity while making noises about needing to finish up the
documentation for Parrot's asynchronous IO system. There was some debate
on whether a PIO flush should force a write to the disk, or simply
ensure that all the buffers were flushed to the OS. Nicholas Clark
discussed some issues he'd had with Perl 5.8's PerlIO system, and the
need for two different kinds of flush, or more succinctly, the need to
distinguish 'flush' from 'sync'. Dan was convinced by this argument and
Steve Fink seconded the decision.
Then, on Sunday, Jürgen released a patch which got read buffering
working. Dan had a few problems with it and the patch hadn't been
applied by the end of the week. I'm sure it'll go in like a greased
weasel once that's been fixed though.
<http://xrl.us/eti> -- Jürgen adds write buffering
<http://xrl.us/etj> -- Nicholas discusses different types of "flush"
<http://xrl.us/etk> -- Jürgen adds read buffering
PBC Object Files
Michael Collins wondered if it might be a good idea to come up with a
parrot 'object file' specification. I liked Michael's description of an
object file as 'a file that contains compiled instructions plus a
section with a table that maps subroutine/constant labels to their
corresponding byte offsets within the file.' Leo Tötsch's answer was
'not yet'. Apparently the basic functionality is there but there are
some cleanups and a couple of opcodes needed.
<http://xrl.us/etl>
Parrot binaries
Ask Bjørn Hansen posted to say that he'd been trying to make an RPM
.spec file for parrot and had noted the lack of a "make install" target.
He also wondered about the permissions of various files in the
distribution, which seem somewhat cockeyed. Steve Fink posted a patch
which covered some of this (or at least the make install and RPM issues)
with tools which would generate RPMs and asked for comments on his work.
Leo Tötsch liked it and offered a couple of suggestions
<http://xrl.us/etm>
<http://xrl.us/etn> -- Steve's working patch
Some comments on PDD 14 Big Numbers
Mark Biggar, who implemented the original Big* packages for Perl had
some suggestions about Parrot's big number handling based on PDD 14.
Benjamin Goldberg wondered if it would be a good idea to design our
BigInt type so that we could replace the maths engine with a different
engine so that users could pick which ever engine they prefer as
configuration option, and so that new maths engines could be added
without having to make wholesale changes.
<http://xrl.us/eto>
99 bottles of beer on the wall
Douglas Hunter appears to have noticed that, up until now, Parrot had
lacked a vital program -- one which would output the lyrics to that well
known song, *99 Bottles of Beer on the Wall*. So, being a community
spirited kind of chap, he implemented just that and posted it to the
list. A few people quibbled about his style (unnecessary labels, that
sort of thing). Leo Tötsch pointed out, with the aid of some IMCC output
that the optimizer caught those issues anyway, and added the code to the
Parrot distribution's examples/ directory. Well done Douglas, it's good
to see Parrot being used for essential applications like this. I'm just
surprised nobody has yet benchmarked the Parrot implementation against
Perl and Python. This may just be the test application we need for the
Parrot/Python speed challenge.
<http://xrl.us/etp>
BASIC, IMCC and Windows
Clinton A Pierce has been having a hard time making good on his offer to
produce a milestone Windows binary for distribution. He's having a hard
time building IMCC because it seems to want headers that MSVC++ isn't
happy with. Dan noted that this needs to be fixed before the next
release of Parrot (which will be either 0.1.0 or 0.0.11) because he
wants to get rid of the IMCC/parrot difference and just have a single
binary. Leo Tötsch and Nicholas Clark offered a few suggestions about
workarounds, but it looks like there's still no Windows distribution for
Parrot.
<http://xrl.us/etq>
Iterator Proof of Concept
Following the deafening response to his Iterator proposal of last week,
Leo Tötsch agreed with me that that must mean that everyone liked the
idea and posted a proof of concept patch and invited comments. Nobody
has yet done so.
<http://xrl.us/etr>
vtable_1 - accessor macros
Leo Tötsch has started work on hiding vtable functions and posted his
first patch. He commented that the new accessor macros seem to make for
more readable source files. He asked if people were okay with the macro,
as the next step would be to start using the macros all over the parrot
source. Nicholas Clark liked the basic idea, but worried about
documentation, and about the possibility of scary macro layering a la
Perl 5. He also wondered if it would be possible to conditionally write
them as inline functions, which would make debugging easier. Leo didn't
see much point in making this particular set of macros into inline
functions as they were simple translations with no complex
functionality.
<http://xrl.us/ets>
Parrot 0.0.10 released
Parrot version 0.0.10, codename 'Juice' was released on Wednesday. Steve
Fink rounded up the usual list of improvements and generally did a good
job of letting the world know about the new Parrot release. If you want
the details, follow the link.
<http://xrl.us/ett>
Meanwhile, over in perl6-language
perl6-language was again the busier list this week. The fallout from
Apocalypse 6 continues both with clarifications of what was in that
document and some suggestions inspired by it.
is static?
Towards the end of last week, Uri Guttman had asked about a possible 'is
static' variable trait, and the discussion carried on into the this
week. Arcadi Shehter suggested using "has" to introduce a static
variable:
sub foo () {
has $s //= 0;
$s ++;
}
Larry described this as a *very* interesting idea, but was concerned
that this might be akin to overloading the meaning of "has" in the same
way that C overloaded the meaning of "static". Damian also worried that
using 'has' in this way would mean stretching 'the concept of objects a
little too far'. He also thought that using "//=" to initialize such a
variable felt wrong, and that maybe we needed a third assignment
operator to go with 'assign unless true ("||=")' and 'assign unless
defined ("//=")', which could be thought of as 'assign unless exists'
and suggested "??=" as a possible (though he didn't profess to actually
like it). Damian also thought that such functionality should really be
introduced with a trait and suggested a list of possible trait names.
Uri was unconvinced by any of Damian's alternatives and proposed
deciding the name with a duel on the beach at Boca Raton.
Larry decided that using a trait to denote a 'static' variable would be
the wrong way to go because such a variable has a different kind of
scope from a "my" variable and described the whatever declaration was
eventually settled on as introducing a lexically scoped alias to a
property of the current block. Larry later suggested "state $s = 0"
because 'a static var makes a subroutine stateful'. Uri wasn't sure, but
Damian liked it.
Arcadi Shehter wondered about scoping of lexically scoped subs and if
they could really be thought of as lexically scoped at all, whereupon he
and Mattijs van Duin got a bit tangled up with the various kinds of
scoping available, but there's been no definitive comment from Damian or
Larry about the correct behaviour.
<http://xrl.us/etu>
On the place of Scalar in any class hierarchy
During the discussion last week about strictness and type coercion on
function calls, some confusion arose about whether "Int isa Scalar", or
"Scalar isa Int|String|Float|...". David Whipp proved himself a hero by
posting on this subject, pointing out that Scalar is the type of the
variable, not of the value (I'd probably replace variable with
'container', but I'm picky like that) and explained how this solved some
of the problems people had been having. There was no comment from Larry
or Damian about this post, but I thought it was wonderful.
<http://xrl.us/etv>
A6 questions
Dave Storrs posted a grab bag of questions about Apocalypse 6 and got a
grab bag of answers.
<http://xrl.us/etw>
Apoc 5 - some issues
Matthijs van Duin had a pile of questions and issues with Apocalypse 5.
Some of the questions were Hard. Only Luke Palmer dared answer them. He
and Matthijs batted things back and forth a few times, but it looks like
Matthijs still had some issues with backtracking into and over closures.
<http://xrl.us/etx>
"XML is Too Hard for Programmers"
Rich Morin pointed everyone at Tim Bray's article about XML being hard
to deal with in most programming languages. Robin Berjon chipped in with
a pointer to an xml-dev thread on the same subject. There was a certain
amount of muttering about companies that use formats that seem to walk
like XML but fail to quack like XML (the initials M & S were used, and I
don't think they were referring to Marks and Spencer). Michael Lazzaro
made an impassioned plea for insuring that Perl 6 allows easy, fast
parsing of XML-like things out of the box. Austin Hastings suggested
that Michael should take command of P6ML. Dan pointed to a basic Parrot
XML parser in the Parrot examples directory that was at least four times
faster than the equivalent Perl 5 code that it's a line for line
translation of, and noted that the performance numbers were old.
<http://xrl.us/ety>
<http://xrl.us/etz> -- Tim Bray's article
<http://xrl.us/et2> -- xml-dev thread
Rules and hypotheticals: continuations versus callbacks
Remember what I said about Matthijs van Duin still having some issues
with backtracking? Well, he kicked off a whole new thread just to
discuss it and two possible methods for implementing the grammar system
(labelled the 'backtracking continuation' and 'callback' methods).
Mattijs would like to see the backtracking continuation method blessed
as the right way. (He discusses all this here because the choice of
implementation could well have language level implications). Luke Palmer
was concerned that both of Mattijs's proposed implementations would be
very slow and had a couple of other possible implementation approaches
(the 'success continuation' and 'backtrack exception' methods). Mattijs
reckoned that the success continuation approach was pretty much the same
as his 'callback' method, and that the 'backtrack exception' method
seemed to have problems with rules like "<foo> <bar>". And then it all
got very complicated as Dan and Matthijs went back and forth at the
issue with occasional interjections from others where appropriate. Then
someone mentioned threads...
Dan and Matthijs seem to have very different sets of assumptions which
leads one to suspect that they're arguing past each other on occasion. I
certainly found myself wishing there was somewhere convenient with an
ample supply of chalkboards, chalk, index cards and Sharpies and other
high bandwidth communication aids where they could go and come to some
kind of understanding.
At one point Austin Hastings observed that 'when anyone says "I don't
see why anyone would ...", Damian immediately posts an example of why.
Unless it's Damian, in which case Simon, Larry, or Dan usually
counterpost.' Hey, it made me smile.
I think Larry's only contribution to this thread bears repeating in its
entirety:
I would like to express my sincere gratitude to all of you for working
through these issues. I bent my brain on the Perl 5 regex engine, and
that was just a "simple" recurse-on-success engine--and I'm not the only
person it drove mad. I deeply appreciate that Perl 6's regex engine may
drive you even madder. But such sacrifices are at the heart of why
people love Perl. Thanks!
<http://xrl.us/et3>
Questions to Help Program Perl6::Parameters
Brent Dax is working on a Perl6::Parameters source filter for Perl 5, a
task he describes as 'damn hard'. He had a couple of questions about
argument behaviour. Damian had the answers, and made noises about his
forthcoming module, Perl6::Rules. Simon muttered something about
Parse::FastDescent (but everyone passed over that) and pointed out
Matthijs van Duin's work in progress.
Larry thanked Brent for taking on the task and 'suffering vicarious pain
for the user' and mentioned that he was interested in feedback on spots
where the design impacts performance unduly. Larry went on to discuss
possible changes to the scoping of $_ to help with with the transition
from Perl 5 to Perl 6. He and Damian proceeded to discuss other
entertaining syntax possibilities to do with "want", "where" and "when".
Nobody has yet proposed meaningful semantics for "what", "who" and
"why", but I'm sure somebody will get 'round to it.
<http://xrl.us/et4>
<http://xrl.us/et5> -- Matthijs' work in progress
".req" or ".arity"?
Austin Hastings asked that Routine's ".req" method be renamed ".arity".
Damian rather liked the idea. Larry wasn't so sure because ".arity" is
somewhat opaque to non-mathematicians, but he accepted that one could
argue that anyone who doesn't know what arity means shouldn't be writing
code that depends on it. Steffen Müller thought that either ".req" or
".reqargs" would be a better name for the method.
For those who don't know, 'arity' is the number of arguments a function
or operator takes.
<http://xrl.us/et6>
Acknowledgements, Announcements and Apologies
And another summary rolls towards its close. I'd like to echo Larry's
thanks to everyone who's working on scary magic like the Perl 6 rules
engine and Perl6::Prototypes. The way people like Brent, Matthijs, Leo
and Luke have stepped up to the plate for this undeniably Hard Stuff is,
frankly, inspirational. It's people like you who keeps me bullish about
Perl 6.
Thanks too to everyone else involved in either list; Michael Lazzaro
made the point that often the most productive way for perl6-language to
proceed is for an initial suggestion to be thrown out onto the list,
then everyone has a good long wibble about it going off in about 3000
different directions at once before someone (usually one of Damian,
Larry or Allison but not necessarily) pulls it all together into
something that makes sense and we move on to the next item. My gut tells
me that without all the wibbling the end result wouldn't be quite so
satisfying.
For instance, much as I hated trying to summarize the everlasting
pipeline thread, the end results of that discussion are the rather
lovely "==>" and "<==" operators that appeared in the latest Apocalypse.
(Of course, Larry or Damian will probably respond to this summary by
telling me that actually, they'd been planning something like that all
along. I just won't necessarily believe them)
If you appreciated this summary, please consider one or more of the
following options:
* Send money to the Perl Foundation at
<http://donate.perl-foundation.org/> and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. <http://dev.perl.org/perl6/> and <http://www.parrotcode.org/>
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, photographic and writing commissions,
or a print of Mark Citret's *Empty Room* to [EMAIL PROTECTED]
This week's summary was again sponsored by Darren Duncan. Thanks Darren.
If you'd like to become a summary sponsor, drop me a line at
[EMAIL PROTECTED]
--
Piers
