On Tue, Aug 12, 2008 at 8:44 AM, Allison Randal <[EMAIL PROTECTED]> wrote: > The simple answer is Parrot won't do any automatic mapping of types between > HLLs. If you call a Python library function that returns a Python Dictionary > type, you'll get back a Python Dictionary PMC. You can interact with it as a > string keyed hash (because it implements the string keyed vtable functions), > but if you want to access its more advanced methods you'll have to make > method calls on the PMC. > > We are absolutely *not* trying to hide the multi-lingual nature of the VM > from the users. The multi-lingual nature of Parrot is one of its primary > competitive advantages. The basic principle of loading libraries is "you > have to learn the interface for the library and the kinds of values it > returns", which is true whether the library is written in the same language > as your code or a different language. In general, using a Python library and > having it return a different type than the documentation says would more > confusing than it would be helpful. > > Any automatic mapping between multiple languages will fall down at some > point in a very ugly way. I imagine modules will be developed to allow you > to, for example, mask all Python types from within your Perl 6 code as Perl > 6 types. But users will always have the ability to go back to the default, > unmodified access to the real types.
So, with this direction, if partcl want to be able to use variables generated in another language, it will -have- to manually convert them all, because they will lack the METHODS partcl has defined in its local PMCs. So, to promote HLL interoperability, should we eschew privately defined PMC types? Or at the very least, discourage METHODs defined on these types? For example, if I want bit of code to be runnable on all my TCL pmcs, I have two options at this point. I can - put a METHOD implementation on each PMC that knows how to get me the result I want for that type - add a multimethod helper sub in a private (non-user-visible) namespace that knows how to deal with all the various internal types and has a sane default. It seems like we should be pushing the latter option here to make it easier on cross-language interoperability. Even for those METHODs that are only for a particular type, this seems like a better approach if we want to play nicely with others. (Or, slightly more accurately, if I want to make it easier for others to play nice with me.) Overriding vtable methods may produce suprising results, but missing METHODs will definitely cause runtime failures. > Allison > -- Will "Coke" Coleda
