The Perl 6 Summary for the week ending 20030316
Spring is in the air, the Apocalypse is here (or imminent, depending on
which sense of the word 'Apocalypse' you are using). We'll start with
perl6-internals as usual, before bracing ourselves for the increased
volume and ploughing on into perl6-language.
Object Spec
Dan's 3rd try at the Objects and Classes spec received a very small
amount of further discussion this week. What there was mostly touched on
the boundary between where the line is drawn between parrot's object
system and a particular language's object system. The inference I draw
from all this is that the next Object spec will be the final(ish) Parrot
Object spec.
Parrot 0.0.10
Steve Fink instituted a Parrot feature freeze in the run up to 0.0.10 at
the end of last week, aiming for a release on Saturday the 15th of March
and noted that he was leaning toward "Juice" as a code name (punning on
Leo Tötsch's work on the "imcc -Oj" optimizations). David Cuny pointed
out that there was already a virtual machine called Juice and suggested
a whole list of possible code names. Leo Tötsch reckoned that calling it
'Juice' would be 'too much honour' and suggested a list of anagrams of
'Parrot ten'. ("Partner to", "Par Rotten" or "Tarte porn" anyone?).
It looks like we missed the release on the 15th, but Steve announced a
release candidate on the 16th, in expectation of a release on the 17th.
http://makeashorterlink.com/?E133153C3 -- Feature freeze
http://makeashorterlink.com/?F353239D3 -- Release candidate announced
languages/BASIC reorg
Clinton A Pierce announced that he'd reorganized the languages/BASIC
subtree into 'compiled' and 'interpreted' subtrees and noted that he was
very impressed with the improvements in Parrot's speed and memory
management. Leo Tötsch pointed out a few issues with MANIFEST and the
need for a Makefile, and wondered if Clinton had run things through
IMCC.
http://makeashorterlink.com/?J263219D3
The Judy algorithm
Tim Bunce pointed everyone at the Judy dynamic array code on Sourceforge
and wondered if it would be useful for Parrot. (Judy is a high speed
dynamic array implementation optimized for modern processor
architectures apparently). Leo Tötsch thought it looked interesting and
suggested that someone try wrapping Judy up in a PMC and running some
performance tests. Elizabeth Mattijsen went and took a look and reported
some issues with memory leakage and worried that the project looked
'silent'. Tim mailed her concerns to Judy's author who addressed them in
his reply and admitted that he wasn't that good at keeping the website
up to date. He said that Judy had been 'tested carefully not to have
leakage' and wondered if it might have been an issue with the tool Liz
used to do the testing.
I await further developments with interest. If Judy can be made to work,
it looks jolly quick.
http://makeashorterlink.com/?D473519D3
http://makeashorterlink.com/?W283539D3
Yet another iterator proposal
Leo Tötsch posted a request for comments on what he called 'yet another
iterator proposal'. Nobody commented. I wonder if this means everyone
liked it.
http://makeashorterlink.com/?R293459D3
Parrot for Windows
Benjamin Goldberg wondered if there were any precompiled parrot binaries
for Win32 available as he wants to be able to test parrot code without
the current weird rites he has to go through (see his post for details).
Clinton A Pierce put a snapshot build up on his site temporarily for
Benjamin to download. Robert Spier offered space on www.parrotcode.org
for a windows build when the next release comes out which Dan thought
would be really cool. Dan also wondered about making an automated build
farm but I think he may have a tuit shortage when it comes time to
actually implement it. Joshua Hoblitt also offered to host binaries on
his CPAN mirror. Clint said he'd be happy to make milestone binaries and
wondered if there was a standard way such a distribution should be put
together.
http://makeashorterlink.com/?J3A3219D3
Moving to PIO
Jürgen Bömmels continued to make Dan happy by moving more file related
opcodes from STDIO to Parrot's PIO libraries. The latest ops to get his
attention were "open" and "close". Dan did a happy dance and applied the
patch before wondering if we were subject to a code freeze (I don't
think so; it was feature freeze time).
http://makeashorterlink.com/?G2B3129D3
IMCC and PDD03 (Calling conventions)
Leo has been thinking some more about the parrot calling conventions
described in Parrot Design Document 3 and worried that they can't
actually be done. He proposed reducing the number of parameters that can
be passed in registers in order to take pressure off the register
allocator in IMCC. Dan agreed and quickly changed the PDD to take this
into account. Leo then asked for some clarification on a couple of other
issues that he was having a hard time understanding. Dan said that it
was probably best to come back to these issues after he'd done PDD15
(The object spec). Leo agreed that objects will probably shed more light
on the calling conventions and we all sat back to hang on Dan's every
object oriented word. Not that there's any pressure at all.
http://makeashorterlink.com/?W3C3219D3
Parrot extensions, or PMC versatility
Darren Duncan had some questions about PMCs and parrot extensions and
what he should consider as he wrote a general persistence library. Dan
and Benjamin Goldberg had some answers.
http://makeashorterlink.com/?D1D3219D3
sun4 vtable JIT support
Jason Gloudon posted a patch adding support for vtable calls in the
sun4/JIT and added support for some more ops. There appeared to be a few
problems with the patch so it hasn't been applied yet.
http://makeashorterlink.com/?Y2E3369D3
A fish, a barrel and a running joke
Leon Brocard made maintaining this particular running joke almost
trivial this week by actually posting something. He's implemented
uniq(1) in parrot assembly, though he notes that it's not very fast
compared to GNU uniq(1) yet. Dan added it to the distribution in
examples/assembly/.
http://makeashorterlink.com/?Q2F3549D3
Parrot reaches another milestone
Dan has decided that Parrot has reached the point where it should have a
working "install" make target. He asked for someone to make it so. No
takers so far, but he posted late on Sunday so maybe there will be news
of this in the next summary.
http://makeashorterlink.com/?I204539D3
Meanwhile, over in perl6-language
perl6-language saw 210 messages this week. Which I think is more than
it's seen in the last 3 or 4 weeks put together. Maybe it had something
to do with the return of Damian Conway and the release of Apocalypse 6
(and the spectacularly short Apocalypse 7).
Statement modifiers
Matthijs van Duin wondered if the issue of multiple statement modifiers
has been settled. The thread is long, and the answer is essentially (and
authoritatively) "Yes, it's settled. No, you can't do it." So, unless
Larry changes his mind the point is moot. However, Matthijs does put his
case very well, if you're interested in this area I can recommend
reading the thread.
http://makeashorterlink.com/?Q514629D3
http://makeashorterlink.com/?R224259D3
Just when you get fed up of waiting for the Apocalypse...
Two come along at once.
Apocalypses 6 and 7 appeared online on Monday, a mere 9 months since the
last one (Apocalypse 7 is all of two sentences long and is contained
within Apocalypse 6, we'll be ignoring it from now on). This Apocalypse
covered closures, subs, functions, methods, types, signatures and pile
of other good stuff. All the syntax introduced was spelled out neatly
using Perl 6 rule notation, neatly showing off the power of the syntax
introduced in Apocalypse 5. I would attempt to summarize it, but it's
already pretty dense so I suggest you all read it:
http://makeashorterlink.com/?S142631C3
Now you've digested that, the rest of the summary should be easier to
follow.
Damian returned to the list, though he's only reading posts related to
Apocalypse 6 and he's pretty busy writing Exegesis 6 too so we're not
expecting vast amounts of posts from him.
Austin Hastings kicked off with the first question, wondering if the 's'
in "<psiglet>" was silent. "Of course not." says Larry.
Paul applauded the new "macro" feature (but Damian corrected his
syntax).
S&M vs. B&D
Uri Guttman, displayed entirely too much knowledge about the difference
between B&D and S&M asking if Larry shouldn't have used B&D where he
used S&M in the apocalypse. Austin Hastings knows too much too it
appears, commenting that it depends on whether you consider strongly
typed compile-type semantics as being restrictive or painful.
http://makeashorterlink.com/?X334229D3
Can "is" properties be specified indirectly?
Austin Hastings wondered if there would be some way of differentiating
between an array of constants and an array of variables. In other words,
how would one specify an array which may be appended/pushed, but whose
values cannot change or a hash to which you could add keys but not
change existing entries. Damian thought that you'd have to subclass
Array or Hash as appropriate. Luke Palmer wasn't keen on this because
then it would be easier to do something in C++ than in Perl, which isn't
the usual way of things.
http://makeashorterlink.com/?D144219D3
"is constant" eq pass by value?
Uri Guttman was confused by the default parameter passing style for Perl
6 functions, "is constant". A parameter variable declared with "is
constant" is 'locked'; you can't use the same variable to hold a
different value.
sub some_func ($some_arg is constant) {
$some_arg += 10;
...
return $some_arg;
}
To do that you need to declare the parameter with "is copy". Uri noted
that he really should keep his finger off the send button until he's
read the whole 'megilla', whatever one of those is.
http://makeashorterlink.com/?P554229D3
Pipes
Michael Lazzaro declared that he thought the Apocalypse was *great* and
that the 'sig stuff is very, very nice.' Then he asked about 'pipes'
(the new "<==" and "==>" operators which are almost, but not quite,
entirely unlike the hypothetical "~>" and "<~" operators that were
discussed so interminably a few summaries back). He wanted to know what
was decided about some of the edge cases discussed in the appendix to
the apocalypse (and had a comment to make about style). Damian pointed
out that Michael's edge cases all collapsed to two:
@var <== LIST;
LIST ==> @var;
Damian said that Larry was still unsure about these but that he (Damian)
thought they would be allowed in, if only because
@in ==> map {...}
==> sort {...}
==> map {...}
==> @out;
is a lot less ugly than
@in ==> map {...}
==> sort {...}
==> map {...}
==> push @out;
or (John Williams suggestion)
LIST ==> @var.STORE(*);
I have visions of the Perl 6 naysayers reading this section and
muttering dark imprecations about the end of the Perl as we know it...
http://makeashorterlink.com/?F464219D3
Complex Parameter Types
Michael Lazzaro wanted to know more about 'complex' type declarations.
He wanted to know how these interacted with signatures, could one use
arbitrarily complex types in subroutine signatures? Could one do
multidispatch on them? He also had a question about when/whether types
got coerced (that wasn't actually his question, but it's what it boiled
down to) when functions were called.
The answer to the first two questions was straightforward: Yes, you can
use arbitrarily complex types in function and multimethod signatures.
The third one proved a little trickier. Damian said that values would
not be coerced, but Larry wasn't so sure. He thought that coercion would
be the right thing to do. Probably. Damian noted that the 'Right Thing'
could well vary depending on whether the parameter in question was
declared "is constant/rw" (in which case passing a parameter with the
wrong type would be an error) or "is copy" (in which case coercion could
be the thing to do). Austin Hastings wondered if this could be handled
with a "use strict 'params'" type pragma, but Damian wasn't convinced,
arguing that the use of typed params automatically implied type
stricture.
This thread gets horribly hard to summarize so, for now, I'll just pick
out some representative highlights.
Larry says that, in the absence of a pragma to the contrary type
checking will be done at runtime if the type is unknown/unknowable at
compile time, but he expects the B&D types to come up with a pragma that
enforces compile time checking on pain of failed compilations.
Brent Dax came up with the concept of 'strict' and 'loose' argument
typing. Strict arg typing doesn't coerce except that, say, a Child can
satisfy a requirement for a Parent. Loose arg typing will coerce
wherever possible. He argued that the mechanism for choosing between
strict and loose arg typing should be under the control of the *caller*
rather than the callee, as that seemed to fit best with The Perl Way.
Larry agreed with him. He added that the real question is whether the
default "use strict" should include strict arg typing and noted that he
was inclining toward the strict side. This week.
A subthread sprang up dealing with Type inference. David Whipp noted
that a smart compiler might well be able to infer the type of some
variables at compile time. The theory being that in the presence of good
type inference some variables wouldn't have to have a known type to
avoid triggering compile time errors under strict arg typing. Angel Faus
pointed out that using 'user visible' type inference wasn't too good an
idea because (among other reasons) it might lead to cases where a
program only works as written for more recent versions of the compiler
(which doesn't mean that type inference is a bad idea; if the compiler
knows the type of a variable it could potentially use that information
to improve code performance).
My head started spinning when Larry seemed to imply that, not only is
Int a Scalar, but a Scalar is also an Int. Or maybe it plays one on TV.
This thread is still very much underway as I write this summary, so
attempting to summarize it is akin to summarizing a book when you're
halfway through it; you're never quite sure what are the important bits.
Hopefully things will be a little nearer resolution next week and you'll
get a more coherent summary of the conclusions.
http://makeashorterlink.com/?O374159D3
http://makeashorterlink.com/?O284219D3 -- the inference subthread
http://makeashorterlink.com/?L294639D3 -- My head hurts
Signatures zones and line noise
Brent Dax wasn't keen on the new syntax for declaring whether parameters
were optional, positional, named or variadic (greedy) and wondered if we
couldn't use something prettier (wordier) with named traits ("$x is
optional" etc). Damian thought that would be 'uncomfortably prolix' with
default values ending up a long way from their owners. Paul and Brent
proposed allowing
multi substr(Str $str, $from = $CALLER::_ is optional
$len = Inf is optional,
$new is optional) {
...
}
but Damian pointed out that this could lead to badness because, in a
signature the "is" would bind to the variable, but in a normal variable
declaration and assignment the "is" would bind to the value, which would
be confusing. There was some discussion of appropriate names for the
other 'linenoise' in signatures, specifically the choice of name for the
"*" type. The three front runners appear to be 'variadic', 'greedy' and
'slurpy/slurpificatious'. I like 'greedy', but then I'm close to the
person who proposed it.
http://makeashorterlink.com/?Y5A4129D3
In which Luke Palmer gets ignored
Luke Palmer had things to say about Appendix C of the apocalypse,
specifically to do with temp/let and with "caller" and Continuations.
Maybe what he said on these subjects was completely uncontroversial, but
nobody has replied to either of them yet.
http://makeashorterlink.com/?Y1B4229D3 -- temp/let
http://makeashorterlink.com/?H2C4139D3 -- Continuations
Multi promotion
Richard Proctor wondered what would happen if you declared a multimethod
with the same name as a previously declared normal sub/method.
Specifically he wanted to know if the new declaration would
automagically turn the old one into a multimethod. Michael Lazzaro
thought not. As did Damian and Larry. Damian provided a summary of the
rules for subroutine/method dispatch, which look wonderfully
subvertable. Piers Cawley wondered if it would be possible to get at a
'dispatcher' object and/or override it in a lexical scope, nothing that
sometimes, he scares himself. Nicholas Clark seemed to think Piers
wasn't completely insane before going on to talk about wrapping and
unwrapping in the case when the wrapper has itself been wrapped. Larry
seemed to think that unwrapping should still do the right thing even if
the wrapper being removed is itself wrapped.
http://makeashorterlink.com/?U5D4239D3
http://makeashorterlink.com/?Q1E4259D3 -- Dispatch rules (OK?)
Wrappers vs. Efficiency
In the Apocalypse, Larry talked about the performance implications of
generalized function wrappers and brought up the idea of subroutine
traits which would mark a sub as unwrappable, giving "is inline" as an
example. John Siracusa asked that whatever the 'specific definition for
speed' is that forbids runtime wrapping, it shouldn't be spelled
'inline' (though inline may imply "don't wrap me please"). A few people
agreed, but things mostly got left vague.
http://makeashorterlink.com/?U2F4159D3
Macro invocants
Dave Whipp wondered about using macros to do things like:
my Database $db = MySqlDatabase.connect(...);
$db.select * FROM Foo WHERE Foo.bar LIKE a%b;
by implementing "select" as a macro. Larry thought so, but you would
have to export the macro into the calling context. Larry added that you
would probably implement that particular functionality by treating
".select" as an infix macro with a specially parsed argument on its
right hand side (the SQL statement). David thought this was a little
clunky and proposed "macromethod" as a way to avoid the export
requirements. Luke Palmer was unconvinced and it went back and forth a
few times.
Larry wasn't convinced by David's suggestion either, commenting that
'mixing such compile-time semantics with a notation that supposedly
mandates run-time dispatch is a recipe for a certain amount of confusion
no matter how well we do it.'
http://makeashorterlink.com/?R205539D3
Overloading multis on constness of parameters
Joe Gottman wondered if it would be possible to overload multimethods
based on the const-ness of a parameter is the same way C++ does. The
answer appears to be 'yes'. Piers Cawley passed on a question from Greg
MacCarroll about overloading on the value of a parameter. Damian thought
probably not, but then showed a cunning trick involving overloading
"isa" and a junction to allow something pretty similar. Luke Palmer was
impressed.
I'm not entirely sure what it had to do with this particular thread, but
Austin Hastings posted a chart of his understanding of the various
dispatch rules. Worth reading.
http://makeashorterlink.com/?B215429D3
http://makeashorterlink.com/?E425239D3 -- Austin's chart
Operators and context
Deborah Ariel Picket had some questions about Michael Lazzaro's complete
list of known Perl 6 operators, and wondered if this list should be
extended to take context into account. She also wondered what the
complete list of possible contexts was now. Michael reckoned that the
list she pointed to was still current, but he expected to add the new
"<==" and "==>" ops. He also agreed that adding information about
contextual behaviour would be a good (if daunting) thing to do. He noted
too that Apocalypse 6 seems to imply that there would be a context for
every type. Nothing definitive from Larry (or even Damian) yet.
http://makeashorterlink.com/?Z135529D3
http://makeashorterlink.com/?B245429D3 -- the current operators list
Assignment Overloading
Luke Palmer wondered if it would be possible to overload the assignment
operator and wondered if the assignment operator was a value or a
reference copy. Damian pointed out that "*infix:=" was really an
operator on containers not values and you'd probably implement it by
overloading "STORE" in the container's class. He also commented that
"STORE" might end up being spelled "&infix:=". Copying is a shallow
value copy.
Larry popped up to discuss the .copy method on SCALAR but I wasn't
entirely sure whether that gets called on the target container or the
thing being copied. But that might just be me being confused.
http://makeashorterlink.com/?O255619D3
P6FC
Aldo Calpini put up a tentative class hierarchy for Perl 6's standard
classes (he called them the Perl 6 Foundation Classes, narrowly avoiding
a knee jerk response from at least one summarizer of this parish) and
asked for comments. Murat Ünalan suggested that Aldo was posting to the
wrong audience before suggesting that we adopt the .Net/Java object
hierarchy, which confused Aldo somewhat, so Murat clarified what he
meant. Simon Cozens made a few suggestions to Aldo about naming and
missing classes. Larry added some clarifications on his thinking about
the difference between types and classes.
http://makeashorterlink.com/?O365619D3
http://dada.perl.it/p6fc.html -- Aldo's class diagram
http://makeashorterlink.com/?J575129D3 -- Larry on types and classes
Thoughts about multiple properties
Chris Dutton wondered about using junctions for multiple properties so
"method bar is public is rw {...}" could be written as "method bar is
public & rw {...}" instead. Jonathan Scott Duff didn't think that made
much sense, and pointed out that the "is" is optional after the first,
so you could write "method bar is public rw {...}" if you wanted. Larry
noted that 'that feature is still in Schrödinger's little box.'
This led Mark Biggar to suggest some syntax for neatly defining groups
of traits and complex types without having to go to the length of
defining a class. Michael Lazzaro thought that Perl 6 classes wouldn't
be as heavyweight as they are in Perl 5 and did some WAGging (Wild Ass
Guessing) about making subs that inherit from Sub which looked pretty
good to me even if it did lead Austin Hastings to call Michael a 'bad,
evil man'.
http://makeashorterlink.com/?G685239D3
Named vs. Variadic Parameters
Michael Lazzaro pointed up some issues with subroutines that have both
variadic arguments and named arguments. Luke Palmer thought that there
were two, mutually exclusive, ways of dealing with this: Michael's
proposed behaviour and the behaviour described in the Apocalypse. Luke
was happy with the Apocalypse behaviour. Michael said that he hoped that
whatever was decided, 'broken' function signatures would give rise to a
compiler error.
http://makeashorterlink.com/?X195229D3
"is static"?
Uri Guttman asked about static variables in Perl 6. In Perl 5 you can
get a static variable by doing:
{
my $count = 0;
sub sequence { return ++$count }
}
Uri wanted to be able to do something like:
sub sequence {
my $count is static is default(0);
return ++$count;
}
Dave Whipp wondered if "our" did the job (it doesn't). Larry mentioned
that he didn't particularly like 'static' as a name for this sort of
variable and reckoned that, if there were an 'is static' declaration the
compiler would probably translate:
my $pi is static = 3;
to something like
our $foo__Xdeadbeef will init {.set(3)}
Larry's preferred syntax would be "our $foo is unique", but he noted
that 'It's not like someone isn't going to implement "is static" the
moment our back is turned anyway'.
http://makeashorterlink.com/?Q1A5269D3
No mandatory named arguments?
Nicholas Clark wondered if his reading of Apocalypse 6 was correct and
that there is no way to specify mandatory named parameters. Larry agreed
that this was so, but that one could finesse things at runtime with
tricks like:
sub foo(+$req = die 'You must supply a "req =>" argument') {...}
http://makeashorterlink.com/?J1B5359D3
Acknowledgements, Announcements and Apologies
That about wraps it up for this week. Many thanks to Larry for giving us
all something to talk about on perl6-language this week; I was starting
to think about making the language list summary a fortnightly thing.
If you appreciated this summary, please consider one or more of the
following options:
* Send money to the Perl Foundation at
http://donate.perl-foundation.org/ and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, job offers or a 'get out of war free'
card to [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
--
Piers
