From: Pierre Weis <Pierre.Weis@inria.fr>
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)
In-Reply-To: <9601050905.AA05343@audrey.enst-bretagne.fr> from "Fauque UPS" at Jan 5, 96 10:05:43 am
> 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