On Mon, Aug 18, 2008 at 5:25 PM, Allison Randal <[EMAIL PROTECTED]> wrote: > Will Coleda wrote: >>> >>> 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. > > Are you saying that Tcl doesn't allow any user-defined data types? It only > has a fixed set of data types? And Tcl requires you to only call a fixed set > of methods on variables? You can't call any other methods? That sounds > strange, so I suspect it's not what you mean. (Also, I see the TclSQLite > library, for example, so I know it is possible to create new data types and > new methods on those data types.)
8.5.3 doesn't really allow user defined types, no. There's a core set of types, all but one of which can be coerced into strings and back. Objects are coming in the next major release, IIRC, so that's probably more like the problem you're trying to solve. The METHODs that I'm talking about are not user visible. They're more like HLL vtables, internals that the various builtin commands use. > It's true that you can't get a Python array and expect it to respond to all > the same method calls as a Tcl array. But that Python array is just another > variable type, that accepts keyed access and method calls. You treat it as a > user-defined data type, and read the documentation to find out what method > calls it accepts. > >> So, to promote HLL interoperability, should we eschew privately >> defined PMC types? Or at the very least, discourage METHODs defined on >> these types? > > No, definitely not. > >> 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 > > What bits of code are you running on all Tcl PMCs? For the most part, > different kinds of data types perform different operations. So, the code > you want to run on a list is different than the code you want to run on a > string, is different than the code you want to run on a number. > >> - put a METHOD implementation on each PMC that knows how to get me the >> result I want for that type > > Certainly possible. Many languages already have a set of allowed method > calls on their core object types. For any given language being implemented, > we want to only implement the methods specified for the data type, and no > extra methods. > >> - 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. > > This has a way of getting out of control very quickly if you have to define > multimethods for every possible combination of every possible data type. > And, it doesn't sound like this is using multiple dispatch because it's > needed, but just as a kind of cheap-ish polymorphism. But necessary if I need to access my language-specific METHODs that are not going to be available on an arbitrary PMC. I'll need to define fallbacks for the various builtin types that correspond to my core types, or I'll need to coerce all the PMCs coming into the system. >> 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. > > You seem to be a outlining a complex solution to a simple problem. Which may > mean that we're looking at different problems, or that I haven't explained > my solution well enough yet. Or possibly we're working with different sets > of assumptions. > > While I don't expect every foreign data type to be immediately translated to > a native type as soon as they touch the native code, I do expect it will be > best practice to have any library in any language only return types native > to its language. So, while the Tcl library writer chose to use a Python > library, and so take on the task of learning the interface for that Python > library, they shouldn't pass that burden on to the Tcl user of the Tcl > library. For example: I hadn't even expected there would be a Tcl library here. I expected that: - someone would write the library I wanted in python and compile it to PBC - I'd load the PBC which would setup functions in a namespace - I'd invoke the functions. So that's definitely a different set of assumptions. I'd definitely hope that I could somehow wrap things automagically so I didn't have to write a library wrapper for everything on CPAN6 or any of the other HLLs (or even parrot core's stdlib.) > Python library [contains and returns Python types] > | > v > Tcl library using Python library [contains some Python types, but returns > only Tcl types] > | > v > Tcl code using Tcl library [contains only Tcl types] > > > Allison -- Will "Coke" Coleda
