This Week on Perl 6 (8 - 14 Jul 2002)
by Piers Cawley
|
Pages: 1, 2, 3
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 multidispatch?
Building Support for Non-Native Bytecode
Dan mapped out what would be needed to implement a non-native VM. 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 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 whether these semantics might be useful for more than just strings. Florian Haeglsperger wondered whether Copy on Write didn't solve the problem at a stroke, to which the answer appears to be 'not really.' Dan thinks that 'read-onlyness' 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 speed-up.
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 because 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 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, then 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 lovely 'scribot' bot could prove useful. (I'm deliberately not putting pointers to the IRC channel. If you need to know, then 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
