Front page | perl.perl6.internals |
Postings from July 2002
Perl 6 Summary for week ending 20020714
From:
pdcawley
Date:
July 15, 2002 04:24
Subject:
Perl 6 Summary for week ending 20020714
Message ID:
8465zh6xp8.fsf@despairon.bofh.org.uk
Here you go folks
Perl6 Summary for week ending 20020714
Well, what a week it's been, eh sportsfans? Without much more ado here's
a rundown of all the excitement in the Perl 6 development camps.
Still waiting for Exegesis 5?
The week before last saw a couple of fantastic postings on Perlmonks
dealing with the fun stuff in Apocalypse 5. I'm sorry I missed them last
week. Damian is still beavering away on the Exegesis but these (shall I
call them Apocrypha?) are well worth reading.
http://www.perlmonks.org/index.pl?node_id=179555
http://www.perlmonks.org/index.pl?node_id=179755
Is Parrot a second system?
John Porter worried about the second system effect, and about whether
the movement to implement a bunch of 'foreign' VM ops on Parrot was just
going to add bloat and inefficiency. Dan assured him that "These
'add-on' bytecode interpreters don't get any special consideration in
the core." John was reassured.
I think it was decided that Parrot *is* a second system, but that we're
working to avoid the classic problems associated with them.
http://archive.develooper.com/perl6-internals@perl.org/msg10802.html
Don't mix labels and comments
Simon Glover had a problem with
A: # prints "a"
print "a"
end
Which kills the assembler because of the presence of the comment. Tom
Hughes posted a patch to fix than, and Brian Wheeler pointed out that
the patch means you can't do "print "#"", which would be bad. Tom
reckons he fixed that with his second patch.
http://archive.develooper.com/perl6-internals@perl.org/msg10915.html
Tom's initial fix.
http://archive.develooper.com/perl6-internals@perl.org/msg10918.html And
the second.
Perl 6 grammar, take 5
Sean O'Rourke is my hero. He's still beavering away on writing a Perl 6
grammar. The latest incarnation is apparently "Turing-complete, if you
have a parrot engine and a bit of spare time." The grammar is still
incomplete (of course), and someone pointed out that it had a problem
with code like "{ some_function_returning_a_hash() }". Should it give a
closure? Or a hash ref. Larry hasn't commented so far.
Sean comments: "The fact that I've been able to whip this up in a couple
thousand lines of code is a remarkable testament to Parrot's maturity,
and to the wealth of tools available in Perl 5. In particular, without
The Damian's Parse::RecDescent, Melvin Smith's IMCC, and Sarathy's
Data::Dumper, it never would have been possible."
Quote of the thread: "What, this actually *runs*? Oh, my." -- Dan
Sugalski
http://archive.develooper.com/perl6-internals@perl.org/msg10866.html
So, what is IMCC then?
I asked, they answered. Apparently Reading TFM would have been a good
place to start, though Melvin Smith didn't put it *quite* so bluntly
when he told me. Essentially, the IMCC is the Parrot intermediate
language compiler. It's a bit like an assembler but sits at a slightly
higher level and worries about the painful things like "register
allocation, low level optimisation, and machine code generation." and
everyone gets to share that wealth, Perl6, Ruby, Python, whatever, they
all need the same facilities that IMCC provides.
The idea is that, instead of worrying about registers, you just provide
a string of temporaries or named locals, so you can write:
$I1 = 1
$I2 = 2
$I3 = $I1 + $I2
$I5 = $I3 + 5
And IMCC will notice that it only needs to use 2 registers when it turns
that into:
set I0, 1
set I1, 2
add I0, I0, I1
add I0, I0, 5
Melvin finishes by saying " If people don't get anything else, they
should get this. Implementing a compiler will be twice as easy if they
target the IR instead of raw Parrot. At a minimum, they implement their
parser, generate an AST, and walk the tree, emitting intermediate
expressions and directives."
Leon Brocard, who I am constitutionally required to name check in every
perl 6 summary tells me "imcc is the coolest thing... Please don't quote
me verbatim." Tee hee.
The fine manual is at languages/imcc/README in the parrot source tree.
Vtables and multimethod dispatch
This continued from last week. For some reason this ended up with a
discussion of Pythagoras' Theorem and Manhattan Distance (this was to do
with the idea of dispatch based on distance in type space...)
John Porter worried about the cost of generating full MM dispatch
tables, quoting some scary numbers. Dan reckoned that the numbers
weren't that scary, and that the problem was limited quite neatly.
Quote of the thread: "I'm not sure I want an algorithm that drives on
the sidewalks, runs red lights, and chases pedestrians..." -- Dan
Sugalski (again)
http://archive.develooper.com/perl6-internals@perl.org/msg10814.html is
a good 'root' to start at.
http://archive.develooper.com/perl6-internals@perl.org/msg10859.html
Quote of the thread, in context.
Can I put out a plea for someone, once the dust has settled, to
summarise the state of multi dispatch?
Building support for non-native bytecode
Dan mapped out what would be needed to implement a non-native JVM. I
think he just wants to play Zork using parrot, but I'd never actually
say that. He also said he'd have the specs for dynamic opcode and PMC
loading out within 24 hours, but I think events may have intervened.
http://archive.develooper.com/perl6-internals@perl.org/msg10806.html
Mutable vs immutable strings
Clark C Evans reckoned that we'd need both strings and buffers and
argued that all strings should start off as mutable, but that it should
be possible to 'freeze' them. He also pointed out that there should be
no corresponding 'thaw' operation. He wondered too if these semantics
might be useful for more than just strings. Florian Haeglsperger
wondered if Copy on Write didn't solve the problem at a stroke, to which
the answer appears to be 'Not Really'. Dan thinks that readonliness
should probably hang off PMCs rather than strings and buffers. Dan also
commented that we need to nail down some semantics about when things can
and can't be modified.
The discussion slowly morphed into a discussion of types in Perl and
other languages. Melvin Smith noted that "we've built this register
based VM upon which Perl will probably be the most non-optimised
language. Things like exposing your lexical pads, eval, etc. blow
optimisation out of the water.", but reckoned that Perl itself would
probably still see a massive speedup.
Ashley Winters got scary. A paragraph that begins "Whenever the compiler
runs across an eval, take a continuation from within the compiler." is
always going to be worrying. Actually, he proposed it as a topic for a
CS master's thesis, and Dan pointed out that one Damian Conway is
looking for students...
Quote of the thread: A tie between Ashley's paragraph opener above and
"[Parrot] will have reflection, introspection, and Deep Meditative
Capabilities." -- Who else, Dan Sugalski
http://archive.develooper.com/perl6-internals@perl.org/msg10807.html
(re)start here.
Adding the system stack to the rootset.
One of the weird things about a system that can do continuations is that
stack frames need to come out of managed memory, you can't just use the
C stack. And if you *don't* manage stack frames using garbage
collection, then you end up with memory leaks 'cos the stack frames
don't get released. Which is where we stood.
Dan is in the process of making sure that system stack frames get
properly garbage collected. Mike Lambert also stepped up and did
some/most of the implementation.
http://archive.develooper.com/perl6-internals@perl.org/msg10829.html
http://archive.develooper.com/perl6-internals@perl.org/msg10881.html
http://archive.develooper.com/perl6-internals@perl.org/msg10905.html
Mike's patch.
Making keyed aggregates really work.
Melvin Smith put out a call for someone to do an audit of the keyed
aggregate handling code and find out which methods are missing, which
ones aren't handled by the assembler and generally to fix them. Sean
(Her)O'Rourke has apparently done the deed.
Parrot: copying arrays
Alberto Simões wondered about copying and cloning of arrays and
other aggregates. How deeply should one go when making a copy as opposed
to just taking a reference? This one is still awaiting an answer.
http://archive.develooper.com/perl6-internals@perl.org/msg10868.html
coders: add doco
The internals list came close to a flame war over this one. John Porter
opened with the somewhat incendiary "I have to say that I am extremely
disappointed at the paucity of internal documentation." and went on to
make some good points, but in a tone that rather annoyed several people.
Productive stuff that came out of this, and the subsequent 'Parrot
contribution' thread include:
* FAQ writing should be a collaborative effort. The questions that an
experienced Parrot head has, or thinks are important, are probably
not the questions that a newbie would ask.
So, if you have a question that you think belongs in the FAQ, send a
message to the list with a subject line of 'PARROT QUESTION' and
we'll try and produce some sensible answers and add them to the FAQ.
* The Parrot IRC channel is a good place for some stuff but has no
'journal of record'. Something like London.pm's very lovely
'scribot' bot could prove really useful. (I'm deliberately not
putting pointers to the IRC channel, if you need to know, read the
thread.)
* Why questions, and their answers are often really important.
* We really should be maintaining the .dev files associated with each
source file, as mentioned in PDD7.
* Dan tries to be on IRC regularly from 1300-1700EST Wednesday. "While
it's no substitute for e-mail, and not as good a realtime
communication method as face to face communication, it's better than
no realtime communication at all."
In the end, I think we ended up generating more light than heat, but it
was touch and go for a while...
http://archive.develooper.com/perl6-internals@perl.org/msg10870.html
http://archive.develooper.com/perl6-internals@perl.org/msg10882.html
The first PARROT QUESTIONs
Sadly, the first PARROT QUESTION post didn't contain any actual
questions. Ashley Winters pointed out that 'test_main.c' is a rather
weird place to find parrot's main loop and wondered why parrot.c is
empty.
His followup contained the actual questions, most of which got well
answered in the following thread, which is still ongoing.
Tom Hughes told us he was trying to make sense of the current status of
keyed access at all levels, from assembler through the ops to the
vtables and is getting more confused the more he looks. Which can't be
good. Melvin Smith agreed that things were confusing, but thought that
things might get a little less confusing when he'd committed Sean's
patches. Discussion is ongoing.
http://archive.develooper.com/perl6-internals@perl.org/msg10926.html
Ashley's background post.
http://archive.develooper.com/perl6-internals@perl.org/msg10927.html
Ashley's questions
http://archive.develooper.com/perl6-internals@perl.org/msg10930.html Tom
Hughes on keyed access
More docs
Stephen Rawls submitted rx.dev, an overview of the regular expression
code. Brent Dax added some clarification.
Alberto Simões unveiled a pile of documentation for the Array,
PerlArray and PerlHash PMCs, earning himself a few Hero Points from me.
Type Morphing
I'm not entirely sure I understood this thread. Sean O'Rourke submitted
some patches to fix up Parrot's PMC type morphing. Mike Lambert pointed
at some ambiguities and then Sean showed some code that seems rather
counter intuitive to do with type morphing and comparisons. He also
provided a test file which shows some places where Perl 5 and Parrot
seem to disagree on semantics.
http://archive.develooper.com/perl6-internals@perl.org/msg10940.html
Glossary requests
Mike Litherland made some suggestions about what should go in the
Glossary. Patches were welcomed, and Dan added some terms to the
glossary, which is visible at http://www.parrotcode.org/glossary/
Meanwhile, in perl6-language
The game of 'find a good description of continuations' rumbled on for a
bit. I liked Mike Lambert's description involving a traveller in a maze
(that's why Dan wants a Z-machine interpreter running on Parrot.
Continuations are the 'maze of little twisty passages all similar').
Anyway, Dan also posted a splendidly clear and lucid explanation of
continuations. (Oh frabjous day! Calloo! Callay!) Peter Scott wondered
about serialising continuations, which is a tough problem because some
state really can't be serialised (filehandles for instance), which lead
Ted Zlatonov to suggest "FREEZE {...}" and "THAW {...}" blocks.
http://archive.develooper.com/perl6-language@perl.org/msg10284.html
Mike's 'maze' analogy.
http://archive.develooper.com/perl6-language@perl.org/msg10275.html
Dan's "Continuations are just the stack, you know?" version.
What's MY.line
Chip Salzenburg asked some hardish questions about "MY", "%MY" and the
difference between them. Piers (continuations everywhere) Cawley,
proposed "$a_continuation.the_pad", which should probably be
"$a_continuation.MY" on further reflection, which Dan seemed to think
wasn't utterly insane.
It was also proposed that things like
[localhost:~] $ perl
my $foo = 12;
print $foo;
my $foo = 'ho';
print $foo;
12ho[localhost:~] $
which is legal (with -w a warning) in perl 5 should be illegal in perl
6. This was left as Larry's call.
Quote of the thread: 'And side effects like "I call you, you modify me
invisibly...." seems more like taking dangerous drugs than programming.'
-- Melvin Smith
On seeing the quote of the thread, Richard (madman) Clamp popped up to
point out that, with the aid of Devel::LexAlias you could already do
that in Perl 5. Which is nice.
http://archive.develooper.com/perl6-language@perl.org/msg10290.html
Thread starts here. Pretty much all worthwhile.
http://archive.develooper.com/perl6-language@perl.org/msg10312.html
Quote in context
http://archive.develooper.com/perl6-language@perl.org/msg10319.html
Richard Clamp's bombshell
In brief
http://archive.develooper.com/perl6-internals@perl.org/msg10803.html --
Mark M. Adkins announced a perl script that hunts down all the POD files
in the Parrot directory tree and uses that to generate an HTML tree in a
new subdirectory. It looks rather handy.
http://arstechnica.com/paedia/c/caching/caching-1.html -- Dan pointed us
at an explanation of CPU caches
Robert Spier pointed everyone at http://www.parrotcode.org, specifically
the Development Resources.
Sean O'Rourke proposed ripping a bunch of "set_*" ops out of core.ops
now that we've got 'proper' keyed access in the assembler. Dan
concurred.
http://archive.develooper.com/perl6-internals@perl.org/msg10920.html
Tanton Gibbs sent a patch that adds documentation and a .dev file for
byteorder.c
Nicholas Clark is trying to eliminate compiler warnings.
http://archive.develooper.com/perl6-internals@perl.org/msg10925.html
Steve Purkis has a patch to add "usleep(int)" and "sleep(int)" to the
Linux version of Parrot. Dan likes the idea, but the patch won't go in
until it can be made to work on Win32 as well.
http://archive.develooper.com/perl6-language@perl.org/msg10270.html Luke
Palmer has a vim highlighting file for Perl 6.
The return of "Who's Who in Perl 6"
This week, Allison Randal answered the new standard "5Ws questionnaire"
Who are you?
I'm on the IT staff at the University of Portland. In my spare time
I enjoy working on Perl 6. In my spare-spare time I like to swing in
a hammock and read and ponder the ineffability of 42.
What do you do for/with Perl 6?
I dream in Perl 6... ;)
On the Perl 6 design team I'm the other linguist, or Damian's clone,
or the assistant cat-herder, or sometimes the Devil's Advocate. It
depends on the day, really.
Where are you coming from?
Perl 6 will be an incredible jump in power and flexibility. But it's
also a lot easier to use. I think that fact is often missed. People
see a flurry of changes, but they can't see the forest for the
trees. It's not just about making the hard things more possible,
it's about making the easy things easier. That's the message I want
to carry.
When do you think Perl 6 will be released?
February 17, 2004 at 13:42 GMT. ;) Okay, no. :) But the current
estimates of 12-18 months sound pretty reasonable, especially with
the progress we've seen in Parrot.
Why are you doing this?
Life's too short to settle for weak coffee.
No, really, for the most selfish reason imaginable: I want to use
Perl 6. Anything I can do to make it a better language or to help it
reach production faster is well worth the effort.
And it's incredibly fun.
You have 5 words. Describe yourself.
Extreme Geekiness in Unusual Packaging.
Do you have anything to declare?
Perl "rule"s!
Acknowledgements
Thanks to the denizens of #perl and #parrot for their, ahem, 'mad
proofreading skeelz'. To Melvin Smith and Leon Brocard for their
explanations of imcc.
This summary was brought to you with the assistance of GNER tea, and the
music of Waterson:Carthy and Gillian Welch.
Once again, if you liked it, give money to YAS, if you didn't like it,
well, you can still give them money, maybe they'll use it to hire a
better writer. Or maybe you could write a competing summary.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
-
Perl 6 Summary for week ending 20020714
by pdcawley