From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id AAA10937 for caml-red; Sun, 23 Jul 2000 00:13:47 +0200 (MET DST) 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 UAA10370 for ; Sat, 22 Jul 2000 20:31:28 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e6MIVRf12707 for ; Sat, 22 Jul 2000 20:31:28 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id UAA11047; Sat, 22 Jul 2000 20:31:17 +0200 (MET DST) Date: Sat, 22 Jul 2000 20:31:17 +0200 From: Markus Mottl To: Frank Atanassow Cc: John Gerard Malecki , OCAML Subject: Re: [newbie] Define and use records in sum types Message-ID: <20000722203116.A8157@miss.wu-wien.ac.at> References: <20000717120151.A32148@miss.wu-wien.ac.at> <14709.63462.792269.194367@ish.artisan.com> <20000719221048.B23676@miss.wu-wien.ac.at> <14712.16572.925353.202223@silvester.cs.uu.nl> <20000721220058.A29053@miss.wu-wien.ac.at> <14713.41688.558933.239829@silvester.cs.uu.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14713.41688.558933.239829@silvester.cs.uu.nl>; from franka@cs.uu.nl on Sat, Jul 22, 2000 at 15:34:16 +0200 Sender: weis@pauillac.inria.fr On Sat, 22 Jul 2000, Frank Atanassow wrote: > > But how about "capturing logical invariants"? You need both ways of > > information hiding there: restricting the number of exported functions > > *and* restricting their types! Otherwise there could be ways to destroy the > > invariant. > > Can you be more specific about "capturing logical invariants"? I don't know > quite what you mean. If you have axioms that specify invariant properties about the types and functions in question. E.g. that removing an element from a set results in a set that does not contain it and that this is true for all sets. Exporting auxiliary functions from the module might allow the programmer to violate this condition. The same is true for not restricting the types of the functions. Therefore, you need both means of information hiding to guarantee correctness (i.e. the properties in question). > An instance I can think of where access to names could have semantic > significance is if it has to do with generativity. I hate generativity with a > passion, but eliminating it from ML modules would require a wholesale revision > of the module system, which it is not my object to propose here. So, I will > concede that generativity may cause name access to acquire semantic > significance. (But I hope you agree that it is at least desirable that names > and namespaces should have no semantic significance whatsoever.) I guess you mean that it is only the structure of the module that counts and not the naming? But how about ambiguities then? You need a way to refer to the right function, whatever, if it has the same signature as another one. > > I'd rather use different namings like "r1_name" and "r2_name" for the > > field: although this requires me to always include the name of the type, > > one cannot get confused either: it makes the sources easier to understand. > > I don't find that argument very convincing; Ocaml _already_ allows type, value > and field label definitions to shadow each other, which many people consider a > cognitive burden. I don't have an opinion on that issue; I'm just trying to be > consistent with the way Ocaml treats bindings currently, and add a little bit > more flexibility. There's not much you can do about shadowing of value bindings unless you prohibit it which would cause other problems: you'd have to invent a new name each time even if you just want to "transform" a value using the same name - this could cause horror if you wanted to add such a transformation in the middle of a function body... What concerns type names: I guess this is a consequence of having an "open"-statement for modules, which shadows previous type declarations. Otherwise, forbidding it would probably be a good idea since its scope is the whole module from the point of definition. Now, accessing fields more flexibly is surely possible. The question is whether adding this feature is really of so much help: the only case where it pays off is when you have large records which share a great deal of names. Then it might be a bit more convenient to have an initial declaration that tells the compiler what kind of record you are talking about instead of inventing new names for records. A rather statistical question... > In fact, I don't see how this makes programs any less readable. It adds another construct that people have to learn. Reading constructs that you are not familiar with is confusing. I bet that there are plenty of people who do not even know about the "with"-construct for records... > If you don't add this mechanism, then the rule remains, "an identifier X > refers to the last definition of X in scope". Yes. > If you do add this mechanism, then that doesn't change (since the identifier > [path] "t.x" is still distinct from "x"). Right. But you have to invent additional syntax for doing this. Even though it seems to be a rather marginal addition, it also adds to making the language more complex. I haven't felt the need for it so far, but if other people have other requirements, they are free to ask for it... Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl