On Sun, Jun 03, 2012 at 10:14:06PM -0400, James E Keenan wrote: > 3. Most importantly, this is a point where we really need to get the > input of HLL-designers and the developers of other projects built on > top of Parrot (Winxed? Rosella?). What do *they* need (or what do > some of *us* need in our non-Parrot-core-developer roles)? Is what > they need different from what the Parrot build process needs?
With respect to .dump files: HLL developers don't really care about the .dump files themselves; mainly we just need to know the correct procedure to compile and run dynops and dynpmcs for our languages. (Or, if dynops/dynpmcs disappear someday, how do we achieve their equivalent functionality?) We depend on the tools -- that's the part we know about -- and the tools apparently depend on the .dump files. So they are a dependency one level removed from what HLL designers care about and work with. Along this line, a key piece missing from Parrot's documentation is a description of dynops/dynpmcs -- what they are, how they fit into Parrot's overall design, and the canonical procedures for building and using them. For example, in conversations I've often heard it mentioned that the Parrot design _expects_ most HLLs to develop their own custom PMCs (even for low-level types such as Integer, Float, and Array), but I've never seen this actually documented anywhere. And once a HLL implementer decides to use dynpmcs/dynops in the implementation, there not much solid documentation available (so one can't be sure what is "official API" versus "using something you're not supposed to"). That's my $0.02 for now. Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
