From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA16573; Thu, 3 Jul 2003 13:46:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA15998 for ; Thu, 3 Jul 2003 13:46:26 +0200 (MET DST) Received: from mail3.tpgi.com.au (mail.tpgi.com.au [203.12.160.59]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h63BkNT01675; Thu, 3 Jul 2003 13:46:24 +0200 (MET DST) Received: from ozemail.com.au (syd-ts18-2600-214.tpgi.com.au [203.58.21.214]) (authenticated (0 bits)) by mail3.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h63BkKh01295; Thu, 3 Jul 2003 21:46:20 +1000 Message-ID: <3F04178B.6050107@ozemail.com.au> Date: Thu, 03 Jul 2003 21:46:19 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Pierre Weis CC: brogoff@speakeasy.net, caml-list@inria.fr Subject: Re: [Caml-list] syntax of private constructors in CVS version References: <200306301839.UAA20778@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ozemail:01 caml-list:01 pierre:01 weis:01 modelization:01 non-free:01 modelize:01 invariants:01 quotient:01 equivalence:01 abstraction:01 accessor:01 immutable:01 0.0:01 disallowed:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Pierre Weis wrote: > As you should already know, usual sum and product types in Caml > correspond to the mathematical notion of free algebraic data > structures. This is fairly useful and allows the modelization of a lot > of common data structures in practical programming > situations. However, besides the free algebra structures, > mathematicians use a lot of non-free algebras (so-called structures > defined via generators and relations). Private types aim at giving a > way to modelize those non-free structures. Equivalenetly, you can > think of private types as providing a way to implement types equipped > with invariants, quotient structures (i.e. sets of equivalence classes > for some equivalence relation on a free algebra), or data types with > canonical normal forms. Well said. If I may add: this can already be done using classes, or abstraction of modules. However these tools are much *too* heavyweight, because they also hide the algebraic structure of the types completely. The user then must provide all the accessor functions, for example, instead of using record labels or pattern matching. For immutable values, establishing an invariant at construction time is enough to ensure the invariant is preserved: therefore, it is enough to make construction abstract to ensure all values of the type satisfy the invariants. Just for interest, this is not the case for mutable objects, for example: type rational = private { mutable x: float; mutable y: float }; ... let mess_up_invariant (z:rational) = z.y <- 0.0 Be interested to know the treatment of records with mutable fields. Are they permitted? Or are the mutators disallowed? > In conclusion: private types serve to modelize types with arbitrary > algebraic invariants (no miracle here: you must program those > invariants in the definition of the constructing functions). > > In contrast with abstract data types, the private types still maintain > the elegant pattern matching facility of ML outside the module that > defines the type. > > Hope this helps. Indeed, a fine dissertation, and a good choice for an extension as well. Thanks! -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners