From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id TAA27265 for caml-redistribution; Fri, 5 Jan 1996 19:27:36 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.6.10/8.6.6) with ESMTP id TAA27245 for ; Fri, 5 Jan 1996 19:27:21 +0100 Received: from margaux.inria.fr (margaux.inria.fr [128.93.8.2]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id TAA14233 for ; Fri, 5 Jan 1996 19:27:21 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by margaux.inria.fr (8.6.10/8.6.6) with ESMTP id TAA06112 for ; Fri, 5 Jan 1996 19:27:19 +0100 Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id TAA14225; Fri, 5 Jan 1996 19:27:19 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id TAA27239; Fri, 5 Jan 1996 19:27:18 +0100 From: Pierre Weis Message-Id: <199601051827.TAA27239@pauillac.inria.fr> Subject: Re: entiers et reels To: Hubert.Fauque@enst-bretagne.fr (Fauque UPS) Date: Fri, 5 Jan 1996 19:27:18 +0100 (MET) Cc: caml-list@margaux.inria.fr In-Reply-To: <9601050905.AA05343@audrey.enst-bretagne.fr> from "Fauque UPS" at Jan 5, 96 10:05:43 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis > pourquoi les relations < > <= etc.. sont-elles polymorphes et les operations > + * etc.. ne le sont-elles pas? > > Hubert Fauque En fait les comparaisons sont des primitives polymorphes en Caml Light 0.7. Ces primitives travaillent uniforme'ment sur tous les types de donne'es, en effectuant une descente re'cursive dans la structure des donne'e pour les comparer. C'est tre`s pratique car les fonctions qui utilisent des comparaisons peuvent e^tre polymorphes. Ce comportement est raisonnable pour la plupart des valeurs Caml, comme les entiers ou les chai^nes de caracte`res ou me^me pour les types de donne'es ``alge'briques'' qu'on de'finit en Caml. Les proble`mes peuvent apparai^tre dans le cas de donne'es cycliques (la comparaison peut boucler), ou les donne'es de types non alge'briques (par exemple les nombres rationnels du module camlnum). De la me^me fac,on les fonctions ne font pas partie d'un type de'fini comme une alge`bre libre: la comparison de fonctions est donc proble'matique. C'est pourquoi les comparaisons ont un comportement bizarre avec les fonctions: on accepte (statiquement) de comparer les fonctions mais on de'clenche une erreur dynamiquement. En revanche il n'y a pas de sens raisonable a` une addition polymorphe, et c'est pourquoi nous avons une collection d'additions monomorphes. > in english: > I don't understand why caml accepts 5<6 and 5. < 6. but not 2+3 and 2.+3. The reason is that comparisons (lesser or greater or equal) are polymorphic in the Caml Light system 0.7. These primitives behave uniformely on every data, using a recursive descent into the structure of the data to compare them. This is very convenient since polymorphic functions that use comparisons can be polymorphic. Indeed this behaviour is reasonable for most Caml values, such as integers character strings or even ``algebraic'' data types (sum or product types defined by the user). Problems may appear in case of cyclic data (the comparison may loop), or non algebraic data (such as rational numbers when using the camlnum package). Since arrow types are not algebraic, the polymorphic comparison becomes problematic when faced to functions, for which there is no hope to implement comparisons. That's why the comparisons have a strange behaviour for function: they (statically) accept to compare functional values, but raise a failure at runtime. On the other hand we cannot find a reasonable meaning for a polymorphic addition, that's why we only have monomorphic versions. Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis