On Tue, 2008-07-22 at 15:37 -0700, chromatic wrote:
> The wiki page at:
>
> http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes
>
> seems to be missing the rationale for *why* it's necessary to map types
> between languages? (Also see "If Perl 6 has to care about the internal
> storage format of an Integer PMC, it's doing something very wrong.")
What about HLL-specific container types, above the level of the basic
Parrot-provided types? What does Lisp do with a Perl 5 Scalar? What
does Forth do with a LuaTable? How do you work with a Perl 6 Capture or
Junction in LOLCODE? What about Haskell user-defined types in any
language that doesn't understand records or junctive types?
If your answer is "Use only Parrot-standard opcodes/vtables on them", I
argue that you leave a lot of the source container's functionality on
the table, and you may in fact be constrained to do things that are
meaningless or absurd.
If your answer is "Treat them as opaque objects with methods" then:
A) you have just defined a type mapping
B) this may be much lower performance than another mapping could be
C) what about destination languages without native standardized OO?
D) every source language is burdened with defining a complete set
of dumbed-down methods to access every type, which it may not
need or use internally
E) you've lost the syntactic convenience that comes with being
able to work with advanced types using native syntax in the
destination language, if the source type could map directly
If you want to be smarter than either of these, then you need to figure
out a better way to do HLL-to-HLL typemapping. Hence our discussion.
-'f
