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