The Perl 6 Summary for the fortnight ending 20031123
Right, hopefully things are back to normal(ish) after the disk crashes
that rather spoilt the last summary. I've managed to fill in my mail
archive too so this summary will cover the events of the last fortnight
(that's two weeks for those whose version of English lacks this vital
unit of time).
We start, as usual, with all the action in perl6-internals.
Unifying call and return
It's been a long time coming, but Dan returned from LL3 suitably
refreshed by his dealings with academics ("You can [...] consider a a
sub PMC as a frozen semi-stateless continuation") and set about unifying
Parrot's call and return conventions. The strange thing is that
everyone's been wanting this for months now, but that didn't mean there
wasn't discussion.
Meanwhile Melvin Smith set about making this discussion moot (from the
point of view of someone targeting Parrot) by hiding the details behind
IMCC directives (which already happens admittedly, but Melvin's in the
process of renaming the ".pcc_*" directives to get rid of the ".pcc_"
and (eventually) allowing for pluggable calling conventions.
http://groups.google.com/[EMAIL PROTECTED] -- Dan's heads up
http://groups.google.com/[EMAIL PROTECTED] -- Changes, draft 1
http://groups.google.com/[EMAIL PROTECTED]
-- Dan puts his foot down
http://groups.google.com/groups?selm=5.1.1.6.2.20031115234124.020a7f60@
pop.mindspring.com -- Melvin Makes it Moot
Reviewing a book about VMs
St�phane Payrard bought a copy of "Virtual Machine Design and
Implementation in C++" and reviewed it for perl6-internals. He didn't
like it. Which is putting it mildly.
This led to the inevitable questions about finding good books on VM
design. St�phane quoted Leon Brocard's preemption of this question from
London.pm: "No, there's surprisingly little out there on virtual machine
design and development".
http://groups.google.com/[EMAIL PROTECTED]
IMCC gets high level sub call syntax
Melvin Smith continues to make PIR less like Assembly language and more
like pseudo code. You can now write code like:
_foo()
var = _foo()
var = _foo(a, b)
(var1, var2) = _foo(a, b)
and IMCC will do the Right Thing. Go Melvin.
http://groups.google.com/[EMAIL PROTECTED]
IMCC problems with library loading
Jeff Clites pointed out some issues with IMCC's behaviour when loading
external libraries and wondered about definitive docs on the macro
syntax (I think the current definitive docs may well be the source
code). Leo T�tsch seemed to accept that there were issues with the
current state of IMCC in this context, but implied that fixing it wasn't
an immediate priority.
http://groups.google.com/[EMAIL PROTECTED]
A new list proposal
Melvin Smith proposed creating a parrot-compilers mailing list as a
general purpose list for any and all language development targeting
Parrot. He even went so far as to volunteer to maintain and distribute
the FAQ.
The immediate response was positive, but Leo and others didn't really
think the volume of traffic currently warranted it (which, I think, was
part of Melvin's point, Parrot is reaching the point where it can just
be *used* without necessarily needing to worry over much about its
internals. I think Melvin is concerned that the technical level (and
implicit Perlcentricity) of the current internals list is putting
potential compiler developers off participating).
So, if you're reading this because you're interested in using Parrot as
a target platform, but you don't subscribe to the internals list but
would subscribe to a parrot-compilers list, could you let me, Melvin, or
the list know? I've already committed to including any such list in my
summaries (at least until traffic reaches the point where someone
decides to do a dedicated summary). Let us know if you think it's a
terrible idea too of course.
http://groups.google.com/[EMAIL PROTECTED]
Parrot Documentation Review
Michael Scott posted a review of Parrot documentation with pointers of
where to find existing docs and a discussion of where people *should* be
looking. Somewhat bizarrely, he failed to give the URL of the Parrot
Wiki, his favoured source of documentation (favoured for the very good
reason that it's excellent). However, you'll find the URL below.
http://groups.google.com/[EMAIL PROTECTED]
http://www.vendian.org/parrot/wiki/ -- The very lovely and worthwhile
parrot Wiki
Freeze is in
Dan announced that he's checked in Leo's preliminary patch implementing
freeze/thaw, commenting that it's likely to change dramatically
internally and that the vtable/low-level API wasn't final, but that the
op-level interface would be stable. Jeff Clites was initially concerned
that the patch used things he was expecting to be able to use for his
(in progress) ordered destruction patch. However, after some discussion,
he and Leo seem to be confident that the two things can be unified.
http://groups.google.com/[EMAIL PROTECTED]
Warning Patrol
J�rgen B�mmels has been doing a little warning patrol of parrot and
finds that only a very few fixes to IMCC are required to get a
warning-free compile and posted a patch with them in. Leo applied it
immediately, reasoning that, whilst IMCC's under heavy development,
there's no excuse for throwing compile warnings, and every time the
perpetrators have to integrate such patches they'll become more likely
to try not to generate the warnings in the first place.
Inspired by this, Jonathan Worthington posted a similar patch to
eliminate warnings when building for win32, which Leo also applied.
http://groups.google.com/[EMAIL PROTECTED]
Finished/stable parts of Parrot?
Robin Redeker wondered which bits of Parrot and IMCC could be considered
stable enough to use in implementing a language. Leo opined that
existing syntax will not change much, most of the expected changes
relate to things like adding support for calling conventions and
simplifications like replacing ".pcc_sub" with ".sub". Melvin Smith
pitched in with rather more detail about what was expected to change and
the kind of changes that could be expected in the future. Reading this
it's apparent that we've reached the point where almost any conceivable
extension to IMCC will be backward compatible with earlier versions.
Famous last words I know, but it is looking that way.
http://groups.google.com/[EMAIL PROTECTED]
Do Steve Fink's debugging for him
Steve Fink had a problem with some generated code throwing a segfault
when it was run and, having hit the debugging wall himself, posted the
code to the list and asked help. Leo tracked down the bug in Parrot and
fixed it. However, that's not why this made the summary, what's
interesting is the sample of code that the problem code was generated
from. Here it is:
rule thing() {
<[a-z]>+
}
rule parens() {
{ print "entering parens\n"; }
\( [ <thing> | <parens> | \s ]* \)
{ print "leaving parens\n"; }
}
sub main() {
my $t = "()()(((blah blah () blah))(blah))";
my $t2 = $t _ ")";
print "ok 8\n" if $t2 !~ /^ <parens> $/;
}
Looks tantalizing doesn't it? Someone's now going to tell me that the
code in question has been there forever, but I'm still tantalized.
http://groups.google.com/[EMAIL PROTECTED]
Another minor tasks for the interested
Dan discovered that a "make -j 4" dies quickly and horribly, which seems
to imply that there's a dependency or two missing from the nest of
twisty makefiles that make up the Parrot build system. He asked for
volunteers to fix things. There's been some work done on this, but no
definitive fix so far.
http://groups.google.com/[EMAIL PROTECTED]
Some PIR "How do I?" questions
Dan threw a list of questions about IMCC out to the list as things that
would really benefit from being documented. Sterling Hughes added a
question or two, and Melvin Smith volunteered to get the answers written
up real soon now.
http://groups.google.com/[EMAIL PROTECTED]
Bytecode portability and word/int sizes
Now that Parrot has the beginnings of freeze/thaw support, Melvin Smith
restarted discussion of ensuring that Parrot's bytecode format is
portable. He pointed at several issues that need resolving. Discussion
continues.
http://groups.google.com/[EMAIL PROTECTED]
Meanwhile, in perl6-language
Fun with 'multi'
Discussion of multi dispatch rolled on into the current summary period.
Luke Palmer pointed out that "multi" is no longer a declarator but a
modifier, allowing for fine-grained control of the 'scope' of a
method/function/whatever. Larry pointed out that 'multi' is orthogonal
to scope, saying simply "I'm putting multiple names into a spot that
would ordinarily demand a unique name." and went on to explain precisely
what that implied.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
-- Larry Clarifies
The Perl 6 design process
Rod Adams worried that all of the design of Perl 6 seems to come from
Larry and Damian, with the language list being relegated to asking
questions about how stuff works in more detail and in sniffing out
tricky bits. Taken in combination with the real world's nasty habit of
saddling Larry and Damian with health and financial problems, well, Rod
worries, and wonders if there's anything that can be done to improve
matters.
The redoubtable chromatic (who prefers it if I always render his name in
all lower case, even at the beginning of sentences, hence his becoming
redoubtable) gave the Standard Answer to such questions, pointing out
that the reason things are going through Larry is because, well, Larry's
bloody good at it. However, he did suggest that we're now at the point
where we can probably start turning existing design docs into story
cards and programmer tests for Perl 6, which should make implementation
a good deal easier, and pointed to the Perl XP Training Wiki as a good
place to look into how such tools are used to develop code.
http://groups.google.com/[EMAIL PROTECTED]
http://xptrain.perl-cw.com/ -- The Perl XP Training Wiki
Control flow variables
Luke Palmer doesn't like the repetition and ugliness inherent in code
like:
my $is_ok = 1;
for 0..6 -> $t
{ if abs(@new[$t] = @new[$t+1]) > 3 { $is_ok = 0; last } }
if $is_ok { push @moves: [$i, $j] }
and wondered if there was a Perl6ish way of eliminating $is_ok. He
suggested something like:
for 0..6 -> $t
{ if abs(@new[$t] - @new [$t+1]) > 3 { last }}
FINISH
{ push @moves: [$i, $j] }
Simon Cozens made a plea to eschew adding syntax to the language when it
would be better to find a general mechanism. He wondered if a better
approach may be to have "for" return a status, by analogy with Perl 6's
"if", which would allow one to write:
for 0..6 -> $t {
last if abs(@new[$t] - @new[$t+1] > 3;
} or push @moves: [$i, $j];
Which wasn't really well liked (I'm practicing my understatement here,
okay?) However, Simon's point about distinguishing between Perl 6 the
language and stuff that belongs in CP6AN (CPAN for Perl 6) was well made
and taken.
The thread's almost unsummarizable, it went off in so many different
directions, and elicited some good stuff from Larry about the thinking
behind Perl 6, along with a horde of solutions to Luke's problem. Some
of 'em even work in Perl 5, at the expense of some seriously ugly
looking code. Piers Cawley wrapped one solution, based on a guard clause
approach, up in a higher order function, but fumbled the ball on working
out the macro syntax, which pulled the discussion in another direction.
Meanwhile other subthreads led to discussions of generators, coroutines,
Mathematica's "Sow[]" and "Reap[]" and legitimate uses of "goto".
And Larry emphasised that nested modifiers are still quite illegal in
Standard Perl 6.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
-- Larry on language design
"s///" in string context should return the string
In another of those deceptively 'pregnant' posts, St�phane Payrard
proposed that "s///" in string context should return the string after
substitution. Austin Hastings proposed something scary, which led to
Larry contemplating making
$x.s/foo/bar/.s/moo/goo/;
work somehow. (Which is actually less scary than Austin's original
proposal). I think he rejected the idea for the time being though.
Piers Cawley suggested that it should return the substituted string,
with an appropriate boolean property set depending on whether any
substitutions were made. But then there issues of how you strip such
properties off if you want to use the standard boolean interpretations
of a string. Luke Palmer suggested the rather lovely "but nothing" meta
property.
I have the feeling that what's actually going to happen is that we'll
end up with a supplementary, non destructive form of "s///" which
doesn't alter the original string, but returns a new string with the
substitutions made.
http://groups.google.com/[EMAIL PROTECTED]
Acknowledgements, Apologies, Announcements
Sorry, we're a tad late again, sorry too to those of you reading this on
the mailing lists, I've not got 'round to reimplementing the software to
shorten the article URLs.
If you find these summaries useful or enjoyable you might like to show
your appreciation by contributing money or time to the Perl Foundation
and the Perl 6 effort. , or you could give me feedback directly at
[EMAIL PROTECTED], or stop by at my website.
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
http://www.bofh.org.uk:8080/ -- My website, "Just a Summary"
