This Week in Perl 6, through August 2, 2005
by Piers Cawley
|
Pages: 1, 2, 3
Meanwhile, in perl6-language
The Use and Abuse of Liskov
Damian and Luke's discussion of the right way to do MMD looks to be finally winding down. It seems Luke's convinced Damian of the righteousness of his cause. (Or at least, if he's wrong, he's wrong in a subtler way than Damian realized.) I don't think there's been a final decision as yet, but we're definitely moving forward.
Slurpy Parameters and Auto-Flattening
Ingo Blechschmidt asked for some clarification of the behavior of slurpy parameters. It's not often I hope that Luke is wrong, but I really hope the answer he gave Ingo isn't the true state of things.
Exposing the Garbage Collector
Bah! I propose a simple, slow, yet powerful feature that is useful to implement a whole bunch of other possible APIs for getting at stuff, and people go and suggest making any one of various heavier APIs the One True API. It's enough to make a person despair.
Ah, apologies, I'm letting personal concerns get in the way of the summary, but what the hell, I'm leaving it.
Messing with the Type Hierarchy
Luke had a few things to say about what happens when you monkey with the type hierarchy, so he said them. The usual suspects joined in, most of them addressing the particular instance that Luke had chosen to illustrate his point, rather than discussing the broader point, but hey, this is perl6-language. That's what happens.
Luke's broader question was, "Should it be possible to write a class that
isn't a leaf in the existing hierarchy?" The example that everyone addressed
was the idea of writing a Complex class that wedged in between
Real and Num in the hierarchy (which, as several
people pointed out, isn't necessarily the right way to think about it anyway,
hence the discussion).
My gut feeling was that the answer to the general question should be "Yes, but be very, very careful, and don't be surprise if it bites you later."
Elimination
of Item|Pair and Any|Junction
The discussion of appropriate default prototypes and the like continued.
Autrijus proposed a way of rejigging the type hierarchy to make default
argument types a little clearer. I found things getting a little weird, to be
honest--there's even talk of eliminating Object as a type name,
which seems a little strange.
Execution Platform Object? Gestalt?
Randal proposed that, as the number of possible platforms that Perl 6 can
run on proliferates, it'd be really handy if there were some useful global that
held knowledge about the platform and its capabilities. He proposed
$*OS as a decent place to put it. Larry thought we probably would
have something like that, but thought that there might end up being two
globals: $*OS and $*VM. The usual "Why don't we call
it" thread sprang up, but it seems that the most important upshot is that
this particular bike shed will definitely be painted.
The
Meaning of returns
The continuing invasion by the rampaging hordes from p6c continued apace.
This time, Autrijus had a discussion on the implications of returns
and its implications for type inferencing.
Lazy List Syntax
Flavio S. Glock wondered how to go about creating a lazy list from an
object. Apparently the magic he was missing was prefix:=, which is
syntactic sugar for calling the .next method on anything that
supports iteration, which is nice.
An
Idea for Doing pack
David Formosa had an idea about a possible pack API; he
outlined it on the list. Yuval Kogman seemed to like it, but there's been
nothing from anyone else on the list.
Inferring
(Foo of Int).does(Foo of Any)
Autrijus again, this time thinking about the kind of type inferences that Perl aggregate types allow. Once I had my head in the right space, it made a great deal of sense, even if:
Array of Item).does(Array of Int); # false
Array of Int).does(Array of Item); # also false!made my head hurt the first time I read it.
Garbage Collector API
Various people proposed additions to the proposed Garbage Collector API.
$value.confess()
Brent Royal-Gordon had a cunning idea for debugging: having Perl 6 capture
the call stack at its point of creation and stashing that in a property
called confess, which he could examine in a debugging context to
find out where a value came from. As he pointed out, this would be expensive,
but useful. He's currently Warnocked, but I get the feeling it should be
possible to write an extension to do what he wants without adding anything
extra to Perl 6 itself. It might be a little tricky if he wants the call stack
to change on mutation, though.
Slurpy
is rw Arrays
Having received clarification of the behavior of normal slurpy arrays, Ingo
Blechschmidt asked for clarification of the behavior of Slurp is
rw arrays. Adriano Ferreira and Thomas Sandlaß seemed to talk
sense in reply.
Curious
Use of .assuming in S06
Autrijus wondered if code like:
&textfrom := &substr.assuming(:str($text) :len(Inf))found in Synopsis 6 was a mistake, or if the syntax should be like that. It turns out that the syntax is supposed to be like that. Apparently being able to do without the commas was one of the reasons for making colon pair syntax look like that.
Laziness and IO
In a currently Warnocked post, David Formosa outlined a potential problem with lazy IO.
sub
foo ($x) returns ref($x)
In his continuing discussion of the Perl 6 type system and the inferences that you can draw about it, Autrijus posted a discussion of how to declare that a function that returns a value with the same type as its argument. He suggested that the best way forward would be to declare something like:
sub identity ($x) returns ref($x) { ... }and asked for better suggestions. Thomas Sandlaß had suggestions.
