This week on Perl 6, week ending 2003-04-06

Apr 6, 2003 by Piers Cawley

Welcome my friends to the show that never ends. Yes, it’s another of Piers Cawley’s risible attempts to summarize the week’s happenings in the Perl 6 development community. We start, as usual, with events in the perl6-internals world (not the perk6-internals world, obviously, that would be the sort of foolish typo that would never make it into any mail sent to the Perl 6 lists) where things have been quiet… too quiet. I think they’re planning something.

Documentation for PMCs

Alberto Simoes posted some documentation for the Array PMC and suggested somewhere for it to be included in the Parrot distribution.

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

Extension PMC vs built-in

K. Stol asked how to go about creating extension PMCs which he could use without having to recompile the entire Parrot VM. No answers yet.

http://groups.google.com/groups

Documentation problem with set_global

K Stol reported a problem with parrot_assembly.pod, apparently there was a disagreement between the docs and the code about set_global. Leopold Tötsch agreed that this was a documentation bug, but pointed out that it was far from being the only one. He suggested that parrot_assembly.pod should only have a general description of Parrot Assembly, with details of ‘real’ ops in generated docs like core_ops.pod and information on as yet unimplemented in the appropriate PDDs.

http://groups.google.com/groups

Building IMCC in Win32

Clinton A Pierce’s work last week to get IMCC building in a Win32 environment was admired by Leo Tötsch, who promised to check the needed patches into the distribution.

http://groups.google.com/groups

Typos in rx.ops

Cal Henderson submitted a patch to fix some typos in rx.ops, which were applied. Anton Berezin sent in a further patch to fix a few more errors.

http://groups.google.com/groups

Parrot regex engine

Benjamin Goldberg praised rx.ops, commenting that he was ‘amazed at how cool it is’ and wondered if the work was based on something else. Steve Fink thought it was original to Brent Dax. Steve also pointed to an unfinished draft of his detailed description of how at least one of Parrot’s regex implementations works.

http://groups.google.com/groups

http://0xdeadbeef.net/~sfink/uploads/regex.pod – Steve Fink’s description

Dan Explains Everything

Away from the internals list, Dan Sugalski has been doing some fascinating brain dumps about the ‘whys’ of Parrot in his weblog ‘Squawks of the Parrot’. Specifically, he’s been addressing why JVM and .NET weren’t chosen. In the course of this discussion he’s come up with a rather neat one sentence description of continuations: ``A continuation is essentially a closure that, in addition to closing over the lexical environment, also closes over the control chain.”

Anyway, I commend the whole blog to you.

http://www.sidhe.org/~dan/blog/

Meanwhile over in perl6-language

The perl6-language list was where all the action was this week with the list attracting far more traffic than the internals list at the moment.

How shall threads work in P6?

Austin Hastings has ‘been thinking about closures, continuations, and coroutines, and one of the interfering points has been threads.’ Austin wants to know what the Perl 6 threading model will look like, and threw out a few suggestions. Matthijs van Duin thought that preemptive threading in the core would be unnecessary, arguing that cooperative threading would solve everyone’s problems. Almost nobody agreed with him. Most tellingly, Dan disagreed with him. Parrot will be getting preemptive threads and that’s not a point for negotiation.

Larry popped up to point out that, at the language level, the underlying thread implementation (whether preemptive or cooperative) really didn’t matter, what was more important to the user was how much information was shared between threads. Larry said he thought that both the pthreads (all globals shared by default) and ithreads (all globals unshared by default) approaches to threading were ‘wrong to some extent’.

http://groups.google.com/groups

http://groups.google.com/groups

Conditional returnss?

Michael Lazzaro was concerned about the inefficiency of

    return result_of_big_long_calculation(...) 
        if result_of_big_long_calculation(...);

and ugliness of:

    my $x = result_of_big_long_calculation(...);
    return $x if $x;

He wondered if there was a less ugly way to do it in Perl 6. There is:

    given result_of_big_long_calculation(...) { return $_ when true }

