The Perl 6 Summary for the week ending 20030126
Welcome to the first Perl 6 summary of the new 'Copious Free Time
enabled' era, which should mean that these summaries will get mailed out
on Monday evening from now on.
We start, as usual, with perl6-internals
The eval patch
Leopold Tötsch continued to work on making "eval" and its associated
operators work and asked for some opinions about a problem he was having
with jumps between code segments. Jason Gloudon played sounding board
and the two of them found a way forward.
<http://makeashorterlink.com/?I27426D33>
The Parrot crashes
Dan announced that Parrot was crashing big time under (at least) OS X,
throwing segfaults in the NCI mark routine. Other people contributed
reports of what was happening on their platform and Leo Tötsch tried to
track down the error, working on the assumption that it was something to
do with his eval patch as that was the last patch that had gone in.
Later in the week Dan realised that part of the problem with OS X was a
problem with imclexer.c, an autogenerated file being generated with bad
code. Leo reckoned it was a problem with something having been multiply
defined, which had since been fixed.
Still later in the week, Steve Fink offered some analysis on the NCI
mark routine and a patch which attempted to fix the problems he saw with
it. Leo reckoned that the patch wasn't quite right, but the analysis was
good and used that to fix the problem and discovered in the process that
the parrot build process's dependency analysis wasn't quite up to the
mark. (I don't think there's a fix for that yet, but at least we know
the problem exists...)
<http://makeashorterlink.com/?D18434D33>
<http://makeashorterlink.com/?R39426D33>
<http://makeashorterlink.com/?A2B432D33>
Compiling to Parrot
K Stol is looking for a final project for his Bachelor's degree and
would like to implement some language targeting Parrot and asked for
suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested
Java (though Gopal V wasn't sure that was such a good idea just yet).
Dan suggested that, just because someone else was already working on a
TCL compiler it didn't mean it wasn't worth trying anyway, but
apparently it would have been unlikely to get approval as a Bachelor's
project. There was some further discussion of Lua and whether there
would be any real point in implementing it and the thread died down
before Mr Stol told anyone what he'd decided to do, which was rather a
shame I thought.
<http://makeashorterlink.com/?R1C423D33>
Extending the packfile format
Some months ago, Jürgen Bömmels offered a patch to extend the Parrot
packfile format whilst retaining backward compatibility. This week,
after a little modification, Leo Tötsch applied it. James Mastros
wondered if it didn't make sense (at least before parrot 1.0) to ignore
backward compatibility issues and just make it right. Leo and Dan
agreed, but Leo pointed out that, at least until the switch from
assemble.pl to IMCC was complete, maintaining backward compatibility was
the right thing. (So, if you're currently using assemble.pl to assemble
your language, consider moving it to IMCC sooner rather than later).
<http://makeashorterlink.com/?U5D442D33>
The long running Objects thread
Discussions continued. A good deal of time this week was spent
discussing the overrideablility (there's got to be better word than
that...) of OO method dispatch for different languages (and at a
language level too I hope -- I like flexibility). Python for instance
seems to require that every step in the process be subject to override.
Dan pointed out that dispatch would end up being implemented as vtable
methods on per language Object PMCs so that messages from one language's
objects to another's would use the target language's dispatch rules.
Which seems rather cute (in a good way).
<http://makeashorterlink.com/?P3E424D33> -- Christopher Armstrong talks
about Python
<http://makeashorterlink.com/?H1F442D33> -- Dan on how it works.
Intersegment branching
Leo Tötsch added a new opcode for intersegment branches, called
"branch_cs" which was his implementation of the fix that he and Jason
Gloudon had discussed while talking about problems with "eval". Dan
didn't think Parrot needed this and that we could just use a plain jump.
Leo pointed out that there were several places where this didn't quite
work, especially in the presence of JIT optimization. Dan didn't think
that didn't mean it wouldn't work, but reckoned that the cases Leo
pointed out were reasons he wanted to see intersegment jumps mediated by
subroutine calls. Leo followed up to this with an example. I can't for
the life of me tell if this was a counter example, a suggestion or what
though.
This reemerged as a new thread with the subject 'Transferring control
between code segments'. Dan opened the thread by discussing the design
perspective and laying down a few edicts. He went on to discuss the
issues that Leo's 'phenomenally cool' "compile" opcode has exposed in
his earlier handwaving and replaced the handwaves with more detail.
People were generally happy to see this, but there were a few small
issues with it which weren't explicitly resolved this week.
<http://makeashorterlink.com/?U20514D33>
<http://makeashorterlink.com/?S51522D33> -- Design issues
Bytecode Metadata
Dan responded to the earlier discussion of extending the packfile format
by opening a discussion of the type of metadata that might be useful to
have in either the on disk packfile or in memory bytecode. He reminded
everyone that parrot may have to ignore (or at least mistrust) the
metadata and opened the floor suggestions.
James Michael DuPont came up with a proposal involving RDF which Dan
thought might well be overkill (albeit interesting overkill) since he
had been thinking more about metadata that would be used by the engine
itself or provided to programs running on it.
Various other suggestions were made, and it's apparent that one
immutable design guideline is that any bytecode format for Parrot must
allow for executable code to be mmapped in.
Leo Tötsch has a patch implementing a simplified API for generating
packfiles and wondered if he should check it in.
<http://makeashorterlink.com/?H12522D33> -- Opening remarks
<http://makeashorterlink.com/?D64523D33> -- The RDF bazooka
Odd JIT timings
Dan reported that examples/assembly/mops_p.pasm was running slower with
JIT optimization than without under OSX, which doesn't seem right.
Daniel Grunblatt pointed out that JIT cores that don't optimize many
opcodes will always be slower than a Computed Goto (CG) core and there
aren't many optimized opcodes for the PPC architecture. Bruce Gray
pointed Dan at an introduction to PPC assembler in case Dan wanted to
add to the score of optimizations. Anyone else is interested could take
a look too, kudos awaits the heroic implementer.
<http://makeashorterlink.com/?L15521D33>
<http://makeashorterlink.com/?I56514D33>
Meanwhile, in perl6-language
There was a little more diversity of discussion this instead of
concentration on a single massive thread, though that thread did, of
course, continue on its path.
L2R/R2L syntax
There was some discussion of implementing conditionals ("if", "else"
etc) as functions rather than special keywords. Personally I'm not sure
that anything that monkeys with Perl's normal order of evaluation can
strictly be called a function, but what the hey.
Buddha Buck showed off a rather neat implementation of if, then and else
which borrowed some of its implementation from a Smalltalk like 'Bool'
class with "isTrue" and "isFalse" methods and then used multiple
dispatch to get the rest.
In another subthread, Michael Lazzaro explained why he still wanted
Right to Left pipelining, even though he was much more at ease with Perl
6's rules for when you needed a comma in an argument list. It appears to
be mostly about teachability.
Damian popped up to make (at least) Graham Barr and me happy when he
said that he didn't think the Perl 5ish functional forms of "map" and
"grep" etc would be going away. Huzzah!
<http://makeashorterlink.com/?T27523D33> -- Buddha's Smalltalk port of
conditionals
<http://makeashorterlink.com/?P28541D33> -- Michael Lazzaro on grep, map
and explicit pipelines
<http://makeashorterlink.com/?Z69521D33> -- map/grep/etc still functions
A proposal on if and else
Brent Dax proposed a solution to the problem of implementing "if" and
"else" as functions (the problem being that, unless you cuddle all your
"else"s, perl will intuit a semicolon at the end of "if"'s block and
things will get confused) by proposing that *all* code blocks take an
optional 'else', accessed by the "$code.else" attribute, one of the side
effects of which would be that "elsif" would become "else if".
Austin Hastings wondered if supporting 'separable verbs' might be a
better way forward. The idea certainly looks interesting, the best
summary of the idea I can give you is to point you at Austin's original
message though.
<http://makeashorterlink.com/?L4A521D33> -- All blocks are elseable
<http://makeashorterlink.com/?C2B551D33> -- Separable verbs
Arc: An Unfinished Dialect of Lisp
Rich Morin pointed everyone at Paul Graham's presentation at the first
Little Languages conference about Arc, pointing out that Graham had some
interesting things to say about language design. The discussion that
followed was mostly off topic (in the sense that they weren't talking at
all about Perl 6). Graham's paper is interesting though.
<http://makeashorterlink.com/?L2C516D33>
<http://paulgraham.com/arcll1.html>
Array/Colon question
Michael Lazzaro wondered about the seemingly different meanings of colon
in:
print $FH : $a; # $FH is an indirect object
@a = 0 .. 10 : 2; # @a is (0,2,4,6,8,10)
and wanted to know when ":" meant 'step' and when it designated an
indirect object. Brent Dax helped clear things up. Essentially ":" is a
'supercomma' and different operators and functions interpret what comes
after the supercomma in different ways. ".." treats it as specifying a
step.
<http://makeashorterlink.com/?Q1D521D33>
Multiple Dispatch by Context?
Piers Cawley wondered if it would be possible to specify a multimethod
by context as well as by parameter types. Dan Sugalski managed to hole
the proposal below the waterline with a neat set of multidispatch
declarations that led to a horrible ambiguity. Thomas A Boyer pointed
out that Ada can handle such ambiguities but that it was a complete pain
to implement and voted against using return type for multiple dispatch.
<http://makeashorterlink.com/?B5E525D33>
Who's Who in Perl 6
Ah... um... I appear to be lacking an answer set this week.
Announcements, Acknowledgements and Apologies
I'm afraid to have to announce that, as of this week I can no longer
donate the fee for these summaries to the Perl Foundation it's currently
my only source of income. On the positive side, now that I don't have to
spend 8 hours a day working for someone else I should be able to get the
Summary mailed out to the Perl 6 lists on a Monday from now on.
Thanks to everyone who sent me mail about my redundancy. No matter how
good it feels not to have to get up at 5.50 every morning with the
prospect of not getting home again 'til at least 18.40 it's still a
terrible shock to lose your job. Thankfully we look to be in a much
better position this year than we were last time I was out of work; I'm
hoping that, if I can get a few more freelance writing gigs and maybe a
little consultancy I'm not going to have to go back to the 4 hour
commutes for the foreseeable future.
Thanks too to everyone who's given me answers for the Who's Who section
since this summary started. I'm sorry to be retiring it for now, but as
new blood filters into the Perl 6 community I hope I'll be able to
restart it some time further down the road.
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 concrete proof either
way about Iraq's weaponry to [EMAIL PROTECTED]
--
Piers
