The Perl 6 Summary for the Week Ending 20020908
Well, what a week it's been eh people? Larry's been telling the Slashdot
crowd about quantum god and big knobs, there's been a call for Perl 6
programmers on Perlmonks (http://makeashorterlink.com/?L51631EB1), and
the Octarine parrot took flight.
So, let's start with perl6-internals, as is traditional.
The Octarine Parrot flies!
Jeff Goff (who deserves to suffer for his parody of *Eight Days a Week*)
announced Parrot 0.0.8, available from the usual places. This release
includes:
Working Perl 6 rules/patterns
Multidimensional keyed access
JIT for ARM processors
Lexical scope operators
Many bugfixes and smaller subsystems
Mere moments after announcing the new baby, Jeff realised he'd made a
mistake with the tarball's MANIFEST, and announced the release of Parrot
0.0.8.1, which has all the same features as 0.0.8, but a MANIFEST error
has been excised. MANIFEST seems to be a source of problems, Tanton
Gibbs had problems with it later in the week too.
http://makeashorterlink.com/?A16623DA1 -- Announcement
http://www.cpan.org/src/parrot-0.0.8.1.tgz -- Tarball
Goal call for 0.0.9
Soon after the 0.0.8 announcement Dan asked us what we wanted to see in
0.0.9 and offered his list. The list got rather long as Sean O'Rourke,
Steve Fink and Nicholas Clark all chipped in suggestions. The `long'
list ended up as:
* Exceptions
* Initial PMC freeze/thaw API
* Sub indicators in bytecode
* On-the-fly bytecode section generation
* Methods (in PASM and C)
* Implementation of some methods for the Perl classes
* Stashes
* Resolve the prompt finalization problem
* PMC name, implementation cleanup(*)
* Filename, line number tracking
* Careful elimination of compiler warnings
* Rationalization of bytecode generation
(*) The PMC issue was brought up by Steve. He pointed out that, right
now we have a situation where theoretically language independent PMCs
often refer to, and create, Perl specific PMCs on the fly, which seems
rather wrong.
http://makeashorterlink.com/?S12652EB1
http://makeashorterlink.com/?I13662EB1 -- Steve's list
Approximate string matching in regexes
Sean O'Rourke discoursed on edit distances and approximate matching, and
offered a patch implementing an "rx_amatch" opcode.
http://makeashorterlink.com/?U24663EB1
More regex stack manipulations
Sean also implemented a couple of opcodes for manipulating the regex
engine's stack; "rx_stackdepth Ix" and "rx_stackchop Ix". Dan thought
that the semantics of "rx_stackchop" were slightly off, and that the
instructions were actually intstack specific and should therefore be
called "intstackdepth" and <intstackchop> respectively. Dan is also
`really, *really* close to tossing the last pretense of being a
stack-based system and move all the way to routine-based frames instead,
which would definitely make some things easier.' (Whatever that means).
Sean and Steve Fink both seemed to think that that may be a step too
far, at least for something as backtrack heavy as the regex core. Steve
thought he would rather not create a few thousand Exception or
Continuation objects. Steve also made noises about encapsulating
intstack.c's functionality in an appropriately named PMC.
Later in the week, Steve delivered his patch to provide an integer array
PMC, but wondered if it shouldn't be called an integer dequeue (a double
ended queue). John Porter voted for dequeue. Leopold Toetsch wondered
why the patch needed a pair of new ops, and questioned the entire
premise of the patch, so Steve mounted a sterling defence of his patch.
http://makeashorterlink.com/?P25663EB1
http://makeashorterlink.com/?J16621EB1
core.ops ARGDIR
Leopold Toetsch kicked off a discussion of `the intended meaning of
ARGDIR_IN/OUT'. I'm afraid to say that, whilst I understand the
individual words in his message, I don't really understand the posting
as a whole. Which is my own fault, and makes life rather hard for a
summarizer. However, Nicholas Clark and Angel Faus seemed to understand
him, and discussion ensued.
http://makeashorterlink.com/?D27621EB1 -- Thread starts here.
Parrot: maximizing the audience
Jerome Quelin put the cat among the pigeons when he made a few
observations about the perlcentricity of Parrot, and wondered what the
benefits of making Parrot more explicitly vendor neutral. Jerome
wondered `what could *we* do in order to open parrot to non-Perl centric
people?'
Markus Lair suggested renaming perl6-internals to `something better like
"parrot internals"'. Sean O'Rourke wondered what effect this would have,
apart from breaking his procmail setup. Dan thinks we'll probably shift
to a more neutral list name eventually. John Porter claimed that `some
folks seem to think that sufficient reason [to change] exists now.', and
Dan pointed out that John didn't have to convince `some folks', he had
to convince Dan. John then attempted to invoke Larry.
John Porter reckoned that changing the list name would have "a huge
psychological effect, at least outside our tight little club. But if
that's only as far as you can see...". Dan responded with admirable
restraint.
Steve Fink is surprised at how little Parrot is tied to Perl 6, and
noted that Perl 6 `mostly provides evidence that this isn't just an
exercise in intellectual masturbation', and came down in favour of
renaming the mailing list.
Ask Bjoern Hansen popped his head up to say that it would soon be
relatively easy to change the list name to, say, '[EMAIL PROTECTED]'.
Andrew Kuchling -- one of the python-dev crew popped to talk about
parrot-gen.py and why it's not being heavily developed. (From his point
of view, the mailing list name is an irrelevancy BTW). Andrew made some
good points about the fun and benefits of Parrot from the point of view
of a Pythoneer (It isn't much fun, mostly because of culture shock and
there don't appear to be any real benefits apart from the possibly
chimerical cross-language stuff), and worried about the amount of
optimization that was going on before we'd got any real languages
implemented. Andrew also suggested making Scheme one of the driving
languages for Parrot, based on its simple syntax and fully specced
semantics.
As a result of all this, Dan posted his list of `Parrot long-term
goals/prospects'; a 9 point list, with footnotes about where he sees
things going. I'm not going to summarize it because it's already its own
summary. Read it. There was some discussion about what the eventual
`pure parrot' build environment will look like, including some
optimistic copyright lines...
http://makeashorterlink.com/?G48625EB1
http://makeashorterlink.com/?E59651EB1
http://makeashorterlink.com/?J2A632EB1 -- A Pythoneer speaks
http://makeashorterlink.com/?B2B631EB1 -- Dan's list
Implementation of Lists for languages/scheme
J�gen B�mmels offered a patch implementing Scheme pairs, using simple
Arrays. Dan was impressed, and wondered how far we were from 'real'
scheme. J�rgen thinks we're quite some way away; we still need symbols,
strings, lexicals, functions, macros, continuations... Piers Cawley
outlined an OO way forward using (initially) hashes, and proposed a
'SchemeObject' PMC, which would hide a lot of the common structural code
needed for dispatching methods implemented in any of C/Parrot/Scheme.
John Porter, at his patronizing best pointed out that the hash bashed
approach seemed to be reinventing the wheel.
http://makeashorterlink.com/?O2C651EB1
Teasing notes
Dan announced that he was about to go dark for a while as a deadline of
his had just got a lot closer. However, he dropped a list of hints about
what was forthcoming. Bryan asked for some clarification of a few hints
(but they're *hints*, they're supposed to be a bit vague), and Dan went
and spoiled the mystery by giving him some.
http://makeashorterlink.com/?Q4D625EB1
Tinderbox turning green
Andy Dougherty noted that the recent work on portability and general
lint gathering meant that we were well on the way to a green tinderbox
(ie: automated builds are mostly working, yay!). Dan thought that gave
him an ideal opportunity to break things again by adding exceptions to
the mix. *Andy* then went a bit red, for assorted, faintly embarrassing
reasons, the patch that was meant to turn things green had been applied
and then inadvertently backed out. There's a moral here somewhere.
Actually there was a spate of inadvertent unpatching last week. People
are embarrassed and hopefully putting procedures in place to avoid
another spate.
http://makeashorterlink.com/?E6E631EB1
Perl 6 miscellany
Steve Fink offered a portmanteau patch for the Perl 6 compiler,
including such delights as a '-e' flag to perl6 so the one line script
folks could play. (First person to do the RSA one-liner in Perl 6 gets
*much* kudos from me). Sean wondered about a few of the other fixes, and
between them he and Steve found and squashed a bug with here docs, and
discussed ways of getting working Perl 6 patterns up and running.
http://makeashorterlink.com/?Z6F654EB1
Meanwhile, in perl6-language
Garrett Goebel reopened the `auto deserialization' thread from last week
(which ended up with the concept of "my Date $date .= new('June 25,
2002')" as the Damian approved idea). Garrett's confusion seemed to hang
on whether "my Date $date" and "my Date $date = Date->new()" were
equivalent. If they were, then a class which implemented its own
"operator:=" method could arrange things so that the originally proposed
"my Date $date = 'June 25, 2002'" would work.
Miko O'Sullivan proposed that, in the absence of a method name, ".="
should automagically call a "new_from_[class of object being passed]",
noted that golfers would love it. The consensus seems to be against this
particular bit of DWIMmery.
A subthread of this mammoth thread concerned multimethod dispatch. David
Wheeler wanted to know what it was, so Dan explained, and Damian pointed
at a Perl Journal article on the subject. This subthread ended up
spawning its own thread, when Miko wondered if multi
dispatch/overloading implied anything about runtime/compiletime. Dan
thought not, it was dependent on the language.
Quote of the thread: "I can still remember the precise moment I first
fell in love with polymorphism." -- Damian, in the TPJ article referred
to.
http://makeashorterlink.com/?B10721EB1
http://makeashorterlink.com/?N61742EB1
http://makeashorterlink.com/?H12722EB1 -- multimethods?
http://makeashorterlink.com/?X53743EB1 -- TPJ article
http://makeashorterlink.com/?R24712EB1
Class aliasing
The `auto deserialization' thread also spawned a discussion of Class
aliasing, but declined to change its subject line, making the life of a
summarizer *so* much easier...
Last week, Damian had proposed doing "class Date is
Really::Long::Package::Name::Ugh", ie. subclassing the long name into a
handy short name. Everyone else seemed to think he was proposing
aliasing a class name (which Damian later denied).
Uri Guttman certainly thought that Damian was talking about lexical
aliasing of classes (my mailer picks his post as this week's base for
this particular subthread). Trey Harris thought that Damian was talking
at about subclassing, and proposed "my class Date is
Really::Long::Package::Name::Ugh" which introduces a lexically scoped
subclass. Nicholas Clark wondered if "class Date :=
Really::Long::Package::Name::Ugh" would express aliasing of classes.
Damian thought it probably would, but noted that Larry hasn't said a
definite 'yes' to class name aliasing.
Brent Dax wondered if classes weren't in danger of becoming the `"new
filehandles" -- relatively limited entities with no sigils that confuse
the syntax horribly.' and pointed out an ambiguous case.
David Wheeler apologised to everyone for confusing inheritance and
aliasing in the first place, and the thread wound down to a close.
http://makeashorterlink.com/?D25752EB1
"@array = %hash"
Another thread from last week that rumbled on into this one.
The discussion of when hashes could have pairs as keys wouldn't go away.
Damian says that the "%hash = (...)" case is syntactic sugar and that
having a pair in an even slot of such a list would probably be an error.
I assume that this also applies in the case of "%hash = @array".
In a subthread, Piers Cawley told David Whipp that he hadn't actually
been joking when he proposed implementing the entire Smalltalk
Collection hierarchy and making it available in core Perl 6. Luke Palmer
liked the idea too. Dan saw no reason why such a thing should be
impossible either...
http://makeashorterlink.com/?A36721EB1
http://makeashorterlink.com/?T37723EB1
Atomicness and "\n"
Last week Damian reminded us of "$roundor7 = rx/<<roundascii>+[17]>/",
and Brent Dax wondered how one could be sure that "<roundascii>" is a
character class. Luke wondered if it mattered. The thread eventually led
Aaron Sherman to make a few proposals about User defined character
classes in regular expressions. Deborah Ariel Pickett wondered why we
still used "?" for non-greedy quantifiers, citing teachability reasons
for why we shouldn't.
http://makeashorterlink.com/?F28722EB1
http://makeashorterlink.com/?Y29713EB1
http://makeashorterlink.com/?P2A752EB1
Hypothetical variables and scope
Aaron Sherman announced that he was working on a library of rules and
subroutines for dealing with UNIX system files, mostly as mental
exercise to help with his understanding of Perl's new pattern features.
He wondered, in particular, about the scoping of hypothetical variables
in the presence of lexicals of the same name. For some reason this
turned into a minor argument about whether "my $x; / (\S*) { let $x =
.pos } \s* foo /", from Apocalypse 5, was a typo for "my $x; / (\S*) {
let $x := .pos } /". I'm not going to try to summarize the argument.
http://makeashorterlink.com/?U3B725EB1
Argument aliasing for subs
Pete Behroozi wondered about syntax for `allowing subroutines to have
many different names for the same argument', citing CGI.pm as an example
of such code in Perl 6. Damian thought that, if it were allowed, it
would be done with properties "sub hidden (..., int $force is
aka($override) ) {...}", (well, he did after he realised that his first
post on this issue was the result of posting after travelling 14,000
miles and giving 93 hours of talks in the space of 18 days, and was
somewhat flawed).
All this cunning use of "is" led Erik Steven Harrison (who should fix
his mailer so it does References or In-Reply-To properly) to wonder if
properties weren't being a little overused, and wondered if the is/but
distinction was still around. Damian thought not, and reiterated the
difference between "is" and "but" and when you would use each of them.
Erik also wondered what was wrong with "sub hidden ( int $force :=
$override ) {...}". Damian pointed out that it didn't play well with the
defaulting operator, "//=" in parameter declarations.
Peter Behroozi got confused about the difference between "$foo is
named('baz')" and "$foo is aka($baz)". ("named" changes the externally
visible name of a parameter, "aka" adds another external name for the
parameter).
The thread then morphed into a discussion of runtime and compiletime
properties. If you've not seen such a discussion before, the whole
thread is worth reading.
http://makeashorterlink.com/?R5C741EB1
Perl 6 parser, built in rules, etc.
Erik Steven Harrison wondered about backward compatibility issues with
changing Perl 6's grammar when the grammar rules are so exposed to the
user. Sean O'Rourke didn't think it was an issue yet. Dan told us that
the eventual Perl 6 grammar would be maintained in a backward compatible
way, with documented places for adding changes, and that this would be
maintained for as long as Larry say so.
http://makeashorterlink.com/?A6D721EB1
regex args and interpolation
David Whipp confused the heck out of me when he asked about `regex args
and interpolation'. I confess I can't for the life of me see what the
issue is that he's trying to get at. Ken Fox seemed to understand him
though, but wanted to know what the rule was that he was using in his
example code, and proposed a couple of implementations of it. Nicholas
Clark wondered about a section of Ken's post:
{ use grammar Perl::AbstractSyntax;
$0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
Specifically, what was that S-expression doing there? Piers Cawley
pointed out that S-expressions were a concise way of writing out an
AST's structure. Nick agreed, but pointed out that it was still in the
middle of a stream of Perl, but worked out that the "use grammar
Perl::AbstractSyntax" part of Ken's code meant that all bets were off.
At this point Nick's head threatened to explode at the wonderfulness of
it all.
http://makeashorterlink.com/?K1E762EB1
Defaulting params (reprise)
Miko O'Sullivan doesn't like "sub foo ( $arg //= 1 ) {...}" for
specifying default values for function arguments. He would rather have
"sub foo ( $arg is default(1) ) {...}". Damian pointed out that "is
default(...)" would be a compile time only thing, which didn't
necessarily make sense.
http://makeashorterlink.com/?D2F712EB1
Hypotheticals again
Jonathan Scott Duff wondered some more about hypotheticals and "let". He
wanted to know whether hypothetically binding to a lexically scoped
variable would also introduce that name into the match object. A strict
reading of Apocalypse 5 suggests that that isn't the case, which,
Jonathan points out, causes the programmer a few headaches. Damian
agreed that he'd like to see $0 contain keys for all the hypotheticals
used in a match, whether they came from the lexical scope or not. Damian
would also like them to turn up in "$o{'$name_with_dollar'" as well. So,
it seems that everyone's assumptions are aligned and we can carry on.
http://makeashorterlink.com/?Z20821EB1
First crack at Builtins.p6m
Aaron Sherman decided that what the world needs now is, at least, a set
of function signatures for everything that's in perl5's perlfunc
listing. He's even had a crack at implementing those functions where
possible. Aaron points out that he thinks of this file as documentation,
not code. People were impressed, and there's talk of using it to compile
down to the IMCC input as a base for hand optimizing. Aaron also
released a second version with more functions implemented and a slightly
different organization.
http://makeashorterlink.com/?U31821EB1
http://makeashorterlink.com/?E32812EB1
More A5/E5 questions
Jonathan Scott Duff asked a bunch of questions about the pattern engine,
and got a bunch of answers.
http://makeashorterlink.com/?R33822EB1
In brief
Leon Brocard wondered if the concatenation bug was fixed yet...
Leon also offered a patch implementing "chr", reckoning that, if we have
"ord" then symmetry demands "chr". Dan applied it, and Jerome Quelin
found a bug in his Befunge-93 interpreter which he thought was a bug in
the chr implmentation, but turned out not to be.
The Perl 6 compiler now does interpolated strings. Kudos to Joseph Ryan.
Josef H��k had a problem with "key_next" not behaving as expected within
multiarray.pmc. Tom Hughes pointed where expectation and reality
differed, and harmony was restored.
Kevin Falcone patched the glossary to include a definition of ICU.
Mike Lambert is having problems with the Perl 6 compiler under Windows.
Sean O'Rourke can't duplicate the problem. Anyone else tried this? More
information is welcomed.
Ken Fox and Damian continued their discussion of how one would munge the
current Perl 6 grammar.
John Williams wondered about doing reduce with "^+=". Damian can't
remember what side he argued when it came up last October, but is now of
the opinion that John's suggestion is a good idea.
Mr Nobody suggested some changes to the Apocalypse 5 pattern syntax for
reasons of length. Consensus seems to be that these changes aren't a
good idea.
Who's who in Perl 6
Who are you?
I'm Dan and... I design virtual machines.
What do you do for/with Perl 6?
I'm designing the virtual machine to compile and run it.
Where are you coming from?
A place about 70 miles east of here.
I started fiddling with computers with an Atari 800 (fully decked
out with a massive *48*K of RAM!) a long, long time ago. That lead
me to Atari BASIC, then to 6502 assembly, then to Forth. Then
(briefly) to college and Pascal and PL/I running under VM/CMS on an
OS/370 system.
From there I bounced to COBOL (on both RSTS/E and OS/370) and OS/370
assembly, and then to C under RSTS/E. I disliked C on first sight
(so of course that's what I spend most of my life writing now), and
it didn't get any better on my Amiga, though AREXX there was rather
nice. Wrote an article on AREXX for one of the now-dead Amiga
magazines, too.
My first real job in the industry was maintaining a horrid app
written in BASIC on RSTS/E (with the new bits written in BASIC/PLUS
2.6, which was a nice dialect of BASIC, and something I still like
better than C) and helping write a new system in Progress on Unix
boxen. (DG AViiON systems with the 88K series processor. Now there
was a sweet, and alas now dead, RISC processor)
That lead to writing C and SQL code on a VMS system, at which point
my fate was sealed, and I've been doing VMS admin and programming
sever since.
I first encountered Perl when looking for a guestbook for a
webserver we were running on one of the VMS boxes. It was, of
course, written in Perl, which meant grabbing a copy of perl. It was
one of the 5.003_9x releases and, since Dec C was significantly
pickier than any other C compiler at the time, I started shooting
patches for it to Chip.
That lead to my first XS module, and then to the second, and third
(and eighth, and tenth, and...). Oddly enough, I wrote my first
piece of Perl code about six months after my first patch to the perl
core (Charles Bailey wrote the Perl pieces for the first module I
did, and chunks of the XS) I ended up with the VMS maintenance hat
for a while, which has since been passed on, and I got snared by the
fun that was the first threading attempt for 5.005.
I ended up volunteering to coordinate the Perl 6 development at TPC
4, since everyone more competent had the good sense to run screaming
away from the job, and I've had it ever since.
When do you think Perl 6 will be released?
When it's done.
Why are you doing this?
Beats the heck out of me. Someone's got to.
You have 5 words. Describe yourself.
Tall enough, under the circumstances.
Do you have anything to declare?
Yes, absolutely.
Acknowledgments
This summary is dedicated to the memory of Gizmo, a cat of great
character, who we had to have put down on Saturday at the age of 17.
Chris Ball and Mark Fowler helped with proofreading this week. Thanks
chaps.
Once again, if you like the summary, please consider giving money to the
Perl foundation at http://donate.perl-foundation.org/, your money will
go to help fund the ongoing development of Perl 6.
This week's summary was, once again sponsored by the O'Reilly Network
who are paying the publication fee for the article directly to the Perl
Foundation.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