was the most popular solution, but Dave Whipp pointed out that it would also be possible to write:

    sub return_if_true ($value) {
        if $value {
            leave where => caller(1), value => $value;
        }
    }

and then just do:

    return_if_true(result_of_big_long_calculation(...));

You know, I like Perl 6 more and more.

http://groups.google.com/groups

== vs. eq

Luke Palmer wondered if there was anything to be gained by getting rid of the distinction between == and eq and falling back to a polymorphic ==. Brent Dax pointed out that the ~~ ‘smartmatch’ operator did exactly that. Luke said that ~~ didn’t meet his needs (its behaviour with hashes, for instance, isn’t what you want when trying to find out if two hashes are equal). Smylers pointed out that Larry had already rejected (and had given good reasons why) the idea. Luke still wanted a ‘generic equality’ operator though. Marco Baringer threw a spanner in the works by pointing out that no such thing as ‘generic equality’ exists. Luke also came up with a symbol for an identity operator, =:= defined as:

    sub operator:=:= ( $a, $b ) { $a.id == $b.id }

Michael Lazzaro isn’t convinced of the need for a universal .id method, but he does like the idea of an identity test operator. There was then some discussion of

    \@a == \@b;

which, Michael claims would compare the lengths of @a and @b rather than their addresses. He backed this up with a quote from Larry where he said ``But it’s probably fair to say that $foo and @foo always behave identically in a scalar context”. I think Michael’s wrong because \@a is not the same as $a. By his argument it seems that even

    my $array_ref = \@foo;
    my $ary_ref2  = [1, 2, 3];

won’t work, which seems wrong somehow.

Discussion continued with various different possible implementations of ‘generic’ equality operators thrown up for consideration. One subthread even saw the return of Tom ``I thought he’d got a life and left the Perl community” Christiansen in a thread that ended up talking about transfinite numbers and the cardinality of infinite sets (which was interesting, but rather beside the point). Andy Wardley got bonus points for making me laugh: ``Gödel seems to think there is an answer, but he doesn’t know what it is. Turing is trying to work it out on a piece of paper, but he can’t say when (or if) he’ll be finished.” Okay, it may not make you laugh, but my degree is in maths.

http://groups.google.com/groups

http://groups.google.com/groups – Why generic equality doesn’t exist

is is overoverloaded?

Luke Palmer was concerned that is has too many meanings. It gets used for setting variable traits, defining base classes and setting up tied variables. Luke is concerned that these appear to be too varied in meaning, and proposed at least adding a new isa keyword for defining base classes. There was some discussion, but I’m not sure that either side is convinced of the other’s rectitude.

http://groups.google.com/groups

Short-circuiting user-defined operators

Joe Gottman wondered if there would be a way to write an operator which would short circuit in the same way as && and ||. He wondered if this would be a function trait (suggesting is short_circuit), or something cunning to do with parameters. Larry thought Joe was trying too hard, proposing:

    sub infix:!! ($lhs, &rhs) is equiv(&infix:||) {...}

He noted that if that couldn’t be made to work you might have to declare the operator as a macro, but that it still shouldn’t be too hard to implement. Dave Whipp wasn’t too sure about Larry’s assertion that declaring a parameter as &foo should force the RHS of that operator to be a closure. What, he wondered would happen with 10 !! &closure?

http://groups.google.com/groups

http://groups.google.com/groups

Ruminating RFC 93 - alphabet-blind pattern matching

Yary Hluchan has been reading the Perl 6 RFC 93, which Larry discussed in Apocalypse 5 and discussed doing regular expression type matches on streams of ‘things’, where the things weren’t necessarily Unicode characters. At one point though Larry popped up to say that the discussion seemed to run contrary to what he said about RFC 93 in Apocalypse 5.

