| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
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.
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.
Stéphane Payrard posted a 'micropatch' to support the true and false properties that are Perl 6 needs.
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.
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.
geeksalad.org -- Parrot on Win32!
Dan Sugalski continues to post interesting stuff on his weblog, including a discussion of the challenges he faces in writing Parrot's Object spec.
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
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'.
search.cpan.org -- The WhatIf module
== vs eqThe 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.
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.
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.
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.
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.
groups.google.com -- Larry thinks out loud 'til his brain hurts
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.
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...
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.
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).
if syntaxBuddha 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.
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.
groups.google.com%[email protected]
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.
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: