This fortnight on Perl 6, week ending 2003-11-23
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/groups?selm=Pine.LNX.4.58.0311100905190.15737@sprite.sidhe.org – Dan’s heads up
http://groups.google.com/groups?selm=Pine.LNX.4.58.0311121141090.28619@sprite.sidhe.org – Changes, draft 1
http://groups.google.com/groups?selm=a06010201bbdd728d2b16@%5B10.0.1.2%5D – 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/groups?selm=20031113173044.GB5924@stefp.dyndns.org
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/groups?selm=5.1.1.6.2.20031116195005.03c2c488@pop.mindspring.com
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/groups?selm=C5EC6699-18A1-11D8-92BE-000393A6B9DA@mac.com
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/groups?selm=5.1.1.6.2.20031117135818.021515f8@pop.mindspring.com
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/groups?selm=47906C10-1959-11D8-AC7B-0050E479991D@mac.com
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/groups?selm=Pine.LNX.4.58.0311191201490.7503@sprite.sidhe.org
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/groups?selm=m24qwzgj0y.fsf@helium.physik.uni-kl.de
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/groups?selm=20031120192528.GA6967@x-paste.de
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/groups?selm=20031121071225.GI26642@foxglove
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/groups?selm=Pine.LNX.4.58.0311211058540.29189@sprite.sidhe.org
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/groups?selm=Pine.LNX.4.58.0311211515220.29189@sprite.sidhe.org
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/groups?selm=5.1.1.6.2.20031122120034.02236230@pop.mindspring.com
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/groups?selm=20031110094753.GA14948@babylonia.flatirons.org
http://groups.google.com/groups?selm=20031119025313.GA10300@wall.org – 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/groups?selm=4.2.0.58.20031114234841.00aa39e0@rodadams.net
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/groups?selm=20031118142052.GA5735@babylonia.flatirons.org
http://groups.google.com/groups?selm=20031119181906.GD10300@wall.org – 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/groups?selm=20031118171859.GH3887@stefp.dyndns.org
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 p6summarizer@bofh.org.uk, 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”
Tags
Feedback
Something wrong with this article? Help us out by opening an issue or pull request on GitHub
