I decided my next step should be to take a look at the PDDs so I know what's going on. I would expect them to be like a writer's canon for a TV show. I'll write my impressions as I go on.
PDD00: Does PDD still mean 'Perl Design Document', or should it mean 'Parrot ...'? The documents seem to all refer to the interpreter. While I'm thinking about it, where will 'Parrot' leave off and 'Perl6' begin? At some point, it will be inappropriate to discuss the Parrot interpreter on a Perl6 list, since Perl6 might have JVM/CLR backends, and Parrot might have Python/Ruby frontends. PDD01: Perl Design Documents Question: PerlIO subsystem? Is it PIO now or something? A description of what level of I/O handling will be available to language implementers would be nifty. I never bothered to read up on what PerlIO did, anyways. Lots of use of the word 'Perl' everywhere. s:ie /perl/parrot/ PDD02: Common vtable format for all variables Nice. Question: Why is the key param for keyed_int vtable functions a pointer? Considering I have to implement all those functions to add a PMC... seems odd to be passed a pointer to a value which is guaranteed to be non-NULL. Is every parameter for every vtable function IN? Err, I just found the add_* functions. Answer: no. For a specification like this, perhaps in/out could be added to parameters or something? It's loathesome non-C clutter, I know. You don't have to put it in, I can live without it. :) Question: set_string_(native|unicode|other) specifies source or dest format? I'd assume the string type is the destination's type. It does coercion from the source STRING*'s format to the $1 format, right? Where's keyed_bignum, anyways? Don't have a heart attack! Just kidding. I don't see any mention of thunking /(.*)(_keyed.*)/ functions to $1(get_pmc$2()). Question: Are thunked _keyed methods provided by default for PMC implementors? vtables.pod says there are 'sensible' defaults, but it seems to have been written pre-keyed-PMCs. Overall, very informative and intimidating. PDD03: Parrot Calling Conventions Definitely a must-read for every assembly-writing parrot coder! Question: Prototypes aren't specified in Parrot code? I see no pointer to a yet-to-be-written calling-convention-specifiying-prototype PDD. PDD04: Perl's internal data types Huh? A bunch of stuff about Perl's IV, UV, NV, and some big* structs. From the title, I expected a description of INTVAL, FLOATVAL, BIGINT, BIGNUM, and STRING. Instead, I see internal details of big* and string implementation which I would guess don't match what's being done. I don't see the point. Question: What should I have gotten from reading this PDD? PDD05: Opcode Function specs It took me a second to realize this was a specification of the *.ops file functions. It seems obvious now, but it wasn't explicitly stated. Question: How does JIT work with this? Whoa, this document is using IV/NV. Needs updating to INTVAL or something. Umm... the example is totally inconsistent with what's actually in the opcode functions. This PDD doesn't need a rewrite; it needs to be superceded. PDD06: Parrot Assembly Language Can't really judge it, but based on age alone I'd guess it's for the best I didn't try to remember it. No offense. PDD07: Conventions and Guidelines for Perl Source Code Coding standard part works for me. As long as it's specific, you can define whatever standard you want as long as it's applied consistently. Naming convention part is obsolete. Probably needs it's own, new PDD. PDD08: Indexing Aggregate PMCs I had to read very closely. I don't know if it will ever be simple to explain. Question: What's @foo["a";12;$hi] trying to do? That's a streamed iterator thingy or something in Perl6, if I recall. I've actually read the Apocalypses, and I don't see what kind of machine support is needed for that. If keyed ops are really implementing @foo["a"][12][$hi], that would be multi-dimensional as stated in the PDD. I can kinda see how someone implementing a vector class would want to know all the dimensions at once, but most classes (like PerlArray & PerlHash, I assume) will just dereference the first KEY* and send (if non-null) key->next to that element's _keyed vtable function, right? PDD09: Garbage Collection and Dead Object Detection This reminds me of the time I implemented a copying GC... I suppose this is good enough for a PDD. Is there a document on how to actually do stuff, though? How to allocate memory, get it hooked up to the root set through various mechanisms? Do I need to implement the mark vtable entry to attach memory to my PMC? Answers like that. Question: How do I allocate memory? Question: How do I make sure my memory gets marked while I need it? Question: Is the GC really implemented in resources.c? It's a non-obvious name, and the top-of-file comment doesn't say so. Okay, that's all of the PDDs. I learned quite a bit from them, hopefully some of it was accurate & useful. :) Discuss. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
