This week on Perl 6, week ending 2003-03-16

Mar 16, 2003 by Piers Cawley

Spring is in the air, the Apocalypse is here (or imminent, depending on which sense of the word ‘Apocalypse’ you are using). We’ll start with perl6-internals as usual, before bracing ourselves for the increased volume and ploughing on into perl6-language.

Object Spec

Dan’s 3rd try at the Objects and Classes spec received a very small amount of further discussion this week. What there was mostly touched on the boundary between where the line is drawn between parrot’s object system and a particular language’s object system. The inference I draw from all this is that the next Object spec will be the final(ish) Parrot Object spec.

Parrot 0.0.10

Steve Fink instituted a Parrot feature freeze in the run up to 0.0.10 at the end of last week, aiming for a release on Saturday the 15th of March and noted that he was leaning toward “Juice” as a code name (punning on Leo Tötsch’s work on the imcc -Oj optimizations). David Cuny pointed out that there was already a virtual machine called Juice and suggested a whole list of possible code names. Leo Tötsch reckoned that calling it ‘Juice’ would be ‘too much honour’ and suggested a list of anagrams of ‘Parrot ten’. (“Partner to”, “Par Rotten” or “Tarte porn” anyone?).

It looks like we missed the release on the 15th, but Steve announced a release candidate on the 16th, in expectation of a release on the 17th.

http://groups.google.com/groups – Feature freeze

http://groups.google.com/groups – Release candidate announced

languages/BASIC reorg

Clinton A Pierce announced that he’d reorganized the languages/BASIC subtree into ‘compiled’ and ‘interpreted’ subtrees and noted that he was very impressed with the improvements in Parrot’s speed and memory management. Leo Tötsch pointed out a few issues with MANIFEST and the need for a Makefile, and wondered if Clinton had run things through IMCC.

http://groups.google.com/groups

The Judy algorithm

Tim Bunce pointed everyone at the Judy dynamic array code on Sourceforge and wondered if it would be useful for Parrot. (Judy is a high speed dynamic array implementation optimized for modern processor architectures apparently). Leo Tötsch thought it looked interesting and suggested that someone try wrapping Judy up in a PMC and running some performance tests. Elizabeth Mattijsen went and took a look and reported some issues with memory leakage and worried that the project looked ‘silent’. Tim mailed her concerns to Judy’s author who addressed them in his reply and admitted that he wasn’t that good at keeping the website up to date. He said that Judy had been ‘tested carefully not to have leakage’ and wondered if it might have been an issue with the tool Liz used to do the testing.

I await further developments with interest. If Judy can be made to work, it looks jolly quick.

http://groups.google.com/groups

http://judy.sourceforge.net/application/10minutes.htm

Yet another iterator proposal

Leo Tötsch posted a request for comments on what he called ‘yet another iterator proposal’. Nobody commented. I wonder if this means everyone liked it.

http://groups.google.com/groups

Parrot for Windows

Benjamin Goldberg wondered if there were any precompiled parrot binaries for Win32 available as he wants to be able to test parrot code without the current weird rites he has to go through (see his post for details). Clinton A Pierce put a snapshot build up on his site temporarily for Benjamin to download. Robert Spier offered space on www.parrotcode.org for a windows build when the next release comes out which Dan thought would be really cool. Dan also wondered about making an automated build farm but I think he may have a tuit shortage when it comes time to actually implement it. Joshua Hoblitt also offered to host binaries on his CPAN mirror. Clint said he’d be happy to make milestone binaries and wondered if there was a standard way such a distribution should be put together.

http://groups.google.com/groups

Moving to PIO

Jürgen Bömmels continued to make Dan happy by moving more file related opcodes from STDIO to Parrot’s PIO libraries. The latest ops to get his attention were open and close. Dan did a happy dance and applied the patch before wondering if we were subject to a code freeze (I don’t think so; it was feature freeze time).

http://rt.perl.org/rt2/Ticket/Display.html

IMCC and PDD03 (Calling conventions)

