Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] float tuples as double_arrays?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] float tuples as double_arrays?
> The floats in an all-float tuple are boxed, unlike floats in all-float 
> records.  The latter are treated as float arrays internally and have 
> double_array_tag.  I'm wondering why the former aren't treated the same 
> way?  Complexity in the compiler and not wanting the double_array special 
> case code to metastasize more is a perfectly valid answer.

I agree with the answer you suggest :-)

Another reason is that, unlike records statically declared with
"float" fields only, tuples can be used polymorphically: a float *
float can be passed to a function expecting an 'a * 'b.  This would
require run-time tests in polymorphic functions operating over tuples.

Similar tests are already generated for polymorphic functions
operating on arrays, but the tests for tuples would be more complex
because tuples, unlike arrays, are not homogeneous: one run-time test
on one component doesn't suffice to determine the type of all other
components.

> The only reason I ask is that the unboxed rep is more efficient, and tuples 
> are more convenient for some things, like breaking things out with patterns:
> [...]
> or with a record
> let {x=x;y=y;z=z;} = v in
> (* need the module name on the field above if not opened, etc. *)

This is true.  Despite this, I still recommend the use of records,
even if they are syntactically a bit heavier than tuples: you get the
"dot notation" (e.g. v.x, v.y, v.z in your example above), and finer
type distinctions if you need them (e.g. you might want to have
different types for 3D point and 3D vectors, for additional type
safety).

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners