This week on Perl 6 (9/16 - 9/22, 2002)
by Piers CawleySeptember 22, 2002
So, another week, another Perl 6 summary. Let's see if I can get through this one without calling Tim Bunce 'Tim Bunch' shall we? Or maybe I should leave a couple of deliberate errors in as a less than cunning ploy to get more feedback. Hmmm.
So, kicking off with the internals list as always:
The Compound Key discussions continue
Dan Sugalski, Graham Barr and Leopold Toetsch (who, incidentally,
turned 44 on the 16th, so not only does he contribute really useful
code, he makes Dan and I feel younger. Can this man do no wrong?) all
thought hard about Ken Fox's Hard Question from last week. The Hard
Question was: `If %h{"a"}[0][1] is a PASM P2["a";0;1], then what
is %h{"a"}{0}[1]?'. Leo thought that things would work because an
integer isn't a valid key type for a hash, so the second case would throw
a `Not a string' error. Dan thought that this might not be enough, so
we probably need an extra flag to designate whether a key element
should be taken as an array or hash lookup. Graham Barr agreed, citing
the `hash with objects as keys' example that seems to crop up
everywhere, and suggesting the rather lovely looking my @array is
indexed('a'..'b'); as another possibility. Graham also wondered how
the flag should be used, suggesting that it should get passed into a
vtable's lookup method, thus allowing the writing of PMCs that don't
care how they're looked up, or other PMCs that did cunning things
depending on how they were accessed. Dan agreed.
http://groups.google.com/groups
Return undef for negative indices
Sean O'Rourke supplied a patch that arranged for @ary[-1000], say,
to give undef when @ary has fewer than 1000 elements. Also
included was a patch which changed array's get_string() method to
return the array's get_integer() value converted to a string. Leo
Toetsch wasn't keen on this idea, wondering if it shouldn't return
something like "PerlArray(0xaddr)" by analogy with the behaviour of
PerlHash PMCs. Sean disagreed, pointing out that in Perl5 one could
say print "You scored $score out of" . @questions . "questions.",
and the array would stringify to the number of elements it
contained. Brent Dax pointed out that in Perl 6 one would have to
write print '\@foo has ' _ +@foo _ ' elements'; because Perl 6
arrays stringify to their elements, separated by
.prop{sep} //= ' '. Sean didn't like this, but appeared to take the
point. Uri Guttman quibbled about style, and proposed print "\@foo
has $(@foo.length) elements";, which certainly does a good job of
making its intention explicit.
http://rt.perl.org/rt2/Ticket/Display.html
A Lexicals pre-patch
Sean O'Rourke was unhappy with the current lexical implementation, as
it doesn't seem to support different levels of static
nesting. Apparently this makes nested scopes hard to implement,
especially in the presence of Perl 6's %MY magic. So he sent a
patch for people to play with.
Jonathan Sillito liked the patch, and pointed to a different approach that would make taking closures easier, but which would possibly make lookup slightly less efficient. Sean wondered how Jon's scheme would handle recursion. Jon thought about that, and answered by outlining how you would implement closures using Sean's scheme, and proposing that Sean make a 'real' patch.
Jürgen oumlmmels had a pile of questions too, related to using Sean's patch to implement proper Scheme functions, and he proposed a set of ops for manipulating pads. Sean agreed that this looked useful.
http://groups.google.com/groups
http://groups.google.com/groups
http://groups.google.com/groups
default.pmc patches
Leopold Toetsch patched default.pmc to make almost all methods
throw meaningful exceptions. Sean O'Rourke reckoned that the patch
went a bit far, proposing a few places where having a slightly richer
default behaviour would be the Right Thing to do, and some others
where doing nothing was the right default behaviour -- the example given
was init. Leo countered that one should really have a
default_scalar.pmc for the first types, and that, for the second
type, the PMC should have an explicitly empty method. The thread
resembled the Monty Python Argument skit for a few messages (`Look,
this isn't a proper argument!', `Yes it is!', `No it isn't it's just
contradiction!'). After a couple of rounds of this, Sean showed his
(substantial) list of default behaviours that he thinks should be in
default.pmc, and Leo showed us his planned PMC hierarchy.
Dan came down on Leo's side.
http://rt.perl.org/rt2/Ticket/Display.html
http://groups.google.com/groups -- Sean's list
http://groups.google.com/groups -- Leo's hierarchy
Keyed ops
Has there been a week since I started doing these summaries that hasn't seen a discussion of keys, keyed ops or key structures? This week's second keys thread was kicked off by Leopold Toetsch wondering about the legality of, for example:
add P0[P1], P2, P3[P4]If it is legal, what PASM ops should be generated. The problem is that the naive approach of using an op based on the argument list would lead to a horrible explosion of specific opcodes to deal with the possible combinations of keyed and unkeyed arguments. Leo wondered if the instruction should get turned into:
add P0[P1], P2[<The Null Key>], P3[P4]Tom Hughes and Leo batted this back and forth for a bit. Tom noted that it wouldn't be hard to create a null key: just create a key with 0 elements for every PMC that didn't otherwise have a key structure, but he still worried that we were looking at 64 different op codes for each 3 argument op.
Sean O'Rourke pointed out that if scratchpads do become `proper'
PMCs, then the various 3 argument keyed ops would become remarkably
useful. For instance @a[0] = %b{1} + $c could become
add P0["@a0";0], P0["%b";1], P0["$c"]But Tom wasn't sure that this quite fit in with Leo's plan. Leo meanwhile produced an RFC with his proposals for how keyed opcodes should look.
http://groups.google.com/groups
http://groups.google.com/groups
Pages: 1, 2 |