Leo has been thinking some more about the parrot calling conventions described in Parrot Design Document 3 and worried that they can’t actually be done. He proposed reducing the number of parameters that can be passed in registers in order to take pressure off the register allocator in IMCC. Dan agreed and quickly changed the PDD to take this into account. Leo then asked for some clarification on a couple of other issues that he was having a hard time understanding. Dan said that it was probably best to come back to these issues after he’d done PDD15 (The object spec). Leo agreed that objects will probably shed more light on the calling conventions and we all sat back to hang on Dan’s every object oriented word. Not that there’s any pressure at all.

http://groups.google.com/groups

Parrot extensions, or PMC versatility

Darren Duncan had some questions about PMCs and parrot extensions and what he should consider as he wrote a general persistence library. Dan and Benjamin Goldberg had some answers.

http://groups.google.com/groups

sun4 vtable JIT support

Jason Gloudon posted a patch adding support for vtable calls in the sun4/JIT and added support for some more ops. There appeared to be a few problems with the patch so it hasn’t been applied yet.

http://groups.google.com/groups

A fish, a barrel and a running joke

Leon Brocard made maintaining this particular running joke almost trivial this week by actually posting something. He’s implemented uniq(1) in parrot assembly, though he notes that it’s not very fast compared to GNU uniq(1) yet. Dan added it to the distribution in examples/assembly/.

http://groups.google.com/groups

Parrot reaches another milestone

Dan has decided that Parrot has reached the point where it should have a working install make target. He asked for someone to make it so. No takers so far, but he posted late on Sunday so maybe there will be news of this in the next summary.

http://groups.google.com/groups

Meanwhile, over in perl6-language

perl6-language saw 210 messages this week. Which I think is more than it’s seen in the last 3 or 4 weeks put together. Maybe it had something to do with the return of Damian Conway and the release of Apocalypse 6 (and the spectacularly short Apocalypse 7).

Statement modifiers

Matthijs van Duin wondered if the issue of multiple statement modifiers has been settled. The thread is long, and the answer is essentially (and authoritatively) “Yes, it’s settled. No, you can’t do it.” So, unless Larry changes his mind the point is moot. However, Matthijs does put his case very well, if you’re interested in this area I can recommend reading the thread.

http://groups.google.com/groups

http://archive.develooper.com/perl6-language%40perl.org/msg09331.html

Just when you get fed up of waiting for the Apocalypse…

Two come along at once.

Apocalypses 6 and 7 appeared online on Monday, a mere 9 months since the last one (Apocalypse 7 is all of two sentences long and is contained within Apocalypse 6, we’ll be ignoring it from now on). This Apocalypse covered closures, subs, functions, methods, types, signatures and pile of other good stuff. All the syntax introduced was spelled out neatly using Perl 6 rule notation, neatly showing off the power of the syntax introduced in Apocalypse 5. I would attempt to summarize it, but it’s already pretty dense so I suggest you all read it:

http://www.perl.com/pub/2003/03/07/apocalypse6.html

Now you’ve digested that, the rest of the summary should be easier to follow.

Damian returned to the list, though he’s only reading posts related to Apocalypse 6 and he’s pretty busy writing Exegesis 6 too so we’re not expecting vast amounts of posts from him.

Austin Hastings kicked off with the first question, wondering if the ’s’ in <psiglet> was silent. “Of course not.” says Larry.

Paul applauded the new macro feature (but Damian corrected his syntax).

S&M vs. B&D

Uri Guttman, displayed entirely too much knowledge about the difference between B&D and S&M asking if Larry shouldn’t have used B&D where he used S&M in the apocalypse. Austin Hastings knows too much too it appears, commenting that it depends on whether you consider strongly typed compile-type semantics as being restrictive or painful.

http://groups.google.com/groups

Can “is” properties be specified indirectly?

Austin Hastings wondered if there would be some way of differentiating between an array of constants and an array of variables. In other words, how would one specify an array which may be appended/pushed, but whose values cannot change or a hash to which you could add keys but not change existing entries. Damian thought that you’d have to subclass Array or Hash as appropriate. Luke Palmer wasn’t keen on this because then it would be easier to do something in C++ than in Perl, which isn’t the usual way of things.

http://groups.google.com/groups

is constant eq pass by value?

Uri Guttman was confused by the default parameter passing style for Perl 6 functions, is constant. A parameter variable declared with is constant is ‘locked’; you can’t use the same variable to hold a different value.

   sub some_func ($some_arg is constant) {
       $some_arg += 10;
       ...
       return $some_arg;
   }

