This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

The Perl 6 Summary for the week ending 20030504

Welcome my friends, to the show that never ends. Yes, another week, another Perl 6 Summary, chock full of condensed goodness, Leo Tötsch admiration and a smattering information about the design and development of Perl 6 and its target virtual machine, Parrot.

A quiet week this week. Even the hotbed of discussion that is perl6-language saw fewer than 100 messages. However, in accordance with tradition, I'll start with perl6-internals, which saw all of 47 messages this week, none of them from Leon Brocard.

External Data Interfaces draft PDD

Discussion of the External Data Interfaces PDD continues. Hopefully we'll see the first 'real' version soon.

PMC Keys

Alberto Simões asked for a good description of PMC Keys. No answer yet.

groups.google.com

Long option processing

Luke Palmer sent a patch to do long option parsing. Again, Warnock's Dilemma applies.

groups.google.com

Problem with readline

Will Coleda announced that he was dusting off his TCL project and found that it threw lots of bus errors. He tracked the problem down down to the readline op. Benjamin Goldberg realised that what was happening was that a filedescriptor was being used as a pointer to a FILE datastructure. Which is never going to be good. (This would never happen in a language with typed values. Well, it might, but the error would be caught before the bus error). No fix yet.

groups.google.com

Read buffering in PIO

Possibly prompted by Leon Brocard's nudge the week before, Dan Sugalski took another look at Jürgen Bömmels' rejected patch to add read buffering to the Parrot IO subsystem. Apparently there's a problem with a double free introduced by the patch. After some discussion (including a contribution from Melvin Smith, PIO's original author) of how to address the issue, Jürgen submitted another patch.

groups.google.com[192.168.0.78]

Excessive memory usage?

Peter Gibbs 'showed off' a short piece of PASM code that managed to use some 60Mb of memory and to allocate 1.5 million headers. He thought this a little excessive. No comment yet.

groups.google.com

Extending pop

Klaas-Jan Stol wondered if it would be useful to have a variant of pop which could pop multiple items off the runtime stack. Dan thought it as a good idea and added a bunch more useful tricks involving stack marks and things, and asked for volunteers to implement it. Nobody has explicitly stepped up to that particular plate...

groups.google.com

Clint Pierce shows off his 'mad NCI skeelz'

Clinton A Pierce has been playing with NCI on Win32 and has now got his Parrot BASIC calling Win32 functions natively. "Mua-hahahaha", as he so eloquently put it. He's now looking for a generic way to allocate a generic memory area in PASM for use as the target of a function, which should allow him to make even more Win32 calls without having to write an adaptor library in C first.

groups.google.com

Dan changes the calling conventions again.

Dan released the final set of calling conventions again. He thinks he won't have to do this again. Again. The changes are all in PDD03 (docs/pdds/pdd03_calling_conventions.pod in the CVS version of the Parrot distribution). The big change is that we no longer use the stack at all for passing parameters, we use an overflow array instead. The smaller change is that the PDD has been clarified somewhat.

groups.google.com[192.168.0.78]

And that about wraps it up for the internals mailing list. However, Dan has been publishing some handy stuff in a new "What the heck is ...?" series on his 'Squawks of the Parrot' website.

www.sidhe.org - Walking the stack

www.sidhe.org - Coroutines

Meanwhile, over in perl6-language

There was lots more about types. And some new stuff too...

"I thought there was no bool type?"

Towards the end of last week, Smylers queried the 'bool' entries in the latest draft of Michael Lazzaro's Type Conversion Matrix. The thing is, Larry has said that there won't be boolean type. Smylers was not the first person to make this comment, he probably won't be the last. The stock response is along the lines of "There's no bool type, but there is bool context." but according to Synopsis 6, this appears not to be the case anymore.

Then it all got a bit weird. Nobody quite asked "What is truth anyway?" but it was touch and go for a while as people discussed what the value of a bool would be in a numeric context. (I had a good deal of sympathy for the view that there should be some kind of warning...). We eventually ended up in a discussion of multistate logic (which, it seems to me is a candidate for 'something you implement in a module' status.), who knows where we'll end up this week.

groups.google.com

Headers

Paul Hodges wondered if it would be possible to write something in Perl 6 that worked in a similar way to the C Preprocessor's #include directive, allowing him to push a common set of use statements and other compile time declarations into a header file, which could then be shared by multiple bits of code. Various people suggested more or less tricky options, but Marco Baringer won the 'simplest thing that could possibly work' prize from your summarizer with:

    macro include ($file) {
      join '', <open $file>;
    }

which does the job very straightforwardly.

groups.google.com

Type Conversion Matrix (Take 3)

Michael Lazzaro posted his third attempt at a type conversion matrix. This triggered some discussion on the difference between primitive (int, float, etc) and 'full' types (Int, Float). Michael worried that some of the discussions were bloating primitives leading him to wonder what would be the point of using them if that happened.

It's apparent from the discussions here that the distinction between storage and value types enables a good deal of magic, but that scares people too.

groups.google.com

Property Inheritance

David Wheeler popped up with something of a head scratcher. He wanted to know whether, when a method is overridden in a subclass, the overridden method inherits the traits (he said properties, but he meant traits I think) of its SUPER method. Luke Palmer thought it probably depends on the trait, but his guess was that traits would be inherited. Which led David to wonder if that meant you could override traits in a child class.

groups.google.com

OO-overhead

For some reason, a discussion on structuring OO code in Perl 5 has been running in perl6-language for a while. It's handy for spotting issues, but not exactly on topic. It is to be hoped that Perl 6 will lose a lot of Perl 5's function and method call overhead though.

Chaining postconditionals

Michael Lazzaro asked for the rationale behind disallowing stuff like:

    return if <expr> for <list>

Short answer: Because Larry said so.

Supporting evidence (from the thread that developed anyway):

    foo $_ if baz for @list unless quux.next() while 1;

or:

    if $X {...} if $Y

groups.google.com

Coroutine calling convention

Luke Palmer kicked off some discussion of the various coroutine calling conventions that Dan had discussed on his Squawks of the Parrot website. Luke though that coroutines should return iterator objects instead of the yielded value. Which would mean they weren't actually coroutines...

groups.google.com

www.sidhe.org - Dan talks Coroutines

Acknowledgements, Announcements and Apologies

So, another summary draws to a close on a glorious May afternoon. Here's to the next one. Thanks to those people who sent the proof I asked for in the last summary. No thanks to the gits who outnumbered them by sending spam to the same address.

If you've appreciated this summary, please consider one or more of the following options:

--=-=-= Content-Disposition: attachment; filename=p6summary.2003-04-27.pod Content-Description: Summary for week ending 20030427

The Perl 6 Summary for the week ending 20030427

Welcome back to (I hope) a normal length summary of Perl 6 shenanigans after last week's bumper double length installment. (Thankfully traffic has been much lighter this week; I'm not sure I could cope with writing another epic.)

Perl6-internals was quiet again this week, but traffic does appear to be picking up a little.

IMC and Variable Number of Arguments

Following on from questions on this subject last week, Klaas-Jan Stol asked for some clarification of Parrot calling conventions as documented in Parrot Design Document (PDD) 03. In a subsequent post he noted that it seems strange that the current perl6 implementation (such as it is) doesn't follow the Parrot calling conventions. Sean O'Rourke shuffled his feet slightly and admitted that he'd chosen that method because "It was easiest", though he'd later rationalized that to "It doesn't matter for internal calls". Dan Sugalski pointed out that it was only a temporary aberration. Unless I missed something, nobody actually answered Klaas-Jan's initial questions.

groups.google.com

Short-lived memory allocation

Last week, in a discussion of the Garbage Collection (GC) system, Dan mentioned that Parrot GC would walk the system stack in order to build the Root Set (the list of memory 'nodes' that are initially known to be alive) which makes life a good deal easier for anyone allocating memory because they don't have to worry about explicitly attaching their shiny new buffer to the root set. Of course, it doesn't lessen the pain of whoever writes the GC system because, as Benjamin Goldberg pointed out, any system stack walking system is inherently unportable.

Benjamin was concerned that there may be systems where, not only could you not use the same stack walking code as was used everywhere else, but it would be impossible to walk the system stack at all. Dan admitted that there 'used to be' such systems, but asserted that, for Parrot's purposes "Either we get access to the C auto variable chain, or we can't run there." Kurt Stephens pointed at some deeply scary sounding (and gloriously non-portable) system stack walking methods which involve co opting the C stack pointer and collecting garbage from unlikely places...

If you're not sure what is meant by 'Walking the system stack' then you're not alone. Tim Howell asked for clarification and received it from Matt Fowles and Brent Dax.

groups.google.com

groups.google.com

PMC Documentation

Alberto Simões continued on his mission to document Parrot's various PMC classes. This week he offered up some Perlstring documentation

groups.google.com

The Native Call Interface (NCI) system.

