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 6DB5FBC69 for ; Wed, 14 Nov 2007 23:09:36 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEIBO0dC+Vqynmdsb2JhbACPAwIBAQcEBhEYgQ8 X-IronPort-AV: E=Sophos;i="4.21,417,1188770400"; d="scan'208";a="19309306" Received: from ik-out-1112.google.com ([66.249.90.178]) by mail4-smtp-sop.national.inria.fr with ESMTP; 14 Nov 2007 23:09:35 +0100 Received: by ik-out-1112.google.com with SMTP id c21so238701ika for ; Wed, 14 Nov 2007 14:09:34 -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=/fMlVLPBYde1KExHvuFjZqeXm+1wdOsw0QH5oWo0+to=; b=T/WDtZUluIjItqNyxKfZSvQsuLEuzdYxLImceYtLY+DboDgMKc2b/rRWIGAgyrKz+y9pp+36I9fQ2hyjF4PYFRN4AltH1pcyxYNPGqPeAcL9O1bFBpO9HmH/Z6uIVGn/jRUOdPyscKZqPhibbKB+dK2GzZvh+73gUQFCgRM9fIg= 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=Gqs2zgmTAV+IWqYubhlM3I0zp137i8OuvJiyYAgjvGsPhmFeOaqSmrsJ/thTA2UDE8B3G2B3UdTlRkfdR8BkFf9dWEsUFg081Mnb/bQMwYY6P6mgPGUgYQXIVlfcj7PeMOMTKD53omXIFl2NrXgZNq2tB/iYjAtRaRlaASemWbo= Received: by 10.70.48.3 with SMTP id v3mr1971433wxv.1195078173674; Wed, 14 Nov 2007 14:09:33 -0800 (PST) Received: from ?192.168.0.7? ( [69.152.94.247]) by mx.google.com with ESMTPS id h15sm1619352wxd.2007.11.14.14.09.31 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Nov 2007 14:09:32 -0800 (PST) Message-ID: <473B7218.6020804@gmail.com> Date: Wed, 14 Nov 2007 16:09:28 -0600 From: Edgar Friendly User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Pierre Weis Cc: 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> <473B28DF.2050705@gmail.com> <20071114210408.GC28796@yquem.inria.fr> In-Reply-To: <20071114210408.GC28796@yquem.inria.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; compiler:01 weis:01 abbreviation:01 explicitely:01 compiler:01 avoided:01 subtyping:01 inlining:01 mult:01 arbitrarily:01 invariants:01 abbreviation:01 arbitrarily:01 invariants:01 edgar:98 Pierre Weis wrote: > Values of a private type abbreviation are concrete in the sense that they are > public and not hidden to inspection. > > No, you must explicitely project row values to int values (even if > this is an identity): I guess I don't understand what you mean by "public and not hidden to inspection". To a programmer using such a type, the values don't seem public. Do you only mean that to the compiler sees the full type (for optimization purposes), or something more? > The function call overhead can be avoided easily, if the from function is > provided by the compiler or if we use a sub-typing constraint row :> int. > I'd love to use subtyping constraints more than functions. Applying a function *could* do some other work or massage the value it gives to me, whereas a compiler cast seems to indicate what's happening better. It also doesn't depend on any cross-module inlining magic that may or may not happen. > On the other hand, the construction you proposed also applies to abstract > types: we need module to define an abstract type; we can have something > lighter such as a direct abstract type definition: > > type rat = abstract { > numerator : int; > denominator : int; > } with > > let make_rat n d = ... > and numerator {numerator = n} = n > and denominator ... > > let plus_rat r1 r2 = ... > let mult_rat r1 r2 = ... > > ... > This example seems like a great time to use a module and an abstract type: there's lots of functions that deal with the data in a way that they all need to use its internal representation. But there's a use for private copies of builtin types, possibly with restrictions on their construction, and it seems that *this* > Given that the injection function (the make function or the constraint part > of your construction) must enforce arbitrarily complex invariants, we may > need a module for private abbreviation as well (imagine for instance a > private abbreviation for prime numbers, that only injects into the prime type > integer arguments that are indeed prime numbers: you may need some room to > define the predicate!). > let is_prime i = ... (* return true if prime, false if not *) type prime = private int constraint is_prime This seems to suffice for the example of primes. For natural numbers, I don't see any advantage of having a private type vs. an abstract type, so using a module to encapsulate that type makes more sense to me. I might point out that supporting arbitrarily complex invariants, while theoretically satisfying, might not be necessary. I'd imagine that 90+% of actual uses of this pattern fall in the case of "simple range restriction", and taking care of those well changes the approach significantly. I like the Perl idea of "make the common things easy, and the hard things possible". > Thank you for your suggestions. > > Best regards, > Thank *you* for treating my naive and amateur suggestions as if they had worth. All the Best, Eric