To do that you need to declare the parameter with is copy. Uri noted that he really should keep his finger off the send button until he’s read the whole ‘megilla’, whatever one of those is.

http://groups.google.com/groups

Pipes

Michael Lazzaro declared that he thought the Apocalypse was great and that the ‘sig stuff is very, very nice.’ Then he asked about ‘pipes’ (the new <== and ==> operators which are almost, but not quite, entirely unlike the hypothetical ~> and <~ operators that were discussed so interminably a few summaries back). He wanted to know what was decided about some of the edge cases discussed in the appendix to the apocalypse (and had a comment to make about style). Damian pointed out that Michael’s edge cases all collapsed to two:

    @var <== LIST;
    LIST ==> @var;

Damian said that Larry was still unsure about these but that he (Damian) thought they would be allowed in, if only because

    @in ==> map  {...}
        ==> sort {...}
        ==> map  {...}
        ==> @out;

is a lot less ugly than

    @in ==> map  {...}
        ==> sort {...}
        ==> map  {...}
        ==> push @out;

or (John Williams suggestion)

    LIST ==> @var.STORE(*);

I have visions of the Perl 6 naysayers reading this section and muttering dark imprecations about the end of the Perl as we know it…

http://groups.google.com/groups

Complex Parameter Types

Michael Lazzaro wanted to know more about ‘complex’ type declarations. He wanted to know how these interacted with signatures, could one use arbitrarily complex types in subroutine signatures? Could one do multidispatch on them? He also had a question about when/whether types got coerced (that wasn’t actually his question, but it’s what it boiled down to) when functions were called.

The answer to the first two questions was straightforward: Yes, you can use arbitrarily complex types in function and multimethod signatures.

The third one proved a little trickier. Damian said that values would not be coerced, but Larry wasn’t so sure. He thought that coercion would be the right thing to do. Probably. Damian noted that the ‘Right Thing’ could well vary depending on whether the parameter in question was declared is constant/rw (in which case passing a parameter with the wrong type would be an error) or is copy (in which case coercion could be the thing to do). Austin Hastings wondered if this could be handled with a use strict 'params' type pragma, but Damian wasn’t convinced, arguing that the use of typed params automatically implied type stricture.

This thread gets horribly hard to summarize so, for now, I’ll just pick out some representative highlights.

Larry says that, in the absence of a pragma to the contrary type checking will be done at runtime if the type is unknown/unknowable at compile time, but he expects the B&D types to come up with a pragma that enforces compile time checking on pain of failed compilations.

Brent Dax came up with the concept of ‘strict’ and ‘loose’ argument typing. Strict arg typing doesn’t coerce except that, say, a Child can satisfy a requirement for a Parent. Loose arg typing will coerce wherever possible. He argued that the mechanism for choosing between strict and loose arg typing should be under the control of the caller rather than the callee, as that seemed to fit best with The Perl Way. Larry agreed with him. He added that the real question is whether the default use strict should include strict arg typing and noted that he was inclining toward the strict side. This week.

A subthread sprang up dealing with Type inference. David Whipp noted that a smart compiler might well be able to infer the type of some variables at compile time. The theory being that in the presence of good type inference some variables wouldn’t have to have a known type to avoid triggering compile time errors under strict arg typing. Angel Faus pointed out that using ‘user visible’ type inference wasn’t too good an idea because (among other reasons) it might lead to cases where a program only works as written for more recent versions of the compiler (which doesn’t mean that type inference is a bad idea; if the compiler knows the type of a variable it could potentially use that information to improve code performance).

My head started spinning when Larry seemed to imply that, not only is Int a Scalar, but a Scalar is also an Int. Or maybe it plays one on TV.

This thread is still very much underway as I write this summary, so attempting to summarize it is akin to summarizing a book when you’re halfway through it; you’re never quite sure what are the important bits. Hopefully things will be a little nearer resolution next week and you’ll get a more coherent summary of the conclusions.

http://groups.google.com/groups

http://groups.google.com/groups – the inference subthread

http://groups.google.com/groups – My head hurts

Signatures zones and line noise

Brent Dax wasn’t keen on the new syntax for declaring whether parameters were optional, positional, named or variadic (greedy) and wondered if we couldn’t use something prettier (wordier) with named traits ($x is optional etc). Damian thought that would be ‘uncomfortably prolix’ with default values ending up a long way from their owners. Paul and Brent proposed allowing

    multi substr(Str $str, $from = $CALLER::_ is optional
                           $len  = Inf is optional,
                           $new is optional) {
        ...
    }

but Damian pointed out that this could lead to badness because, in a signature the is would bind to the variable, but in a normal variable declaration and assignment the is would bind to the value, which would be confusing. There was some discussion of appropriate names for the other ‘linenoise’ in signatures, specifically the choice of name for the * type. The three front runners appear to be ‘variadic’, ‘greedy’ and ‘slurpy/slurpificatious’. I like ‘greedy’, but then I’m close to the person who proposed it.

http://groups.google.com/groups

In which Luke Palmer gets ignored

Luke Palmer had things to say about Appendix C of the apocalypse, specifically to do with temp/let and with caller and Continuations. Maybe what he said on these subjects was completely uncontroversial, but nobody has replied to either of them yet.

http://groups.google.com/groups – temp/let

http://groups.google.com/groups – Continuations

Multi promotion

Richard Proctor wondered what would happen if you declared a multimethod with the same name as a previously declared normal sub/method. Specifically he wanted to know if the new declaration would automagically turn the old one into a multimethod. Michael Lazzaro thought not. As did Damian and Larry. Damian provided a summary of the rules for subroutine/method dispatch, which look wonderfully subvertable. Piers Cawley wondered if it would be possible to get at a ‘dispatcher’ object and/or override it in a lexical scope, nothing that sometimes, he scares himself. Nicholas Clark seemed to think Piers wasn’t completely insane before going on to talk about wrapping and unwrapping in the case when the wrapper has itself been wrapped. Larry seemed to think that unwrapping should still do the right thing even if the wrapper being removed is itself wrapped.

http://groups.google.com/groups

http://groups.google.com/groups – Dispatch rules (OK?)

Wrappers vs. Efficiency

In the Apocalypse, Larry talked about the performance implications of generalized function wrappers and brought up the idea of subroutine traits which would mark a sub as unwrappable, giving is inline as an example. John Siracusa asked that whatever the ‘specific definition for speed’ is that forbids runtime wrapping, it shouldn’t be spelled ‘inline’ (though inline may imply “don’t wrap me please”). A few people agreed, but things mostly got left vague.

http://groups.google.com/groups

Macro invocants

Dave Whipp wondered about using macros to do things like:

    my Database $db = MySqlDatabase.connect(...);
    $db.select * FROM Foo WHERE Foo.bar LIKE a%b;

by implementing select as a macro. Larry thought so, but you would have to export the macro into the calling context. Larry added that you would probably implement that particular functionality by treating “.select” as an infix macro with a specially parsed argument on its right hand side (the SQL statement). David thought this was a little clunky and proposed macromethod as a way to avoid the export requirements. Luke Palmer was unconvinced and it went back and forth a few times.

Larry wasn’t convinced by David’s suggestion either, commenting that ‘mixing such compile-time semantics with a notation that supposedly mandates run-time dispatch is a recipe for a certain amount of confusion no matter how well we do it.’

http://groups.google.com/groups

Overloading multis on constness of parameters

Joe Gottman wondered if it would be possible to overload multimethods based on the const-ness of a parameter is the same way C++ does. The answer appears to be ‘yes’. Piers Cawley passed on a question from Greg MacCarroll about overloading on the value of a parameter. Damian thought probably not, but then showed a cunning trick involving overloading isa and a junction to allow something pretty similar. Luke Palmer was impressed.

I’m not entirely sure what it had to do with this particular thread, but Austin Hastings posted a chart of his understanding of the various dispatch rules. Worth reading.

http://groups.google.com/groups

http://groups.google.com/groups – Austin’s chart

Operators and context

Deborah Ariel Picket had some questions about Michael Lazzaro’s complete list of known Perl 6 operators, and wondered if this list should be extended to take context into account. She also wondered what the complete list of possible contexts was now. Michael reckoned that the list she pointed to was still current, but he expected to add the new <== and ==> ops. He also agreed that adding information about contextual behaviour would be a good (if daunting) thing to do. He noted too that Apocalypse 6 seems to imply that there would be a context for every type. Nothing definitive from Larry (or even Damian) yet.

