This week's summary
Piers Cawley <[email protected]> Tue, 29 Apr 2003 07:29:58 +0100
| Newsgroups | gmane.comp.lang.perl.perl6.announce |
|---|---|
| Message-ID | <[email protected]> |
The Perl 6 Summary for the week ending 20030427
Welcome back to (I hope) a normal length summary of Perl 6 shenanigans
after last week's bumper double length installment. (Thankfully traffic
has been much lighter this week; I'm not sure I could cope with writing
another epic.)
Perl6-internals was quiet again this week, but traffic does appear to be
picking up a little.
IMC and Variable Number of Arguments
Following on from questions on this subject last week, Klaas-Jan Stol
asked for some clarification of Parrot calling conventions as documented
in Parrot Design Document (PDD) 03. In a subsequent post he noted that
it seems strange that the current perl6 implementation (such as it is)
doesn't follow the Parrot calling conventions. Sean O'Rourke shuffled
his feet slightly and admitted that he'd chosen that method because "It
was easiest", though he'd later rationalized that to "It doesn't matter
for internal calls". Dan Sugalski pointed out that it was only a
temporary aberration. Unless I missed something, nobody actually
answered Klaas-Jan's initial questions.
<http://xrl.us/g6h>
Short-lived memory allocation
Last week, in a discussion of the Garbage Collection (GC) system, Dan
mentioned that Parrot GC would walk the system stack in order to build
the Root Set (the list of memory 'nodes' that are initially known to be
alive) which makes life a good deal easier for anyone allocating memory
because they don't have to worry about explicitly attaching their shiny
new buffer to the root set. Of course, it doesn't lessen the pain of
whoever writes the GC system because, as Benjamin Goldberg pointed out,
any system stack walking system is inherently unportable.
Benjamin was concerned that there may be systems where, not only could
you not use the same stack walking code as was used everywhere else, but
it would be impossible to walk the system stack at all. Dan admitted
that there 'used to be' such systems, but asserted that, for Parrot's
purposes "Either we get access to the C auto variable chain, or we can't
run there." Kurt Stephens pointed at some deeply scary sounding (and
gloriously non-portable) system stack walking methods which involve co
opting the C stack pointer and collecting garbage from unlikely
places...
If you're not sure what is meant by 'Walking the system stack' then
you're not alone. Tim Howell asked for clarification and received it
from Matt Fowles and Brent Dax.
<http://xrl.us/g6i>
<http://xrl.us/g6j>
PMC Documentation
Alberto Simões continued on his mission to document Parrot's various PMC
classes. This week he offered up some Perlstring documentation
<http://xrl.us/g6k>
The Native Call Interface (NCI) system.
Michael Collins has been playing around with calling C from Parrot and
found the NCI system rather cumbersome. He wondered if the whole thing
couldn't simply be implemented with a "callcfunc" opcode and showed a
simple implementation of what he was driving at. Dan replied to this,
explaining that he'd considered it but that it turns out not to be the
Right Thing, and gave his reasons to do with encapsulation (when you
call a PMC's method you shouldn't have to know whether it's written in
C, PASM or Befunge) and issues with dynamic generation of stub
functions. Michael wasn't entirely convinced by Dan's argument.
On the subject of NCI, Clinton A Pierce wondered if it is supposed to be
Win32 capable and, if it was, what he needed to do to get it working as
his first attempt had failed. Currently on the horns of Warnock's
Dilemma.
<http://xrl.us/g6l>
<http://xrl.us/g6m>
"use" for p6c
Joseph F. Ryan resent his patch to implement "use" in Parrot's Perl 6
implementation, this time as a straight CVS diff on Steve Fink's
request.
<http://xrl.us/g6n>
Building on Win32
Matthia Barbon continued his sterling work on getting Parrot to play
well with Win32, offering a couple of patches. Steve Fink applied them
both.
<http://xrl.us/g6o>
<http://xrl.us/g6p>
External Data Interfaces draft PDD
Matthia Barbon redrafted Brent Dax's External Data Interfaces PDD based
on the discussion of the original document. This elicited a few comments
and I presume we can expect another, clarified draft at some point.
<http://xrl.us/g6q>
PPC JIT questions
Peter Montagner has started to work on the Just In Time (JIT) system for
the PowerPC architecture (a chap can get tired of making sure that every
initialism is expanded at least once in a document you know. Still, it's
been a few summaries since I last did anything like this) and had a
couple of questions about its architecture and what he was allowed to do
in PPC assembly. Dan answered, Peter asked for clarification; the usual
give and take.
<http://xrl.us/g6r>
A question about encoding
Speed junkie Luke Palmer (Hmm... that may not mean quite what I want it
to mean) is working on the next iteration of "string_str_search", which,
apparently isn't fast enough (it's still slower than Perl 5). He had a
few questions about encodings. Benjamin Goldberg offered answers and an
entire function. Luke was impressed, but he still muttered about how
much faster single byte searching could be (he's written a
singlebyte/singlebyte search routine that goes slightly more than 2.5
times faster than Perl 5 apparently).
Later, Luke posted a new implementation of "string_str_search" which
used his screamingly fast algorithm for single byte searching and a
'stupid, slow algorithm' for multibyte searches. Steve Fink applied the
patch and asked for a unified diff next time as they are easier to read.
<http://xrl.us/g6s>
<http://xrl.us/g6t>
Leo Tötsch's iterator proposal
Remember Leo Tötsch's iterator proposal that received so little feedback
a few weeks back? Steve Fink finally commented.
<http://xrl.us/g6u>
uniq.pasm and Parrot IO
About a month ago, Jürgen Bömmels was doing some work on the moving
Parrot's IO operators to use Parrot's own PIO asynchronous IO system,
which broke Leon Brocard's uniq.pasm. Jürgen estimated that he might
have it working 'next weekend'. This week Leon asked if any progress had
been made yet.
<http://xrl.us/g6v>
Meanwhile, over in perl6-language
The Type discussions continued. (Though I note, with some satisfaction
that most of the discussions died down after I posted the summary. Maybe
I got it right. Or not.)
Types
Michael Lazzaro's excellent summary of what we knew about Types served
as the seed for this particular discussion, which was essentially a
continuation by other title of the thread that started last week.
Discussion centred on ways of specifying what sorts of type coercions
should be automatic and which disallowed. Paul Hodges suggested "use
strict allow => { Int => Str, Foo => Bar }" as a possibility, which
doesn't quite work where you want to allow a type to convert to more
than one possible target type, but it does look like a reasonable start.
There was also discussion of autocoercion to different types via a
'path' of coercions which looks to like it has enormous potential for
complexity based nuisance. Michael Lazzaro reckoned that a lot of the
chaining problems would go away if you drew a distinction between a
'lossless' coercion to a string and a serialization of something to a
string for the purposes of debugging or whatever. (Coercing *from* a
string to almost any other type but a numeric one seems to be the hard
problem...)
Damian offered some thoughts about user defined coercions when he
pointed out that a coercion is really an interaction between two classes
and should therefore be implemented using a multimethod. He argued that
things like Coercions were a strong argument for allowing return type to
be incorporated into the multidispatch resolution mechanism. Others
agreed that this would be a good thing, and we await a decision from
Larry.
<http://xrl.us/g6w> -- Seed
<http://xrl.us/g6x> -- This week's 'root'
<http://xrl.us/g6y>
Change in 'if' syntax
The Subject of the thread still thinks the discussion is about a change
in the syntax of "if", but it's actually about a change in how a block
is recognized, which has knock on effects on on the syntax of various
control structures, of which "if" is just one example. Various people
balked (again) at the fact that the new rules for detecting a block mean
that code like " %foo {bar}" no longer means "find the value associated
with 'bar' in the hash %foo" but instead evaluates to a hash variable
followed by a block, and probably a syntax error soon afterwards.
Michael Lazzaro and Damian showed workarounds for this ("%foo .{bar}"
and %foo{ bar} respectively) and Arcadi Shehter reminded everyone of the
space eating "_" that seems to have been completely forgotten since the
last time this issue arose.
<http://xrl.us/g6z>
"anon-sub()"'s execute in a for??
Paul Hodges took a crack at implementing "for" as a subroutine and came
up with something that didn't look too insane. Luke Palmer added a
refinement allowing for n at a time looping. However, for reasons that I
can't quite put my finger on, I'm not quite sure that either method has
got the sub signature quite right, and I'm not entirely sure how you
would express "for"'s signature as a Perl 6 signature anyway. Answers on
a mailing list please.
<http://xrl.us/g62>
"*" vs "**"
Paul Hodges wondered about the "*" and "**" flattening operators. He
wondered if they were actually distinct operators or if the double
variant was simply the result of applying "*" to the results of
*@whatever. According to Larry, the two are distinct, the only
difference between them is one of timing. I'm not sure I understood the
distinction to be honest and I don't think I'm alone in this. Austin
Hastings asked for an illustrative example, but we didn't see any before
the end of the week.
<http://xrl.us/g63>
P6Objects: Hint's allegations and things unsaid
Austin Hastings' response to last week's mammoth Types discussion was a
mammoth document of his own on what is currently known about Perl 6's
Object Orientation features which was the result of trawling back
through about two years of perl6-language postings. And jolly good it is
too. It triggered a modest amount of discussion, but my theory is that
everyone was too impressed to say much. I know I was.
<http://xrl.us/g64>
Storing program state for restarting
Ed Peschko wondered if it would be possible to serialize the state of a
running program so that it could pick up where it left off after it died
at the point of expiry. Dave Storrs suggested that, if one could just
serialize the current continuation, the problem would become trivial
(I'm not entirely sure he's right about that though; the current
continuation seems to me to be in slightly the wrong place) and asked
how one could do such a thing. The answer appears to be 'to the best of
current research's knowledge, you can't generally do that, but we're
working on it...'.
<http://xrl.us/g65>
C-struct style data reads
Paul Hodges doesn't like "pack". What he wants to be able to do is
something akin to C's:
struct {
int someInt;
float someFloat;
char strData[42];
float otherFloat;
char moreStr[123]
} buf;
fread(buf, sizeof buf, 1, fp);
printf("%.0f %s", buf.someFloat, buf.moreStr);
instead of unpacking a string with "unpack "ifa43fa123" <$file>" or
whatever. This led to some discussion of appropriate syntax and the
like, but it was generally felt that, even if something like this wasn't
in the core, it wouldn't be too hard to implement it.
<http://xrl.us/g66>
Return types vs. Generic Programming
Michael Lazzaro wants the moon on a stick. In particular he wants to be
able to declare:
class Object { method CLONE returns MAGIC_TYPE {...} }
where MAGIC_TYPE is some magical token that means not having to declare
class Whatever { method CLONE returns Whatever { .NEXT::CLONE } }
class Whoever { method CLONE returns Whoever { .NEXT::CLONE } }
Quite what's wrong with
class Object { method CLONE returns Object {...} }
is a mystery to me. Luke Palmer wants more than that. The insanity
continued for several messages.
Do you get the feeling that I'm not a fan of this particular proposal? I
confess I'm finding it very hard to summarize it any more than the above
without exclamations of shock and dismay. So I'll stop now. Read the
thread if you're interested.
<http://xrl.us/g67>
Type Conversion Matrix
Michael Lazzaro posted a matrix of some of the known built in types and
of the possibilities of conversion between them, noting that what was
shown were the conversions that it was possible to make automatic, not
necessarily those which should be automatic. For some reason this led to
a discussion of boolean types. Nope, I don't know why either.
Another subthread discussed which conversions were lossy and whether or
not to make them automatic in the case of going from, say 'Int' to
'int'. (Int being a Perl Integer which could be undef and have
properties and traits, and 'int' being, essentially, at least 32 bits of
signed integer).
Michael posted a second take on the matrix with more information and
with an additional 'Scalar' type added to it.
<http://xrl.us/g68>
<http://xrl.us/g69>
Fun with Junctions
Austin Hastings got faintly confused by the difference between 'all' and
'any' junctions. The rule of thumb appears to be 'if you want to use a
junction to represent a set, use an "any" junction.'
<http://xrl.us/g7a>
Fun with multi-dimensional arrays
Dave Whipp pointed everyone at a discussion of Perl 6 on Perlmonks,
where people were implementing J H Conway's Game of Life in Perl. Dave
had a some questions about tools for iterating over multidimensional
arrays, suggesting some syntax as he went, then pulling it all together
in a rather neat recalculation engine for the game of life.
Things got scary pretty quickly after that; at one point Dave even did a
local redefinition of "infix:=" which certainly had me worried. Some
clever stuff going on there and no mistake.
<http://xrl.us/g7b>
http://www.perlmonks.org/index.pl?node_id=253366
Acknowledgements, Announcements and Apologies
That about wraps it up for this week.
If you've 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, photographic and writing commissions,
or some proof that people read this bit to [email protected]
--
Piers