From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 100277F7B8 for ; Thu, 30 Jan 2014 22:43:28 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.216.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.216.176 as permitted sender) identity=mailfrom; client-ip=209.85.216.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qc0-f176.google.com) identity=helo; client-ip=209.85.216.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qc0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUCAPXG6lLRVdiwlGdsb2JhbABZhBu9J4EFCBYOAQEBAQcLCwkSKoIlAQEBAwEnGQEbHQEDAQsGBQQHDS4iAREBBQEcBhMIh2gBAwkIn1eMXIMJk0oKGScNZIg0EQEFDI52B4Q4BIlJjl+QMhgphHce X-IPAS-Result: ApUCAPXG6lLRVdiwlGdsb2JhbABZhBu9J4EFCBYOAQEBAQcLCwkSKoIlAQEBAwEnGQEbHQEDAQsGBQQHDS4iAREBBQEcBhMIh2gBAwkIn1eMXIMJk0oKGScNZIg0EQEFDI52B4Q4BIlJjl+QMhgphHce X-IronPort-AV: E=Sophos;i="4.95,752,1384297200"; d="scan'208";a="47193536" Received: from mail-qc0-f176.google.com ([209.85.216.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Jan 2014 22:43:27 +0100 Received: by mail-qc0-f176.google.com with SMTP id e16so5848821qcx.21 for ; Thu, 30 Jan 2014 13:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dERVBZ5JRhxXltLDmfTPY66UeLWVEySVAp9ZZqyrBO0=; b=ktaroUGfwpkRGAKCjdGWM6pU0a1vBwiUXvr3GedPR33QRTucglqM84IvvO5fkjqZGZ uYCkhJQ+a45IgsWq2xTfx7TXTCytI1tr/8cxhJAsT4drv4uaW6joh1sJ6+qMr+2T6nfb zIFvZD8kbsz4n7/TUGGUyZPkPyIUJ1CqdLLZI7b9v8q466/j3rOT3Fr8cRWzD1jK5BpQ 82S/P+vAeKoKT+N5tzLD25E/6V0dn1bRR55pqZWfsJ5nu7k5tchORQ/mOjCG0BwmwuYK xsiLvAiu1fULONGMh2mcd7LbBduVBAeT77UzPB3N0LbOC0CmOskAUC7vnNTqBxpZf9Zi kFpg== X-Received: by 10.140.109.72 with SMTP id k66mr24733502qgf.20.1391118206212; Thu, 30 Jan 2014 13:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.106.137 with HTTP; Thu, 30 Jan 2014 13:43:06 -0800 (PST) In-Reply-To: <04ca01cf1e02$a2dc7b00$e8957100$@ffconsultancy.com> 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> From: Yotam Barnoy Date: Thu, 30 Jan 2014 16:43:06 -0500 Message-ID: To: Jon Harrop Cc: Goswin von Brederlow , Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a1139b03e85a3a104f136f2c6 Subject: Re: [Caml-list] How much optimized is the 'a option type ? --001a1139b03e85a3a104f136f2c6 Content-Type: text/plain; charset=ISO-8859-1 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. > > > --001a1139b03e85a3a104f136f2c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't really understand how this could work. If= the type of a function is 'a * 'b -> 'c then the function e= xpects 2 tuple members, right? It has no idea what their size is, because i= t can be called on any tuple. Now let's say the tuple is float * int. I= f we unbox the tuple,=A0 we get 3 words, with the int comprising the 3rd wo= rd, 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 &= lt;jon@ffconsult= ancy.com> wrote:
Yotam wrote:
> I don't think so. Without metadata, how do you know where one tupl= e member
ends and another begins?

Use static type information. When the type is known to be 'a * &#= 39;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 tupl= e
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<= br> many other types, e.g. unboxed optional arguments.

Cheers,
Jon.



--001a1139b03e85a3a104f136f2c6--