http://groups.google.com/groups

http://archive.develooper.com/perl6-language@perl.org/msg12130.html – the current operators list

Assignment Overloading

Luke Palmer wondered if it would be possible to overload the assignment operator and wondered if the assignment operator was a value or a reference copy. Damian pointed out that *infix:= was really an operator on containers not values and you’d probably implement it by overloading STORE in the container’s class. He also commented that STORE might end up being spelled &infix:=. Copying is a shallow value copy.

Larry popped up to discuss the .copy method on SCALAR but I wasn’t entirely sure whether that gets called on the target container or the thing being copied. But that might just be me being confused.

http://groups.google.com/groups

P6FC

Aldo Calpini put up a tentative class hierarchy for Perl 6’s standard classes (he called them the Perl 6 Foundation Classes, narrowly avoiding a knee jerk response from at least one summarizer of this parish) and asked for comments. Murat Ünalan suggested that Aldo was posting to the wrong audience before suggesting that we adopt the .Net/Java object hierarchy, which confused Aldo somewhat, so Murat clarified what he meant. Simon Cozens made a few suggestions to Aldo about naming and missing classes. Larry added some clarifications on his thinking about the difference between types and classes.

http://groups.google.com/groups

http://dada.perl.it/p6fc.html – Aldo’s class diagram

http://groups.google.com/groups – Larry on types and classes

Thoughts about multiple properties

Chris Dutton wondered about using junctions for multiple properties so method bar is public is rw {...} could be written as method bar is public & rw {...} instead. Jonathan Scott Duff didn’t think that made much sense, and pointed out that the is is optional after the first, so you could write method bar is public rw {...} if you wanted. Larry noted that ‘that feature is still in Schrödinger’s little box.’

This led Mark Biggar to suggest some syntax for neatly defining groups of traits and complex types without having to go to the length of defining a class. Michael Lazzaro thought that Perl 6 classes wouldn’t be as heavyweight as they are in Perl 5 and did some WAGging (Wild Ass Guessing) about making subs that inherit from Sub which looked pretty good to me even if it did lead Austin Hastings to call Michael a ‘bad, evil man’.

http://groups.google.com/groups

Named vs. Variadic Parameters

Michael Lazzaro pointed up some issues with subroutines that have both variadic arguments and named arguments. Luke Palmer thought that there were two, mutually exclusive, ways of dealing with this: Michael’s proposed behaviour and the behaviour described in the Apocalypse. Luke was happy with the Apocalypse behaviour. Michael said that he hoped that whatever was decided, ‘broken’ function signatures would give rise to a compiler error.

http://groups.google.com/groups

is static?

Uri Guttman asked about static variables in Perl 6. In Perl 5 you can get a static variable by doing:

    {
        my $count = 0;

        sub sequence { return ++$count }
    }

Uri wanted to be able to do something like:

    sub sequence {
        my $count is static is default(0);
        return ++$count;
    }

Dave Whipp wondered if our did the job (it doesn’t). Larry mentioned that he didn’t particularly like ‘static’ as a name for this sort of variable and reckoned that, if there were an ‘is static’ declaration the compiler would probably translate:

    my $pi is static = 3;

to something like

    our $foo__Xdeadbeef will init {.set(3)}

Larry’s preferred syntax would be our $foo is unique, but he noted that ‘It’s not like someone isn’t going to implement “is static” the moment our back is turned anyway’.

http://groups.google.com/groups

No mandatory named arguments?

Nicholas Clark wondered if his reading of Apocalypse 6 was correct and that there is no way to specify mandatory named parameters. Larry agreed that this was so, but that one could finesse things at runtime with tricks like:

    sub foo(+$req = die 'You must supply a "req =>" argument') {...}

http://groups.google.com/groups

Acknowledgements, Announcements and Apologies

That about wraps it up for this week. Many thanks to Larry for giving us all something to talk about on perl6-language this week; I was starting to think about making the language list summary a fortnightly thing.

If you 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, job offers or a ‘get out of war free’ card to p6summarizer@bofh.org.uk

This week’s summary was again sponsored by Darren Duncan. Thanks Darren. If you’d like to become a summary sponsor, drop me a line at p6summarizer@bofh.org.uk.