Unboxed float tuples

Unboxed float tuples

[Daniel Bünzli]

Tuples and records are represented the same way. However when it comes
to records with only floats fields we get a special unboxed
representation.

Why don't we get that for tuples of floats only ?

Using tuples (vs records) to handles points and vectors is
syntactically more lightweight (IMHO). More important it makes it
easier to share that kind of data
between independent modules without introducing new dependencies.
However I don't want to sacrifice the unboxed representation for that.

Is it worth to ask for a feature request ? I guess many people would
be against changing the runtime representation.

Best,

Daniel

Re: [Caml-list] Unboxed float tuples

[Jon Harrop]

On Sunday 08 November 2009 16:01:48 Daniel Bünzli wrote:
> Using tuples (vs records) to handles points and vectors is
> syntactically more lightweight (IMHO).

If you want to handle structs and vectors then you probably want structs 
(value types) and not boxed representations like tuples and records anyway.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] Unboxed float tuples

[Martin Jambon]

Daniel Bünzli wrote:
> Tuples and records are represented the same way. However when it comes
> to records with only floats fields we get a special unboxed
> representation.
> 
> Why don't we get that for tuples of floats only ?

Because polymorphic functions like fst would break (or would require extra
runtime checking).

Note that ('a * 'b) is pretty much the same as:
type ('a, 'b) tuple = { a : 'a; b : 'b }


# Obj.tag (Obj.repr { a = 1.0; b = 1.0 });;
- : int = 0
# Obj.tag (Obj.repr (1.0, 1.0));;
- : int = 0


whereas:

# Obj.tag (Obj.repr { Complex.re = 1.0; im = 1.0 });;
- : int = 254



Martin

-- 
http://mjambon.com/

Re: [Caml-list] Unboxed float tuples

[Brian Hurt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 816 bytes --]



On Mon, 9 Nov 2009, Daniel Bünzli wrote:

> Tuples and records are represented the same way. However when it comes
> to records with only floats fields we get a special unboxed
> representation.
>
> Why don't we get that for tuples of floats only ?

Because tuples are generic data types.  Access to records and arrays are 
special cased- in the record case, because the compiler knows the type of 
the record, in the array case because array access is via C code which 
handles the special case.  But the compiler needs to be able to compile 
code with generic tuple accesses, like:

let third_of_four (_, _, x, _) -> x;;

Fixing this would require a major rearchitecting and rewrite of not only 
the compiler, but also the garbage collector, the run time, and all the C 
bindings that have been written.

Brian

Re: [Caml-list] Unboxed float tuples

[Jon Harrop]

On Sunday 08 November 2009 19:39:03 Brian Hurt wrote:
> Fixing this would require a major rearchitecting and rewrite of not only
> the compiler, but also the garbage collector, the run time, and all the C
> bindings that have been written.

If you're willing to endure a whole program optimization pass then you can 
avoid having to touch the GC and run-time by monomorphizing the code, e.g. 
converting all tuples into monomorphic record types.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] Unboxed float tuples

[Richard Jones]

On Mon, Nov 09, 2009 at 12:01:48AM +0800, Daniel Bünzli wrote:
> Tuples and records are represented the same way. However when it comes
> to records with only floats fields we get a special unboxed
> representation.
> 
> Why don't we get that for tuples of floats only ?
> 
> Using tuples (vs records) to handles points and vectors is
> syntactically more lightweight (IMHO). More important it makes it
> easier to share that kind of data
> between independent modules without introducing new dependencies.
> However I don't want to sacrifice the unboxed representation for that.

I guess others have pointed out why this isn't so easy.

How about a syntax extension instead to turn a vector (| a, b, c |)
into { v0 = a; v1 = b; v2 = c }, and a standard type to solve the
module communication problem?  I'm not sure if camlp4 will let you
define bracket lexemes like that.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Unboxed float tuples

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]


>> t to sacrifice the unboxed representation for that.
>>     
>
> I guess others have pointed out why this isn't so easy.
>
> How about a syntax extension instead to turn a vector (| a, b, c |)
> into { v0 = a; v1 = b; v2 = c }, and a standard type to solve the
> module communication problem?  I'm not sure if camlp4 will let you
> define bracket lexemes like that.
>
>   
I use (^ ^) and {^ ^} as bracket for my bindlib library.

The only defect is that you have to add spaces :

^)^))) should be written ^) ^) ))

You can look at the code of bindlib for more info ...

Cheers,
Christophe
> Rich.
>
>   



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Caml-list] Unboxed float tuples

[Lukasz Stafiniak]

On Sun, Nov 8, 2009 at 9:58 PM, Christophe Raffalli
<christophe.raffalli@univ-savoie.fr> wrote:
>>
>> How about a syntax extension instead to turn a vector (| a, b, c |)
>> into { v0 = a; v1 = b; v2 = c }, and a standard type to solve the
>> module communication problem?  I'm not sure if camlp4 will let you
>> define bracket lexemes like that.
>>
>>
> I use (^ ^) and {^ ^} as bracket for my bindlib library.
>

I've been using {| |} -- a mesh of [| |] and { }

Cheers