From: Geoffrey Broadwell <[EMAIL PROTECTED]>
Date: Tue, 22 Jul 2008 22:00:42 -0700
On Tue, 2008-07-22 at 22:58 -0400, Bob Rogers wrote:
> 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;
I disagree. How do you represent Complex in a language that doesn't
have a way to represent a number with more than one dimension? This is
a fundamentally different kind of thing than any simpler numeric type.
True. But passing a Complex to any language that does not have a
concept of Complex is going to cause problems if the language tries to
treat it as anything but a black box. And a black box doesn't require a
special representation.
Granted, some conversion may be necessary when calling into a
language with a more limited complex type. For example, Common Lisp
distinguishes (complex float), where Re and Im are both floating point,
from (complex rational), where they are both Integer, BigInt, or Ratio.
But most other languages don't. In that case, mapping needs to happen,
and ought to be CL's responsibility when it compiles the call.
But if you can't represent X in a language *at all*, what does it
mean to map such a thing?
> 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).
That's certainly a possible choice, but it's still a mapping, and I
argue not the only sane one. More than one language has a Complex type,
but not all of them do. If we make Complex the base Parrot type that
everything gets converted to, then some languages will be ... unhappy.
If we standardize on some other numeric type, than we fail the round
trip test spectacularly.
> 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?)
I have two answers to that:
1. It may not be a deep copy; it may be an autobox of some sort. But
that just begs the question of how to explain the source language's
semantics to all destination languages. Something we need to
discuss, clearly. :-)
Yes, indeed (to the question-begging part, especially. ;-)
2. We may simply decide that when you pass containers between HLLs,
you explicitely give up some or all of the source language's
guarantees, and the source language compiler is required to treat
the data structure after that point as if it had been exposed to
hard radiation.
-'f
What guarantees? When you pass a hash to function that expects that arg
to be an array, strange things are bound to happen. And they are bound
to be equally strange regardless of whether the call to this function
was foreign or native. It seems strange to expect inter-language
calling to be somehow safer than intra-language calling.
-- Bob
P.S. I will be incommunicado for a few days, so please don't interpret
silence as lack of interest.