Michael Collins has been playing around with calling C from Parrot and found the NCI system rather cumbersome. He wondered if the whole thing couldn't simply be implemented with a callcfunc opcode and showed a simple implementation of what he was driving at. Dan replied to this, explaining that he'd considered it but that it turns out not to be the Right Thing, and gave his reasons to do with encapsulation (when you call a PMC's method you shouldn't have to know whether it's written in C, PASM or Befunge) and issues with dynamic generation of stub functions. Michael wasn't entirely convinced by Dan's argument.

On the subject of NCI, Clinton A Pierce wondered if it is supposed to be Win32 capable and, if it was, what he needed to do to get it working as his first attempt had failed. Currently on the horns of Warnock's Dilemma.

groups.google.com

groups.google.com

use for p6c

Joseph F. Ryan resent his patch to implement use in Parrot's Perl 6 implementation, this time as a straight CVS diff on Steve Fink's request.

groups.google.com

Building on Win32

Matthia Barbon continued his sterling work on getting Parrot to play well with Win32, offering a couple of patches. Steve Fink applied them both.

groups.google.com

groups.google.com

External Data Interfaces draft PDD

Matthia Barbon redrafted Brent Dax's External Data Interfaces PDD based on the discussion of the original document. This elicited a few comments and I presume we can expect another, clarified draft at some point.

groups.google.com

PPC JIT questions

Peter Montagner has started to work on the Just In Time (JIT) system for the PowerPC architecture (a chap can get tired of making sure that every initialism is expanded at least once in a document you know. Still, it's been a few summaries since I last did anything like this) and had a couple of questions about its architecture and what he was allowed to do in PPC assembly. Dan answered, Peter asked for clarification; the usual give and take.

groups.google.com

A question about encoding

Speed junkie Luke Palmer (Hmm... that may not mean quite what I want it to mean) is working on the next iteration of string_str_search, which, apparently isn't fast enough (it's still slower than Perl 5). He had a few questions about encodings. Benjamin Goldberg offered answers and an entire function. Luke was impressed, but he still muttered about how much faster single byte searching could be (he's written a singlebyte/singlebyte search routine that goes slightly more than 2.5 times faster than Perl 5 apparently).

Later, Luke posted a new implementation of string_str_search which used his screamingly fast algorithm for single byte searching and a 'stupid, slow algorithm' for multibyte searches. Steve Fink applied the patch and asked for a unified diff next time as they are easier to read.

groups.google.com

groups.google.com

Leo Tötsch's iterator proposal

Remember Leo Tötsch's iterator proposal that received so little feedback a few weeks back? Steve Fink finally commented.

groups.google.com

uniq.pasm and Parrot IO

About a month ago, Jürgen Bömmels was doing some work on the moving Parrot's IO operators to use Parrot's own PIO asynchronous IO system, which broke Leon Brocard's uniq.pasm. Jürgen estimated that he might have it working 'next weekend'. This week Leon asked if any progress had been made yet.

groups.google.com

Meanwhile, over in perl6-language

The Type discussions continued. (Though I note, with some satisfaction that most of the discussions died down after I posted the summary. Maybe I got it right. Or not.)

Types

Michael Lazzaro's excellent summary of what we knew about Types served as the seed for this particular discussion, which was essentially a continuation by other title of the thread that started last week. Discussion centred on ways of specifying what sorts of type coercions should be automatic and which disallowed. Paul Hodges suggested use strict allow => { Int => Str, Foo => Bar } as a possibility, which doesn't quite work where you want to allow a type to convert to more than one possible target type, but it does look like a reasonable start.

There was also discussion of autocoercion to different types via a 'path' of coercions which looks to like it has enormous potential for complexity based nuisance. Michael Lazzaro reckoned that a lot of the chaining problems would go away if you drew a distinction between a 'lossless' coercion to a string and a serialization of something to a string for the purposes of debugging or whatever. (Coercing *from* a string to almost any other type but a numeric one seems to be the hard problem...)

Damian offered some thoughts about user defined coercions when he pointed out that a coercion is really an interaction between two classes and should therefore be implemented using a multimethod. He argued that things like Coercions were a strong argument for allowing return type to be incorporated into the multidispatch resolution mechanism. Others agreed that this would be a good thing, and we await a decision from Larry.

groups.google.com -- Seed

groups.google.com -- This week's 'root'

groups.google.com

Change in 'if' syntax

The Subject of the thread still thinks the discussion is about a change in the syntax of if, but it's actually about a change in how a block is recognized, which has knock on effects on on the syntax of various control structures, of which if is just one example. Various people balked (again) at the fact that the new rules for detecting a block mean that code like %foo {bar} no longer means "find the value associated with 'bar' in the hash %foo" but instead evaluates to a hash variable followed by a block, and probably a syntax error soon afterwards. Michael Lazzaro and Damian showed workarounds for this (%foo .{bar} and %foo{ bar} respectively) and Arcadi Shehter reminded everyone of the space eating _ that seems to have been completely forgotten since the last time this issue arose.

groups.google.com

anon-sub()'s execute in a for??

Paul Hodges took a crack at implementing for as a subroutine and came up with something that didn't look too insane. Luke Palmer added a refinement allowing for n at a time looping. However, for reasons that I can't quite put my finger on, I'm not quite sure that either method has got the sub signature quite right, and I'm not entirely sure how you would express for's signature as a Perl 6 signature anyway. Answers on a mailing list please.

groups.google.com

* vs **

Paul Hodges wondered about the * and ** flattening operators. He wondered if they were actually distinct operators or if the double variant was simply the result of applying * to the results of *@whatever. According to Larry, the two are distinct, the only difference between them is one of timing. I'm not sure I understood the distinction to be honest and I don't think I'm alone in this. Austin Hastings asked for an illustrative example, but we didn't see any before the end of the week.

groups.google.com

P6Objects: Hint's allegations and things unsaid

Austin Hastings' response to last week's mammoth Types discussion was a mammoth document of his own on what is currently known about Perl 6's Object Orientation features which was the result of trawling back through about two years of perl6-language postings. And jolly good it is too. It triggered a modest amount of discussion, but my theory is that everyone was too impressed to say much. I know I was.

groups.google.com

Storing program state for restarting

Ed Peschko wondered if it would be possible to serialize the state of a running program so that it could pick up where it left off after it died at the point of expiry. Dave Storrs suggested that, if one could just serialize the current continuation, the problem would become trivial (I'm not entirely sure he's right about that though; the current continuation seems to me to be in slightly the wrong place) and asked how one could do such a thing. The answer appears to be 'to the best of current research's knowledge, you can't generally do that, but we're working on it...'.

groups.google.com

C-struct style data reads

Paul Hodges doesn't like pack. What he wants to be able to do is something akin to C's:

    struct {
        int   someInt;
        float someFloat;
        char  strData[42];
        float otherFloat;
        char  moreStr[123]
    } buf;
    fread(buf, sizeof buf, 1, fp);
    printf("%.0f %s", buf.someFloat, buf.moreStr);

instead of unpacking a string with unpack "ifa43fa123" <$file> or whatever. This led to some discussion of appropriate syntax and the like, but it was generally felt that, even if something like this wasn't in the core, it wouldn't be too hard to implement it.

groups.google.com

Return types vs. Generic Programming

Michael Lazzaro wants the moon on a stick. In particular he wants to be able to declare:

   class Object { method CLONE returns MAGIC_TYPE {...} }

where MAGIC_TYPE is some magical token that means not having to declare

   class Whatever { method CLONE returns Whatever { .NEXT::CLONE } }
   class Whoever  { method CLONE returns Whoever  { .NEXT::CLONE } }

Quite what's wrong with

   class Object { method CLONE returns Object {...} }

is a mystery to me. Luke Palmer wants more than that. The insanity continued for several messages.

Do you get the feeling that I'm not a fan of this particular proposal? I confess I'm finding it very hard to summarize it any more than the above without exclamations of shock and dismay. So I'll stop now. Read the thread if you're interested.

groups.google.com

Type Conversion Matrix

Michael Lazzaro posted a matrix of some of the known built in types and of the possibilities of conversion between them, noting that what was shown were the conversions that it was possible to make automatic, not necessarily those which should be automatic. For some reason this led to a discussion of boolean types. Nope, I don't know why either.

Another subthread discussed which conversions were lossy and whether or not to make them automatic in the case of going from, say 'Int' to 'int'. (Int being a Perl Integer which could be undef and have properties and traits, and 'int' being, essentially, at least 32 bits of signed integer).

Michael posted a second take on the matrix with more information and with an additional 'Scalar' type added to it.

groups.google.com

groups.google.com

Fun with Junctions

Austin Hastings got faintly confused by the difference between 'all' and 'any' junctions. The rule of thumb appears to be 'if you want to use a junction to represent a set, use an "any" junction.'

groups.google.com

Fun with multi-dimensional arrays

Dave Whipp pointed everyone at a discussion of Perl 6 on Perlmonks, where people were implementing J H Conway's Game of Life in Perl. Dave had a some questions about tools for iterating over multidimensional arrays, suggesting some syntax as he went, then pulling it all together in a rather neat recalculation engine for the game of life.

Things got scary pretty quickly after that; at one point Dave even did a local redefinition of infix:= which certainly had me worried. Some clever stuff going on there and no mistake.

groups.google.com

www.perlmonks.org

Acknowledgements, Announcements and Apologies

That about wraps it up for this week.

If you've appreciated this summary, please consider one or more of the following options:

--=-=-=

-- Piers

--=-=-=--