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 PAA09746 for caml-red; Mon, 18 Dec 2000 15:47:03 +0100 (MET) 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 AAA31191 for ; Sat, 16 Dec 2000 00:37:49 +0100 (MET) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id eBFNblj03179 for ; Sat, 16 Dec 2000 00:37:48 +0100 (MET) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id PAA01240; Fri, 15 Dec 2000 15:37:43 -0800 (PST) Date: Fri, 15 Dec 2000 15:37:43 -0800 (PST) From: Brian Rogoff To: Mattias Waldau cc: caml-list@inria.fr Subject: RE: Functions must be explicitly typed, (was Same label in different types, how do people solve this?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis@pauillac.inria.fr On Fri, 15 Dec 2000, Mattias Waldau wrote: > >> Pierre Weis wrote > >> I would like to note that type inference (i.e. code without > >> annotations) helps a lot when developing programs: the annotation free > >> code is not only easier to write but also easier to maintain since it > >> is kind of ``auto-adaptative'' and resistant to reorganisations and > >> names modifications. > > If this were important, we shouldn't have different operators for * and *. I agree. It's the same problem as with functions like print_int, output_int, etc., where the lack of overloading forces a type name to get attached to a function to disambiguate. I don't like this either, and I eagerly await a solution. Be patient, people are still working on a fix; it has come up a few times already that the Caml developers are not happy with the status quo but are working on something which will do quite a bit more than just enable you to overload a few arithmetic operators. > I had to change a program from integers to float recently, and it isn't fun > at all. Yes, I used to wonder if type classes would have been a good idea since they do make a few of these simpler issues easier to handle. Pierre Weis gave some examples of what he'd like to be able to do: for instance, to overload the .() or .[] so array and string access would be the same, and even extend it to hash table lookup. If it takes a little while to get these features in a type-safe way I'm willing to wait. If it turns out to be too difficult then I suppose we can agitate for type-classes ;-). I guess the positive side of all of this for the Caml developers is that they'll always have lots of interesting things to work on. In the meantime, there are workarounds which can help you out. You may use the module system to bind the names of functions (like "*.") to the name you want and localize the changes that you'll need to make when you change representations (i.e., you'll only need to change them where you've done the rebinding). Admittedly this is a workaround, same as the record label fixes, but it may lessen your difficulties. -- Brian