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 MAA10373; Tue, 1 Jul 2003 12:47:36 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA10036 for ; Tue, 1 Jul 2003 12:47:35 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h61AlWj16121; Tue, 1 Jul 2003 12:47:32 +0200 (MET DST) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA10639; Tue, 1 Jul 2003 12:47:31 +0200 (MET DST) From: Pierre Weis Message-Id: <200307011047.MAA10639@pauillac.inria.fr> Subject: Re: [Caml-list] syntax of private constructors in CVS version In-Reply-To: <4.3.2.7.2.20030630115836.0314dae0@localhost> from Chris Hecker at "Jun 30, 103 12:00:38 pm" To: checker@d6.com (Chris Hecker) Date: Tue, 1 Jul 2003 12:47:31 +0200 (MET DST) Cc: pierre.weis@inria.fr, brogoff@speakeasy.net, caml-list@inria.fr X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; pierre:01 weis:01 caml-list:01 crime:99 butter:99 chocolate:99 abstraction:01 inspect:01 invariants:01 enforcement:99 implementor:01 retaining:01 conceptual:01 compiler:01 chris:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > So, when do we get views to solve this problem for abstract types? If > pattern matching is so great (which it is) it seems a crime to not allow it > on abstract types (another great feature). To make an american candy joke, > peanut butter and chocolate taste great together! > > Chris Hem, the introduction of the private type feature was just my answer to this question. I wanted to get the security of type abstraction without the drawback of loosing pattern matching. Put it another way: -- regular data types are concrete, you can freely create their values with constructors or labels, you can inspect their values via pattern matching, -- private types are ``semi concrete'', you cannot freely create their values (you are obliged to use their construction functions) but you can still inspect their values via pattern matching, -- abstract types are not concrete, you cannot freely create their values (you are obliged to use the construction functions they provide) and you cannot inspect their values via pattern matching (you are also obliged to use the inspection functions they provide). Yet another way (coarse and oversimplified view (:)): -- concrete types are freely readable/writable data types, -- private types are freely read only data types, -- abstract types are nor freely readable nor freely writable data types. And some specific advantages of each: -- concrete types give you the maximum freedom (no invariants to respect, no burden with construction functions), but you get a maximum dependancy on the implementation (modification of the concrete type is visible all over the place). Addition of operators is easy. -- abstract types give you the maximum security (strict enforcement of invariants by the compiler), no dependancy on the implementation that can be modified as required by the implementor of the type, no possibility of confidentiality leaks: the contents of a value that can have truely hidden parts. Addition of operators is difficult or impossible. -- private types give you the same security as abstract types for invariants and the same facility for the addition of new operators. You loose the ability to hide parts of values. In my mind, private types give you for free a lot of useful facilities that you could have with views, while retaining invaluable, both conceptual and implementationnal, simplicity. You may be right that eventually Caml could still need an extra feature as powerful and complex as views for abstract data types, but for the time being let's start and experiment with this now available, simple, and effective feature. It has already proved to be incredibly powerful and efficient for some applications. So let's go and discover where we still need more :) I mean, try it :) Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/ ------------------- 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