Further down the thread, Ed Peschko wondered about using the Regex engine ‘in reverse’ to generate a list of all the possible strings that a regular expression could match. Everyone politely assumed that when Ed referred to the rule rx/a*/ he really meant rx/^a*$/ and got stuck into the problem. Matthijs van Duin pointed out that to get a ‘useful’ list of productions you’d have to go about producing all possible matches of length ‘n’ before giving any possibilities of length n+1 (where ‘length’ counts atoms I think…). Once Luke Palmer had that key insight he showed off an implementation that could generate such a list. Piers Cawley used Luke’s cunning implementation to show a lazy generate_all method that would iterate through all the possible productions of a rule. Luke said that he hoped it wouldn’t actually need such a wrapper to be lazy. Personally I think that might be a hope too far…

http://groups.google.com/groups

http://groups.google.com/groups – Luke’s code, with explication further down the thread

Named vs. Variadic Parameters

This thread continued from last week. The problem is that, if you want to define a function that you would call in the following fashion:

    foo $pos, opt_nam => 'value', 'slurpy', 'list', ...;

Then your signature needs to look like

    sub foo ( $pos, *@slurpy, +$opt_nam ) {...}

which seems rather counter intuitive (though mixing positional and non positional parameters could be seen to be counter intuitive whatever happens…) Various people argued for longer forms to denote the differences between positional, named, optional etc arguments and proposed various solutions. Larry didn’t sound all that convinced, pointing out that if you wanted to implement such parameter specification styles you could always use a macro and declared that ``Perl 6 is designed to allow cultural experimentation. You may reclassify any part of Perl 6 as a bike shed, and try to persuade other people to accept your taste in color schemes. Survival of the prettiest, and all that…”

http://groups.google.com/groups

http://groups.google.com/groups

Implicit threading

The discussion of how to write short circuiting operators spawned a subthread (which, rather annoyingly shared the same subject…) trigged by a suggestion of David Whipp’s to do lazy initialization of some variables by spawning subthreads. The idea being that one could do

   my $a is lazy := expensive_fn(...);

or something, and Perl would immediately spawn a subthread to calculate the value of expensive_fn(...) then, at the point you come to use the value of $a, the main thread would do a thread join and block if the subthread hadn’t finished. Austin Hastings liked the idea and went on to suggest other places in which implicit threading could be used. My gut feeling is that this is the sort of thing that will get implemented in a module on top of whatever explicit threading system we get in Perl 6.

http://groups.google.com/groups – Dave Whipp’s cunning idea

http://groups.google.com/groups – Further discussion here

Properties and Methods

Luke Palmer was concerned about potential naming clashes between properties and methods. He thought that things would be safer if, instead of accessing properties using method call type syntax. He was also worried about method naming clashes between the methods of things in a junction, and of the Junction class itself. Nobody had commented on this by the end of the week.

http://groups.google.com/groups

Patterns and Junctions

Adam D. Lopresto had a suggestion for using two different kinds of alternation in regular expressions. In Adam’s proposal, alternation with | could ignore the order of the alternatives when attempting to make a match and alternation with || would do the kind of order respecting alternation we’re used to. I confess that I wondered what on earth Adam was on about, but Luke Palmer liked the idea, pointing out a way something like it could be used for globally optimizing large grammars. However, he was unconvinced by the syntax and suggested that it would be better if we could mark rules as being ‘side effect free’ and thus capable of being run in arbitrary order.

http://groups.google.com/groups

Acknowledgements, Announcements and Apologies

The schedules for both OSCON and YAPC::USA have been announced and there’s a fair amount of Perl 6 and Parrot related content at both of them. I shall be attending both conferences (but only speaking at YAPC – about refactoring tools and about Pixie; the object persistence tool I work on, neither of which are Perl 6 related) and driving from YAPC to OSCON with probable stops in Washington DC, Philadelphia, Boston, Burlington VT, Ottawa and Chicago (where we cheat and hop on a train). Hopefully I’ll get to meet up with some of my happy readers at some or all of these stops and at the conferences.

http://www.yapc.org/America/ – YAPC

http://conferences.oreillynet.com/os2003/ – OSCON

I would like to apologize to Leon Brocard for failing to mention his name in this week’s summary. Leon is offering a ‘Little Languages in Parrot’ talk at OSCON though.

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

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

Tags

perl-6
perl-6-internals-parrot

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub