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

Apr 13, 2003 by Piers Cawley

Another week passes, another summary gets written. How does he do it?

We start, as per usual with the still very quiet perl6-internals list.

hey sexy where you been?

The internals list’s normally impeccable spam filters failed slightly this week and we actually saw a couple of spam messages sent via the RT system. The problem is being looked into.

Support for true and false properties

Stéphane Payrard posted a ‘micropatch’ to support the true and false properties that are Perl 6 needs.

PMC elements() inaccessible from the assembler?

Stéphane also wondered about how he should access a PMC’s elements method via Parrot Assembly as there didn’t seem to be a an appropriate operator defined in core.ops. Leo Tötsch said that it was known that there were inconsistencies between vtable definitions and the ops files and that a major cleanup was needed which would probably happen once it became clean which vtable methods will remain and how core.ops needed to change.

http://groups.google.com/groups

Parrot on Win32

Clinton A Pierce announced that he’d built a Win32 Parrot distribution and had put a zip file up for downloading (and hopefully mirroring). He warned that it was very much a work in progress and the downloader should beware. But hey! Parrot on Win32! Bravo Clint!

In the same vein, Mattia Barbon posted a couple of patches to improve Win32 support.

http://groups.google.com/groups

http://geeksalad.org/tmp/Parrot_Dist_20030410.zip – Parrot on Win32!

http://groups.google.com/groups

http://groups.google.com/groups

Dan’s Blog

Dan Sugalski continues to post interesting stuff on his weblog, including a discussion of the challenges he faces in writing Parrot’s Object spec.

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

Meanwhile over in perl6-language

The internals list is still very quiet, seeing all of 28 messages. Meanwhile perl6-language saw over 200 messages. Maybe it had something to do with Allison and Damian’s Synopsis being posted on perl.com

http://www.perl.com/pub/2003/04/09/synopsis.html

Incorporating WhatIf

David Storrs had wondered about the CPAN module WhatIf which provides rollback functionality for arbitrary code. He wanted to know if support for this rollback capability could be added to the Perl 6 core. Luke Palmer liked the idea, and pointed to Larry’s discussion of let subcall() in one of the appendices to Apocalypse 6. Simon Cozens thought that ‘that way lies madness’ and wondered if we weren’t already a long way down that road. The thread got a little bit meta at this point, discussing what was and wasn’t a valid rationale for adding something to the core rather than just implementing it in a module. Austin Hastings rule of thumb (which seems to be a good one) is that something belongs in core if it ‘enables a paradigm’, citing rules, continuations, multidispatch, thread support and the new object system as examples of paradigm enabling stuff that belongs in core. Dan Sugalski’s rule of thumb is ‘does it provide extra utility at marginal cost?’ Spot the implementer.

It turns out that Larry’s rule of thumb is pretty much the same as Austin’s and he thinks we should add let funcall() to the core because ‘management of hypotheticality is the essence of logic programming’.

http://groups.google.com/groups

Whatif

http://groups.google.com/groups

== vs eq

The discussion of the meaning of

    \@a == \@b

continued. In particular, does it return true if @a and @b are bound to the same array, or does it return true simply if @a and @b have the same number of elements. John Williams noted that he was looking forward to Apocalypse 8, on references which would hopefully clarify a lot of these issues.

The Over overloading of is

Piers Cawley pointed out that the three different behaviours of ‘is’ that Luke Palmer had worried about the week before were all just examples of setting traits on containers and provided some code in an attempt to show what he meant. Luke Palmer wasn’t convinced (and I’m not entirely convinced myself) but thought it was probably best to reserve judgement until the Objects and Classes Apocalypse has been done.

http://groups.google.com/groups

Properties and Methods and Namespaces, oh my!

Piers Cawley tried to put Luke Palmer’s worries about clashes between method and property names to rest, and failed to do so. Luke wanted to have lexically and dynamically scoped properties, but that gave Dan Sugalski the screaming abdabs. Luke Palmer came up with anonymous properties, an idea which I particularly like:

    my $visited = Property.new;

    sub breadth_first_traversal($root can LinksInterface, &code) {
        my @queue is Queue = $root;
        for @queue {
            next if .$visited;
            $_ = $_ but $visited;
            code($_);
            push @queue: .links;
        }
    }

I don’t think any of the design team have commented on this particular idea but I think it’s lovely and I hope it gets rolled into the language.

http://groups.google.com/groups

globs?

Paul showed a lump of Perl 5 code that depended on globs to do bulk setting of attributes in hash based objects and wanted to know how one could do the same thing in Perl 6. Responses were along two lines, the first being that you wouldn’t be able to do that sort of thing at all with Perl 6 objects, and others pointing out that you didn’t really need a glob to get the example given to work. Paul was enlightened.

