Print
		Email article link

This Week on Perl 6, Week Ending 2004-09-03

Another week, a free weekend, and still I haven't started writing the summary until Monday. Still, I don't actually start at college 'til next week, so that's all right then.

We start with perl6-internals.

Compile op with return values

The discussion of how to return something from dynamically compiled code continued with Leo, Dan and Steve Fink all working to clarify and address the issues.

Compile op with return values

Library loading

Dan started the process of nailing down Parrot's dynamic loading API so that it can be added to the embedding interface. Steve Fink and Aaron Sherman had suggestions.

Library loading

Pathological register allocation scenarios

Gregor N Purdy had asked Dan if his work compiler could be made to spit out structurally equivalent C code to the Parrot code that was breaking IMCC. His idea being that we could then see how C compilers dealt with such nastiness. Dan thought that, whilst this was a good idea, it would be too much work to implement. Gregor wasn't so sure.

Pathological Register Allocation Scenarios

Dan and Leo demonstrate comic timing. Again.

14:17:09 GMT Dan: PerlHash test 20 is failing? Anyone know what's up
so we can fix it?
15:30:41 GMT Leo: It stopped failing at 15:55 CEST (13:55 GMT)
16:32:29 GMT Dan: D'oh!

Related Reading Perl 6 and Parrot Essentials, 2nd Edition By Allison Randal, Dan Sugalski, Leopold Tötsch Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

We love it when a patch comes together.

Failing perlhash test

PMC Instantiation

Leo had raised issues with the current scheme for PMC instantiation. This week Dan came through with some design which got discussed and (I think) implemented.

PMC Instantiation

Last bits of the basic math semantics

If you believe Barbie, "Math is hard". She's right, up to a point. The list's spent a couple of weeks now sorting out the design of Parrots underlying mathematical and numeric systems to make sure that maths works right (for sufficiently useful values of "right"). This particular line of discussion covers rotations and stuff, where you're actually treating a number as a bit field.

Last bits of the basic math semantics

Cross-compiling parrot

And you thought compiling Parrot on a Win32 box was hard. Robert Schwebel wants to cross compile Parrot and isn't having a good time. Dan wasn't surprised because the Parrot build process still gets most of its information from the local perl installation which will generally be wrong when you're cross compiling.

Dan noted that part of the problem is that we don't have people on the team with a need or the experience of doing cross compilation and added that he'd be thrilled if this were to change. Any patches to make things better for cross compilers will, of course, be gratefully received.

Cross-compiling Parrot?

Proposal for a new PMC layout and more

Leo's concerned that the current PMC layout isn't the Right Thing, and laid out a proposal describing some changes he thinks would be worthwhile. In essence, he argues for removing the requirement for fixed sized PMC headers and separate variable sized buffers in favour of unifying buffers and PMCs so that PMCs become variable sized, thus eliminating some time consuming indirection, and space consuming overheads.

Nicholas Clark thought the proposal was interesting, but said that, since the proposed changes would be invisible to the user, he'd be far happier with a functionally complete implementation of parrot with stable, useful APIs.

Dan rejected the proposal (both for technical reasons and because he agreed with Nicholas). I don't think Leo was convinced by the technical reasons, but the "Let's get the interfaces finished!" argument clinched it.

Leo's layout proposal

Dan explains why not

Semantics for regexes

Dan appears to have opened an entertaining can of worms when he outlined his view of the minimum string semantics required to support a regular expression engine and asked for comments. Boy did he get them. And boy did they run off in all sorts of strange directions. Interesting directions mind. Anyway, further down the thread, Dan, Chip Salzenburg and Patrick Michaud seemed to reach something approximating agreement about the low level semantics required.

Semantics for regexes

TODOs and calls for volunteers

Leo came up with a list of things that need fixing/implementing and asked for volunteers. These include sorting out what happens with the experimental ops, implementing new_extended for every PMC class and finishing up BigInt's MMD and vtable functions.

He also had some proposals for how we should get the Integer classes properly implemented now we know what the semantics will be.

TODOish fix ops

Takers wanted: new_extended

Takers wanted - BigInt/BigNum

Integer PMCs

Meanwhile, in perl6-language

Roles trying to be nice

Abhijit Mahabal had some questions about making roles work. Luke, Patrick, and Jonathan Scott Duff set about answering them. I'm not entirely sure that any of the answers so far are enough for Abhijit, but then I'm not entirely sure that any answer could be enough. At some point you have to take things on trust and hope that nothing breaks at runtime.

Roles trying to be nice

Pipeline performance

Rod Adams brought up some issues with the performance of "pipelining" arrays in Perl 5 — in general doing say grep {...} map {...} @ary is rather slower than writing an explicit loop. He wondered if Perl 6 would be faster. Larry's answer that all lists function lazily if they can in Perl 6 seems to imply that yes, Perl 6 will be faster.

Pipeline performance

Synopsis 9 draft 1

"Synopsis 9?" I hear you ask "But we haven't seen Apocalypse 9 yet!". Indeed we haven't, but that's not stopped Larry writing it. Synopsis 9 gives an overview of Perl 6's data structures (hopefully enough for anyone who happens to be starting work on a rough cut of a Perl 6 implementation) which will be covered in more detail when the Apocalypse itself comes out.

The usual storm of discussion and general proofreading goodness went on.

Synopsis 9 draft 1

The range operator

Joe Gottman wondered if there would be sufficiently lazy way to generate ranges. In particular, he wanted to know if he'd be able to write reverse (1..5) and have Perl handle that lazily, or if he could do 5 .. 1 :by(-1). Larry thought that, if range objects were made sufficiently smart, there would be no reason why the reverse approach couldn't be lazy.

Reverse .. operator

Can PRE and POST be removed from program flow?

John Siracusa wondered if it would be possible to turn off the PRE and POST Design By Contract hooks in production code to improve performance. (Leaving aside arguments about whether this is sensible; personally I reckon that a production environment is where you should be most worried about values that might fail the PRE/POST hooks). Larry reckoned it would be possible to simply clobber the global definitions of PRE and POST to make them no ops. This wasn't enough for John, who wanted to be able to get rid of them entirely so even the call to the no op didn't happen. So Damian showed him the obvious macros...

S4: Can PRE and POST be removed from program flow?

Announcements, Apologies, Acknowledgements

It looks like the Google groups gateway is working again, so I'll keep with the Google style linking.

If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send feedback or contributions to a getting Piers to OSCON 2005 fund.

The Perl Foundation

Perl 6 Development site

Or, you can check out my website.

Contact Us | Advertise with Us | Privacy Policy | Press Center | Jobs | Submissions Guidelines

Copyright © 2000-2004 O’Reilly Media, Inc. All Rights Reserved.
All trademarks and registered trademarks appearing on the O'Reilly Network are the property of their respective owners.

For problems or assistance with this site, email