On 16/02/2015 11:28 AM, Jonathan S. Shapiro wrote:
BitC v0 doesn't actually *have* a tuple type. We define "," as an
infix syntax for pair, with the result that (a, b, c) turns into
pair(a, pair(b, c)). This is mostly OK, except that the type ('a, 'b,
'c) can do strange things if 'c gets specialized to a pair type. It
was never apparent that this distinction between tuples and pairs had
any practical consequence in the expressiveness of the language, and
it allowed us to have a tuple-like syntax without introducing another
special case into the compiler implementation.
I've only been skimming these discussions, but I would suggest again
that Virgil's approach to this is worth looking at, if you haven't
already [1]. They have a total transformation from tupled function
application into unboxed native function application:
> Normalization is the process by which the Virgil compiler converts
all uses of tuples
> into uses of scalars, regardless of where they occur, including
parameters, return values,
> local variables, array elements, fields, and elements inside other
tuples. Variants of
> normalization (also known as scalar replacement of aggregates or
flattening) have been
> employed in numerous functional language implementations, e.g. [3]
and [36]. Reducing
> tuples to individual scalar values simplifies the program to a normal
form where tuples
> no longer appear and exposes the individual values to classical
compiler optimizations.
> It also eliminates the ambiguities demonstrated in the previous
section; all normalized
> functions accept zero or more scalars and return zero or more scalars.
> [...]
> Tradeoffs. Normalization removes all boxing related to tuples,
achieving Virgil’s
> implementation goal of avoiding implicit memory allocations. For
small tuples,
> normalization has much better performance than boxing, but large
tuples might
> actually perform better if allocated on the heap, depending on how
the program uses
> them; in a program that uses large tuples, reading and writing
pointers to objects on
> the heap may be cheaper than reading and writing the many tuple
elements individually.
Since BitC already explicitly distinguishes boxed tuples from ordinary
tuples, this tradeoff doesn't even apply.
Sandro
[1] http://lambda-the-ultimate.org/node/4716
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
