On Fri, Mar 16, 2012 at 9:44 AM, Allison Randal <[email protected]> wrote: >> Yes, rakudo/nqp uses current PCC to pass arguments. Not Parrot >> multidispatch though. > > Cool. I'd like to propose ripping it out. With a suitable delay, of > course, to make sure there aren't any other languages using it, and to > talk through what they do need and if there's a better way to provide it.
Rip out MMD? Winxed and NQP-rx currently use Parrot's MMD, and several libraries such as PCT rely on it. I'm not saying it can't be done, of course. Many existing cases can probably be replaced by better use of inheritance. If we rip out MMD, I think it will expose shortcomings in other systems, especially NameSpaces. I'm not against opening the box, I just want to make sure nobody is surprised by what we will find inside. >> And redesigning Parrot to be heavily multi-threaded VM is really >> interesting task. But I wouldn't call it "Parrot". Just because it >> will be easy to do it from clean start. Or use Erlang if it's matter. > > Building a multi-threaded VM is one of the key reasons Parrot was started. Again I mention nine's work. He's managed to do almost exactly this, with a few remaining rough edges. Invocations can be bundled up into a Task PMC. The Task can be dispatched onto any of a number of underlying worker threads. Overhead for an individual task is very small, which makes parallelization much more attractive for certain tasks. So long as Task.invoke can still eagerly gobble up arguments, it doesn't really matter where they come from or how they are marshaled. If we can make C-based method invocation faster that obviously is a big help for built-in types. Once we have 6model and start moving towards a system where more methods are PBC-based instead, those savings become less attractive. We still need an abstracted interface where arguments come from (or appear to come from) a signature object. We can't have a Sub rely on intimate details of the memory layout of its caller. So long as we have some abstraction boundary, I think we can keep most things working just as well as they are now. If we can make signatures hold less state by default, load data lazily when possible, and be more easily reused between invocations, I think we will see much win. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
