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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id B65257EE94 for ; Mon, 31 Dec 2012 02:48:35 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of marek@xivilization.net) identity=pra; client-ip=178.63.18.39; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of marek@xivilization.net designates 178.63.18.39 as permitted sender) identity=mailfrom; client-ip=178.63.18.39; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@coaxial.xivilization.net) identity=helo; client-ip=178.63.18.39; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="postmaster@coaxial.xivilization.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0HAAPu4FCyPxIn/2dsb2JhbAAqGhaDMroYFnOCHgEBBAE6BgEBNwEECws1ESE2BhMbh2YDCQoILKQ+hDoBBXaDQA2IOgaLbWobhCiUOYFVgR2KG4URgnWBcA X-IronPort-AV: E=Sophos;i="4.84,383,1355094000"; d="scan'208";a="188044254" Received: from coaxial.xivilization.net ([178.63.18.39]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 31 Dec 2012 02:48:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xivilization.net; s=xiv; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=sMlCRxG5+CnOFNKpZdYxB9lObRcuFvFVJsRqKosfsM4=; b=fMZtvM0X4AIPkHV6KrNCHvQaBlJONjg8nrWFPlsiVOT/YJpHmKK06l46EvjzZZn+Hfd220eWFHbsAgfRtsvic7eaEBz+TXick6Me2l7/K9jjzAqBADyDcDw2nlSqhiYT; Received: from ppp-46-244-134-46.dynamic.mnet-online.de ([46.244.134.46] helo=localhost.localdomain) by coaxial.xivilization.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TpUUT-0008PY-Dc; Mon, 31 Dec 2012 02:48:33 +0100 Date: Mon, 31 Dec 2012 02:48:08 +0100 From: Marek Kubica To: Gabriel Scherer Cc: =?ISO-8859-1?B?VPZy9ms=?= Edwin , caml-list@inria.fr Message-ID: <20121231024808.6ed61bdc@xivilization.net> In-Reply-To: References: <20121230140823.20f39bcd@xivilization.net> <50E04922.207@etorok.net> <20121230151941.7d2261d1@xivilization.net> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] C interop: Return values in parameters Hello Gabriel, Thanks for your mail. I read it multiple times to grasp all information. On Sun, 30 Dec 2012 15:36:16 +0100 Gabriel Scherer wrote: > References are a derived concept defined as: > > type 'a ref = { mutable contents : 'a } > > You can update them from the C side just as you would handle a > polymorphic record, with Field and Store_field. Turns out Field is also valid as L-Value so I can even use Field(x,0) to set. Fun :) With this solution, I managed to fix my immediate problem. > In the code you show, the OCaml value corresponding to the pointer is > exactly the pointer, hidden as a 'value' type. This is correct as > OCaml detects out-of-(OCaml)-heap pointer. However, if you used a > custom block instead ( > http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html#toc150 > ), OCaml would do the boxing for you: Data_custom_val(v) already > returns a pointer than can be dereferenced or mutated. I read this as well as and while I seem to understand how it works, I don't get how to modify it. Do I understand right that I'd just create such a custom block and just wrap the pointer into it? I'll probably implement it tomorrow and see how I like it. > I think you have a choice between using references explicitly for > those functions of the API that mutate input references, or uniformly > representing this type of data as a custom block. The latter option > may be valuable if you have uses for the other features of custom > blocks, eg. the user-defined comparison and finalization operations, > and probably not worth the trouble otherwise. Finally, explicitly > using references to signal mutability in some part of your API is > probably clearer and a better design. Well, except for finalization I don't really have much use for the operations that custom blocks expose, but the finalization might be worth the work. Thanks again, I really felt productive today, by getting things done. regards, Marek