This week on Perl 6, week ending 2003-05-11

May 11, 2003 by Piers Cawley

PEPPERPOT 1: Ooh look! It’s another Perl 6 summary!

PEPPERPOT 2: Well I never did! What’s in it this week?

PP 1: Ooh, I don’t know. Shall we have a look?

PP 2: Ooh yes.

Following a convoluted animation sequence involving surreality, fig leaves, classical statuary, and a cardboard cutout of an orange Leon Brocard, the camera pulls back to reveal a large bearded man, sat in a leather chair with a huge Apple PowerBook on his lap. PIERS looks from the screen to the camera and says

PIERS: I never wanted to be a summary writer. I wanted to be a lumberjack, leaping from tree to tree as they float down the mighty rivers of Briti… Ah… *ahem*.

PIERS comes to a stammering stop as he realises that quoting Python is so 20 years ago and that this year all the cool London.pm kids are quoting Buffy the Vampire Slayer instead.

Anyhoo.

As you may have gathered from the above introduction, it’s been fairly quiet this week. However, design, development and discussion continues. As usual we’ll start with perl6-internals.

Long option Processing

Towards the end of April, Luke Palmer had posted a patch implementing a long option processing subsystem for Parrot. After wondering if getopt_long was a standard function (it isn’t), Steve Fink applied the patch.

http://groups.google.com/groups

Excessive memory usage?

Leo Tötsch responded to Peter Gibbs’ question of the week before about Parrot’s apparently excessive memory use for a simple program. Leo and Peter batted the issue back and forth a few times in the process of tracking down the source of the problem. I think they got to the root of the problem, but I’m not sure if they’ve worked out a fix just yet.

http://groups.google.com/groups

NCI and handling of generic buffers of stuff

Last week Clinton A. Pierce had wondered about allocating blocks of ‘generic’ memory within Parrot for use as targets for native functions (in his case for calling Win32 functions). Piers Cawley wondered if it wouldn’t be possible to implement a scratch buffer PMC to manage such blocks of memory. Dan pointed out that this was exactly what the ‘unmanagedstruct’ PMC type was intended for, but Clint wasn’t sure that this did quite what he wanted and asked for more advice.

Later in the week Clint announced that he’d got UnManagedStruct PMCs doing some useful work, including allocating arbitrarily sized buffers from parrot assembly. People were impressed (In fact, Dan went so far as to call Clint his hero in his ‘Squawks of the Parrot’ weblog). However, Leo Tötsch pointed out that a good deal of the work that Clint had done on UnManagedStruct probably belonged on ManagedStruct instead. Apparently Clint (and Dan) hadn’t noticed that ManagedStruct existed. Hopefully now he’s had it pointed out to him, things will become a little more logical.

http://groups.google.com/groups

http://groups.google.com/groups

http://www.sidhe.org/~dan/blog/archives/000186.html

Calling convention changes

After Dan’s last set of changes to the Parrot calling conventions, Brent Dax wondered why we still had a user stack now that it was no longer being used for argument passing. Klaas-Jan Stol reckoned it was still useful and it would make targetting Parrot easier. Luke Palmer wondered if the user stack wouldn’t make it harder to implement an exception system.

Interestingly, Dan seems to be toying with having Parrot use Continuation Passing Style function calls at some point in the future. Who knows, maybe the next final calling conventions will mandate CPS (I confess, I rather like the idea myself…)

http://groups.google.com/groups

http://www.sidhe.org/~dan/blog/archives/000187.html

Building Parrot on windows

Getting Parrot working well in a Win32 environment seems to have been a Parrot theme over the last few weeks. This week Cal Henderson popped up with some problems getting things to link. The problem was tracked down quite quickly, and Cal ended up offering to do regular windows builds for the tinderbox system, though it looks like that’s not yet as easy as it could be. Apparently the standard Win32 make targets don’t quite build enough. I’m sure someone’s working on fixing this; getting Win32 into the tinderbox will be really handy.

http://groups.google.com/groups

IMCC vs. Parrot assembler

Zellyn Hunter wondered about how to choose between IMCC and the native parrot assembler. (Zellyn also presented me with a dilemma about which personal pronoun to use, which I solved by going and looking at his website. Unless ‘Leah’ turns out to be a chap’s name I think I’m safe). He also asked about the state of the documentation within CVS, and wondered which documents were still valid and which (if any) had been caught out by the march of development, suggesting a small meta document with information on the validity of the various docs (which begs the question of how one knows that the metadoc is up to date.)

The answer to the first question was ``Well, it depends”, with the rider that, unless you enjoyed doing your own register allocation, IMCC looked like the saner choice. Jerome Quelin pointed out that the Ook! compiler targets PASM, which seems to be in agreement with the whole sane/unsane thing.

http://groups.google.com/groups

More on stack walking