http://groups.google.com/groups

alphabet-blind pattern matching

The discussion of how to match streams of objects as well as simply strings of characters using the grammar engine continued with a new subject line. And it continued to make my head hurt. I particularly liked Larry’s observation that in ‘treating patterns as too powerful for just test […] we run the risk of making patterns to powerful for text’. Larry seemed to think that the idea of matching streams of objects with the grammar engine had merit though, which led to one of his wonderful ‘thinking aloud’ posts where he went through the various possibilities.

http://groups.google.com/groups

http://groups.google.com/groups – Larry thinks out loud ‘til his brain hurts

Synopsis questions

Angel Faus incurred the potential wrath of the summarizer by bundling up a whole host of questions relating to Synopsis 6 in a single post. Larry earned my undying gratitude by answering each question in a separate post with a new subject. Yay Larry.

As it happened the answers provoked very little in the way of discussion so I don’t really need to handle each question separately in this summary. Larry answered all the questions.

http://groups.google.com/groups

Variable/value type syntax

Ralph Mellor wasn’t keen on the syntax for declaring the types of values and variables and proposed a new syntax. People weren’t keen. I have the really strong feeling that whoever writes the Perl 6 introductory texts will have an interesting time explaining the difference between variable and value types. At least Luke Palmer had a moment of clarity when he realised why using is for tying made sense…

http://groups.google.com/groups

Currying questions

Ralph also wondered if currying assumptions could be overridden by passing the relevant argument by name when the curried function is called. Luke Palmer didn’t think it should be allowed. No call from the core design team yet.

http://groups.google.com/groups

Multimethod Invocants

Paul got confused by multimethods with multiple invocants and asked for clarification. Luke Palmer clarified things for him. The rule for multimethods is that multidispatch is only done on the invocants. Therefore a pair of declarations like:

    multi foo($me : Int $i)    {...}
    multi foo($me : String $s) {...}

would probably throw a compilation exception or at the very least a warning because of the collision between invocant types. If you really wanted to dispatch on the type of the second argument you’d have to write the method declarations as:

    multi foo($me, Int $i:)    {...}
    multi foo($me, String $s:) {...}

Larry pointed out that one generally calls multimethods as if they were subroutines, calling $obj.foo(1) would first try and find a method called foo, only falling back to multiple dispatch there were no such method to find. All of this engendered confusion in Michael Lazzaro (and in me if I’m honest, but now it’s been made clear, it makes sense).

http://groups.google.com/groups

Change in if syntax

Buddha Buck was caught out by the fact that, in Perl 6 you don’t need parentheses ‘round the test in an if statement and wondered when things had changed. Luke Palmer pointed out that they were now optional, a convenience bought by prohibiting whitespace between a variable and its subscript (so %foo {bar} does not look up the value associated with ‘bar’ in the %foo hash). Brent Dax hoped that this no whitespace rule was a simple tiebreaker, but Damian dashed that hope. The whitespace rule means that an opening brace after whitespace *always* denotes the beginning of a block or an anonymous hash. Some people don’t like this.

http://groups.google.com/groups

Named parameters are always optional?

John Siracusa wanted a way of creating a subroutine that would only accept named parameters, some or all of which are required. With Perl 6 as it stands, this appeared to be impossible without adding extra code to the body of the sub. Luke Palmer thought that what John wanted was silly, and suggested that if John really wanted the ability he should just write a module to do it. After a few posts back and forth on this, Austin Hastings pointed out that this discussion was analogous to the earlier discussion about WhatIf and what should and shouldn’t be in the core.He argued – by the ‘enables a paradigm’ rule of thumb – that there was no need for core support for requiring named arguments because it could be added easily with a module. John thought that adding this with a module meant that there would be no way to check parameters successfully at compilation time (actually, I think you could, with a suitably clever macro…).

By the end of the week John still wanted compulsory named arguments, but nobody else (who participated in the thread) seemed to be convinced that they were important enough to be implemented as part of the language.

http://groups.google.com/groups

Aliasing operations in Perl 6

Mark Jason Dominus asked for some clarification of the binding operator := and how it interacted with autodereferencing. Given code like:

    my $zero = 0;
    my $zeroref = \$zero;

    my $bound := $zeroref;

He wanted to know whether the value of $bound was 0 or \$zero. Damian answered that references only autodereferenced themselves in an array or hash context, so the $bound would be \$zero.

http://groups.google.com/groups

Acknowledgements, Announcements and Apologies

Leon Brocard does not make his traditional appearance in this summary as he is on holiday. Normal service will hopefully be resumed soon.

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

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