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.)
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.
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:
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