David Robins read Dan’s blog entry about stack walking and had a few questions about the details. He wanted to know what was done about false positives (ie, how do you know that something that looks like a pointer is a pointer), and what was done about object destruction. Dan replied that, in one of the Parrot GC system’s few conservative choices, Parrot GC took the view that if something in the system stack looks like a pointer then it’s safest to assume that it is a pointer and proceed on that basis. He also noted that, if a language required a specific order of object destruction then it was down to the language to handle that.

The usual spectre of timely closure of IO handles was raised again – Perl 5 guarantees that objects get destroyed (and therefore handles get closed) as soon as an object goes out of scope. This is somewhat harder to guarantee in a system that doesn’t use reference counting for garbage collection. Graham Barr commented that ``Anyone who depends on GC for the closing of file handles asks for all they get.“, which is certainly one way of approaching the issue, but it does rather fly in the face of the Perl 5 Way.

http://groups.google.com/groups

http://www.sidhe.org/~dan/blog/archives/000174.html – Dan explains stack walking

PIO work

Jürgen Bömmels continued his sterling work on the Parrot IO system (PIO), fixing up the problems with buffering and double frees etc that were mentioned last week.

sysinfo op

Dan added a sysinfo op which allows a running program to at least get some information about the machine it’s running on. Things are apparently somewhat spotty for various architectures that Dan didn’t have immediate access to, but there’s a framework in place now and patches are welcome.

http://groups.google.com/groups

Meanwhile in perl6-language

The language list was again busier than the internals list this week, but only just. Maybe we’re all waiting with bated breath for the next exegesis. Or maybe everyone’s exhausted. It can’t last though.

bool Type

Discussion of the hypothetical/non-existent bool type continued. I tried really hard to care.

Coroutine calling convention

As Luke Palmer continued to argue that Coroutines were a useless/dangerous bit of syntactic sugar and we’d be better using explicit iterator objects. Meanwhile, others discussed the various options for calling semantics in the case where Coroutines continued to look like coroutines instead of iterators. Damian Conway proposed another form of Coroutine calling convention. Damian proposed that yield return the ‘new’ arguments with which you ‘resumed’ the coroutine. This gives the programmer the option to handle different arguments however she likes. Piers Cawley liked the idea and posted a few snippets of code for implementing these semantics using continuations. He also suggested that it might be handy to be able to declare ‘Blocklike’ subroutines that were ‘return transparent’. I think the continuations scared people off because there has been no comment, even on the Blocklike subs idea.

http://groups.google.com/groups

http://groups.google.com/groups – Damian’s proposal

Include macro

Uri Guttman, may his name be forever mispronounced, responded to last week’s summary (instead of the original thread, bad Uri!) by pointing out that the simple minded include macro referred to in that summary was inefficient and proposed an optimization. This turned into a discussion of whether file reads should be ‘slurpy’ by default (Michael Lazzaro thought they should be, almost everyone else disagreed with him).

Then Damian popped up with his proposed Grand Unification of HERE docs, POD, and general file slurping, which looks very cool, but unfortunately, the unary << operator that Damian proposes to hang all this off seems to clash with Larry’s proposed use of <<list of words>> as a replacement for qw/.../. The idea was well received, and people started casting around for a sensible operator and adding other neat ideas to go with it. Damian won the ‘evil, evil, evil’ prize when, after <<< had been proposed as the file slurp operator, he came up with the idea of vectorizing it, which would lead to such delights as

    my($stdout, $stderr) = >><<<<< open 'grep foo * |';

Or, for the avoidance of headaches:

    my($stdout, $stderr) = >> <<< << open 'grep foo * |';

(I hate to think how one would write that in a POD C<…> escape).

This then turned into a discussion of whether <<...>> made sense as a replacement for qw<...>, especially given the perceived utility of Damian’s proposal.

Towards the end of the thread, Michael Lazzaro withdrew his contention that slurpy reads should be the default.

http://groups.google.com/groups

http://groups.google.com/groups – Conway’s Unified Here Theory

Acknowledgements, Announcements and Apologies

The camera pulls back from observing a computer screen on which the words ``The camera pulls back from…” are being typed and swings around to focus on the typist who looks up from the screen and addresses the camera.

PIERS: And so, by some extraordinary coincidence, fate, it seemed, had decided that you, my readers, should keep your appointment with the end of this summary. But what of the new technologies that had been spoken of?

AUDIENCE: Where *BLEEP*?

PIERS: In an empty house?

AUDIENCE: When *BLEEP*?

PIERS: In the middle of the night?

AUDIENCE: Best time!

PIERS: What diabolical plan had been shaped by Damian and Larry’s crazed imaginations? What indeed? From what had gone before it was clear that this was going to be…

AUDIENCE: a picnic?

PIERS: no picnic.

AUDIENCE: Awwwww!

The lights dim, the screen fades to white and the following words scroll up the screens of browsers the world over:

If you’ve 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 better framing device than terrible pastiches of Monty Python and the Rocky Horror Show to p6summarizer@bofh.org.uk. People suggesting an MST3K version of this summary can jolly well do it themselves.