From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id E686FBC69 for ; Wed, 14 Nov 2007 20:19:10 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANbWOkdA6aq4kmdsb2JhbACPAwIBAQcCBhMWgRE X-IronPort-AV: E=Sophos;i="4.21,417,1188770400"; d="scan'208";a="19301933" Received: from rn-out-0910.google.com (HELO rn-out-0102.google.com) ([64.233.170.184]) by mail4-smtp-sop.national.inria.fr with ESMTP; 14 Nov 2007 20:19:10 +0100 Received: by rn-out-0102.google.com with SMTP id s46so245208rnb for ; Wed, 14 Nov 2007 11:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=2uajBp1MGMsnkmom+7VJC6Ryd1skKby6DIjxD0tnzSM=; b=c6zUamSvxJMSfpJiC3H/YrARW8Bf/mcyzXn5P6GQGb0mOM0mFcMKKNwSCYgdEemwUq53VHYfjANtp2fZUjmg1iG4qa8KEtaWoAkH+4Hf7e8at5NTbbJV/DX2TaXVy/JF0MaaFIbLEFVhY61WH/3YBeuUJmuTtchTeBbEROTBGvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gL1aeuEJXTbzfb1dsqI98CSfNTUtE+m00kApl+Hwgj6e+kBWp1qUy2BaCpfOJ82aX6wt2Sa/SsIR2gbaSbcG0CbCxUZe7Lw430ZqCbzcK516GR9ebI81wm/xe3hFRcDpglXOMIpe5zXheyTY6ooZSzk1UROZT4HZe0TNzNgdOjQ= Received: by 10.70.135.3 with SMTP id i3mr3507124wxd.1195067948979; Wed, 14 Nov 2007 11:19:08 -0800 (PST) Received: from ?192.168.0.7? ( [69.152.94.247]) by mx.google.com with ESMTPS id h37sm2436407wxd.2007.11.14.11.19.05 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Nov 2007 11:19:06 -0800 (PST) Message-ID: <473B4A27.3050603@gmail.com> Date: Wed, 14 Nov 2007 13:19:03 -0600 From: Edgar Friendly User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Pierre Weis Cc: Alain Frisch , caml-list Subject: Re: [Caml-list] Compiler feature - useful or not? References: <473A363F.2080301@gmail.com> <891bd3390711131608g48b584a4n6b0ccab95d7de3f3@mail.gmail.com> <20071114075827.GA24058@yquem.inria.fr> <473AEC04.3030303@frisch.fr> <20071114143524.GA4423@yquem.inria.fr> <473B249D.9040703@frisch.fr> <20071114184352.GB28796@yquem.inria.fr> In-Reply-To: <20071114184352.GB28796@yquem.inria.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; compiler:01 weis:01 accessors:01 compiler:01 edgar:98 wrote:01 clearer:01 integer:01 defines:01 caml-list:01 functions:01 functions:01 exceptions:01 constraint:01 constraint:01 Pierre Weis wrote: > If we stick to the row example of positive values, we get: > > - a value of type row is in fact a concrete integer (it is not hidden in any > way), > - a value of type row can only be created by the make function defined in the > implementation of the module that defines the private type, > - a value of type row can be projected out of type row to a value of type int > with a ``no-op'' identity function (I called it from in the example). > > So, no: a value of type row is not of type int and you need a marker to > indicate the projection (for the time being the marker is a (identity) > function call to let the implemention as simple as possible, but a sub-typing > constraint makes sense and we can provide it if this is considered clearer). > > Best regards, > > -- Pierre Other than piggybacking on the private row types work by J. Garrigue and probably simplicity of implementation, does there exist a reason for involving the module system in this mechanism? At the basic level, creation and projection will always be identity functions (except that creation can throw exceptions), so it seems reasonable to elide that repetitive code. For more complex examples (a private type with more functions that work on the internal representation of that type), since the representation is already exposed, it seems appropriate to just let the client implement those functions through the identity accessors. It'd probably be safer than doing so in the Row module, because the compiler could enforce the creation invariant in those functions instead of allowing them to bypass the 'make' function. Once all these functions are removed from the module all that's left is the type definition and the creation constraint. Am I missing something? E.