From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p4AFH0vj024157 for ; Tue, 10 May 2011 17:17:01 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscBAIlWyU1RZ90wkWdsb2JhbACmCBQBAQEBCQsLBxQDIqcon22DF4J4BJ5P X-IronPort-AV: E=Sophos;i="4.64,346,1301868000"; d="scan'208";a="94841702" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail4-smtp-sop.national.inria.fr with ESMTP; 10 May 2011 17:15:50 +0200 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110510151548.QTBA6199.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Tue, 10 May 2011 16:15:48 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110510151548.XPIY25656.aamtaout04-winn.ispmail.ntl.com@romulus.metastack.com> for ; Tue, 10 May 2011 16:15:48 +0100 Received: from DIVA ([172.16.0.7]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id p4AFFhdZ012678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 10 May 2011 16:15:44 +0100 From: "David Allsopp" To: "OCaml List" Date: Tue, 10 May 2011 16:15:42 +0100 Organization: MetaStack Solutions Ltd. Message-ID: <000001cc0f25$22be86a0$683b93e0$@metastack.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwPITTubDTuVVrLTAWZL26VqvDdhg== Content-Language: en-us x-ms-exchange-organization-originalclientipaddress: 172.16.0.2 x-ms-exchange-organization-originalserveripaddress: fe80::547c:3c42:e1da:eda2%11 X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=cTs9vV391PwA:10 a=V35hxywFhi8A:10 a=kj9zAlcOel0A:10 a=D1dWD5UjIhmDSEuN49QA:9 a=OZzGvmgp1uil_FaALpUA:7 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: [Caml-list] Obj question I have need of the following type in some code: type 'a tbc = Confirmed of 'a | TBC of 'a When values of this type are used, one usually wants to extract either the tag or the value (i.e. matching on both is unusual). An alternative would be to have: type 'a tbc = 'a * bool but the "problem" is that this version requires two blocks for each value where the first type only requires one block. It turns out that the compiler automatically optimises this just to retrieve field 0 of the block: let get_tbc_value = function Confirmed x -> x | TBC x -> x so there's no need to resort to Obj there. The same is not true for this: let safe_is_tbc = function TBC _ -> true | Confirmed _ -> false which generates a branch. This is "better": external is_tbc : 'a tbc -> bool = "caml_obj_tag" which takes advantage that the tag values (once converted to OCaml ints by caml_obj_tag) are the same as the representations for [true] and [false]. So I have two questions: a) Is that subtle use of caml_obj_tag "safe" (caml_obj_tag, btw, is otherwise known as Obj.tag) ... bearing in mind the usual caveats that this is buried well within a module, clearly commented and right next to the type definition, etc. etc. b) Is there a way of writing is_tbc without resorting to Obj which doesn't generate a branch? I should add that I'm posing this more from curiosity than because I'm particularly worried about micro-managing performance... I expect my application spends considerably more time waiting for the database query actually to return the results than it does processing them using either representation! David