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 TAA30733 for caml-redistribution@pauillac.inria.fr; Fri, 10 Mar 2000 19:46:26 +0100 (MET) Resent-Message-Id: <200003101846.TAA30733@pauillac.inria.fr> 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 LAA06891 for ; Fri, 10 Mar 2000 11:19:12 +0100 (MET) Received: from alcaudon.tsc.uc3m.es (alcaudon.tsc.uc3m.es [163.117.145.35]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id LAA11615 for ; Fri, 10 Mar 2000 11:19:06 +0100 (MET) Received: from tsc.uc3m.es (garza.tsc.uc3m.es [163.117.145.203]) by alcaudon.tsc.uc3m.es (Netscape Messaging Server 3.6) with ESMTP id AAA3D0C; Fri, 10 Mar 2000 11:19:00 +0100 Received: from tsc.uc3m.es (fenix [163.117.145.58]) by tsc.uc3m.es (8.9.3/8.9.3) with ESMTP id LAA23701; Fri, 10 Mar 2000 11:19:01 +0100 (MET) Message-ID: <38C8C895.A0B778FC@tsc.uc3m.es> Date: Fri, 10 Mar 2000 11:04:05 +0100 From: "Francisco Valverde Albacete" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ohl@hep.tu-darmstadt.de CC: OCAML , Markus Mottl Subject: Re: additions to standard library? References: <200003071524.QAA12371@miss.wu-wien.ac.at> <14535.42143.144192.811309@heplix4.ikp.physik.tu-darmstadt.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsc.uc3m.es id LAA23701 Resent-From: weis@pauillac.inria.fr Resent-Date: Fri, 10 Mar 2000 19:46:26 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Hi, Ocamlers, There follows a rather lengthy mail on this subject, (all in English I am afraid: I could not make my French stretch to try to make fine points...)= , so be warned! Thorsten Ohl wrote: > Markus Mottl writes: > > > Hello, it sometimes happens that I need functions on abstract data > ^^^^^^^^^ often :-) > > types in the standard library which are not available there, but > > could be considered as "usual" operations on such data. > > > Some specific examples include, e.g.: > > My favorites are Map and List, of which I keep carrying around > turbocharged versions. Yes... I've done the coding of functional iterators on some dozen ADT (written as functors or modules) by now. At first I pretended that they w= ould not be necessary but in the end I found I had to code them all, (with all= the fuss added of making them visible in the signatures of the implementation= s, etc). PRO: For this reason I've developed a method of writing ADTs incrementall= y meaning that I can add some related primitives at a time, i.e. all iterat= ors on containers, all constructors for sequences, some extended iterators, e= tc. CON: This exacted a lot of design on a hierarchy of signatures that could= be refined by the use of the "include" feature which is a rather coarse meth= od of establishing a semantic hierarchy, but unfortunately the only one available at present. CON: But this same procedure of refinement is not available for implementations by the lack of a feature similar to "include" for modules= in Ocaml. I know some languages have it (OBJxx or something similar) and som= e language "proposals" too... But in Ocaml we have to make to with repeatin= g definitions. PRO: The good thing as X. Leroy stated some time ago is that we do not in= cur in any penalty for such definitions. CON: The bad thing is that the type specialization of functions through t= his method is disallowed from some versions of the compiler onwards. For exam= ple, you have to use: let new_particular_map func some_data =3D (old_polymorphic_map func some_data : mono_type2 container) instead of let new_particular_map =3D (old_polymorphic_map : (mono_type1 -> mono_type) -> mono_type1 container -> mono_type2 container) CON: Thus you really create another closure on top of the polymorphic one= , thus increasing running time. (I don't remember exactly if the problem manifests itself this way... I've learnt to avoid this second style of co= ding and seldom get the compilation error nowadays.) My proposal for now (not the most elegant, I know) would be to add a syntactic feature in the language similar to "include" for signatures, bu= t effecting textual inclusion of module code, as T.Ohl suggests. Some time = ago I thought this could be managed by using Camlp4, the caml preprocessor, b= ut then the implementor suggested it was hardly used except for Coq and I wa= s loath to tackle with it. The *real thing* would be to have a real nice (semantic) inheritance mechanism for modules but this does not go well with separate compilation= , does it (uh, actually this is a question for the implementor team)? The impression I got from a good set of slides by X. Leroy I got my hands on talking about the differences between classes and modules was, that it wa= s under study in the community but still hazy... Issat so? > > CVS-repository [...] "peer review" > > That's a brilliant idea! Yes. Definitely... Maybe there is a point in keeping the standard library uncluttered and supply a parallell library based on the standard one but giving more functionality... This way, the implementor team can concentra= te efforts in the compilers and environment and the concerned users can keep= a "utility" library up-to-date... I'd be more than willing to contribute co= de & work to such an effort. Fran Valverde Dpto. Tecnolog=EDas de las Comunicaciones Universidad Carlos III de Madrid, Spain