From: Moritz Lenz (via RT) <[EMAIL PROTECTED]>
Date: Tue, 22 Jul 2008 06:34:13 -0700
Recently on IRC the matter of HLL interoperation came up frequently,
this ticket brings it to RT and the list.
Motivation:
It should be possible to use libraries written in a different HLL, for
example you might want to call a TCL library from Perl 6.
Problem:
There are actually many problems. For example, if a TCL function returns
an integer, what will Perl 6 see? A Perl 6-native Int? or a
Int:lang(TCL) (or whatever the syntax for a type name from a different
language is)?
Small plea: For numbers at least, and preferably for anything else
which can be described in mathematical terms, Parrot ought to have as
small a set of representation types as possible, in order to minimize
the need for mapping (if not eliminate it entirely) when calling across
language boundaries.
Start with something "simple," like the meaning of "the integer three
divided by the integer five", which differs significantly between
languages:
In Tcl, this division of two integers produces the integer value 0.
In Perl 5 and Lua, this division produces the floating-point value
0.6.
In Common Lisp, this division produces "3/5", the mathematically-
exact ratio with numerator 3 and denominator 5.
One way to implement these different meanings is to provide a common
division operator that dispatches on the types of its operands. This
fails for operands of mixed type; dividing a Perl integer by a Lua
integer is straightforward, but what should we do for division of a Tcl
integer by a Lisp integer? Or vice versa?
An even bigger problem is that no Perl 5 code, when given two
integers to divide, will expect a Common Lisp ratio as a result. Any
Perl 5 implementation that does this has a bug, even if both those
integers happen to come from Common Lisp. Ditto for a floating-point
result from Common Lisp code that happens to get two integers from Perl
or Lua (or both!).
So I would argue that (1) what seem like differences in numbers in
the various languages are really differences in the way those languages
define their numeric operators, not in the numbers themselves; and (2)
standardizing on common numeric data type will avoid the impossible job
of making the Parrot built-in arithmetic be all things to all languages
(and all combinations thereof).
I would further argue that *any* sort of type mapping is problematic
when calling across language boundaries. If I pass an array of arrays
of ... of numbers from one language to another, then mapping would seem
to require a deep copy. This changes the API: The native call into
this routine can see side effects to the passed data structure, whereas
the foreign call would not. (Or am I misunderstanding what you mean by
"mapping" here?)
-- Bob Rogers
http://rgrjr.dyndns.org/
