RE: [Caml-list] How much optimized is the 'a option type ?

["Jon Harrop" <jon@ffconsultancy.com>]

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

 

I see. I meant unbox the tuple as in "the tuple and only the tuple" rather
than "the tuple and everything inside the tuple". So unboxing a float * int
would give you two words, one pointing to the boxed float and the other
containing a tagged int.

 

Cheers,

Jon.

 

From: Yotam Barnoy [mailto:yotambarnoy@gmail.com] 
Sent: 30 January 2014 21:43
To: Jon Harrop
Cc: Goswin von Brederlow; Ocaml Mailing List
Subject: Re: [Caml-list] How much optimized is the 'a option type ?

 

I don't really understand how this could work. If the type of a function is
'a * 'b -> 'c then the function expects 2 tuple members, right? It has no
idea what their size is, because it can be called on any tuple. Now let's
say the tuple is float * int. If we unbox the tuple,  we get 3 words, with
the int comprising the 3rd word, and no metadata. How does the function know
how big each member is, or where to find each member? Are you assuming we
monomorphize the function?

Yotam

 

On Thu, Jan 30, 2014 at 4:31 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

Yotam wrote:
> I don't think so. Without metadata, how do you know where one tuple member
ends and another begins?

Use static type information. When the type is known to be 'a * 'b you use
the unboxed representation. Otherwise you default to the boxed
representation.

OCaml already does this to some extent because functions that accept a tuple
are compiled to multi-argument functions (IIRC). So this would just be an
extension to handle the return value too. The same idea could be used with
many other types, e.g. unboxed optional arguments.

Cheers,
Jon.



 


[-- Attachment #2: Type: text/html, Size: 4857 bytes --]