From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1750B7F75D for ; Fri, 31 Jan 2014 09:26:29 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=pra; client-ip=212.159.14.17; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jon@ffconsultancy.com) identity=mailfrom; client-ip=212.159.14.17; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="jon@ffconsultancy.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@avasout02.plus.net) identity=helo; client-ip=212.159.14.17; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jon@ffconsultancy.com"; x-sender="postmaster@avasout02.plus.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEBADZd61LUnw4RnGdsb2JhbABZgkh8qz6SToEHFg4BAQEBAQYNCQkUKIIlAQEFCAIdBkELDQMCCREEAQEBJwcZCBsKCQgCBBMLBYdhAxXDQA2JLReMbIIWBgGCL4IJBI8phxSOSohw X-IPAS-Result: AtEBADZd61LUnw4RnGdsb2JhbABZgkh8qz6SToEHFg4BAQEBAQYNCQkUKIIlAQEFCAIdBkELDQMCCREEAQEBJwcZCBsKCQgCBBMLBYdhAxXDQA2JLReMbIIWBgGCL4IJBI8phxSOSohw X-IronPort-AV: E=Sophos;i="4.95,756,1384297200"; d="scan'208,217";a="56222855" Received: from avasout02.plus.net ([212.159.14.17]) by mail2-smtp-roc.national.inria.fr with ESMTP; 31 Jan 2014 09:26:28 +0100 Received: from XPS ([46.208.209.80]) by avasout02 with smtp id LYSR1n0041kdSZJ01YSSBK; Fri, 31 Jan 2014 08:26:27 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=KvrD2AmN c=1 sm=1 tr=0 a=0e+StC6m1dZv7qXQ+YhjwA==:117 a=0e+StC6m1dZv7qXQ+YhjwA==:17 a=0Bzu9jTXAAAA:8 a=XCxr5DcLagoA:10 a=Xub9RBUEA-sA:10 a=Kvk-SOs2Z7YA:10 a=r2vSxAw-AAAA:8 a=BR64nyZ84HQA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=pGLkceISAAAA:8 a=ynWvfNHF5Oh2PrXo13cA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=d6ZO2ScF64gA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=TDSGXA7tdd4V1Gjik-IA:9 a=emUcNtsOKOum78x9:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 X-AUTH: jdh302:2500 Reply-To: From: "Jon Harrop" To: "'Yotam Barnoy'" Cc: "'Goswin von Brederlow'" , "'Ocaml Mailing List'" References: <20140120101654.GI26447@frosties> <08bc01cf17b8$9263d070$b72b7150$@ffconsultancy.com> <20140123092925.GB20624@frosties> <01c401cf1891$b1fb1360$15f13a20$@ffconsultancy.com> <026101cf18dd$756c13d0$60443b70$@ffconsultancy.com> <030501cf1925$45380fa0$cfa82ee0$@ffconsultancy.com> <20140127152944.GA29326@frosties> <02c001cf1ccc$b635a9b0$22a0fd10$@ffconsultancy.com> <04ca01cf1e02$a2dc7b00$e8957100$@ffconsultancy.com> In-Reply-To: Date: Fri, 31 Jan 2014 08:26:32 -0000 Organization: Flying Frog Consultancy Ltd. Message-ID: <056001cf1e5e$266f9640$734ec2c0$@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0561_01CF1E5E.26700B70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHI4li4v5YdVc3QG7JLKEaISEVTZQITm23GAs0uvsEBcUwfGALv8TtSARGMS8wBZ0wNRgGSGZD1Aq5lN6wCA46uAwIAfLE+Ai7euecCTHJxcQGMOt68AmGgOdEB/G+4JZm3zwNQ Content-Language: en-gb Subject: RE: [Caml-list] How much optimized is the 'a option type ? This is a multipart message in MIME format. ------=_NextPart_000_0561_01CF1E5E.26700B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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. ------=_NextPart_000_0561_01CF1E5E.26700B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

I see. I meant unbox the tup= le as in “the tuple and only the tuple” rather than “the = tuple and everything inside the tuple”. So unboxing a float * int wou= ld give you two words, one pointing to the boxed float and the other contai= ning a tagged int.

&n= bsp;

Cheers,<= /p>

Jon.

 

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

 

I don't really understand how this could work. If the type of a functi= on 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:

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Yotam wrote:
> I d= on'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 t= o be 'a * 'b you use
the unboxed representation. Otherwise you default t= o the boxed
representation.

OCaml already does this to some exten= t because functions that accept a tuple
are compiled to multi-argument f= unctions (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. unbo= xed optional arguments.

Cheers,
Jon.

=

 

= ------=_NextPart_000_0561_01CF1E5E.26700B70--