From: Pierre Weis <Pierre.Weis@inria.fr>
Message-Id: <199611181006.LAA21804@pauillac.inria.fr>
Subject: Re: match values (fwd)
To: querciam@l-carnot1.ac-dijon.fr
Date: Mon, 18 Nov 1996 11:06:51 +0100 (MET)
[En francais]
>> Se pose alors imme'diatement le proble`me du choix de cette comparaison:
>>comparaison physique (==) ou e'galite' structurelle re'cursive (=) ou
>>isomorphisme d'arbres rationnels (equal en Caml V3.1), ou e'galite'
>>se'mantique adapte'e au type des ``filtres''. Le proble`me de la
>>pertinence de la comparaison se pose aussi: que faire si le motif
>>s'e'value en une fonction ? plus ge'ne'ralement en une valeur qui
>>n'admet pas l'e'galite' (valeur d'un type abstrait par exemple) ?
>L'egalite recursive me parait plus pertinente que l'egalite physique,
>il y a un risque de bouclage mais il n'est pas plus important que celui
>du code que je propose de remplacer.
>plus important que celui
>du code que je propose de remplacer.
Exact. Cependant le filtrage assure cette proprie'te' de
terminaison. C'est pourquoi il est pre'fe'reable d'admettre une
construction ou` l'emploi de l'e'galite' est explicite (et laisse'e au
choix du programmeur).
> Par ailleurs, a propos de l'impossibilite de tester l'egalite
> structurelle des
> fonctions,
[...]
> pourquoi ne pas declarer differentes
> deux fonctions ayant des adresses memoire differentes ? Le resultat n'est
> pas une egalite au sens fonctionnel, mais permet quand meme de comparer
> des structures comportant des fonctions (je pense par exemple a l'arbre
> d'une expression arithmetique dont les noeuds seraient etiquetes par les
> fonctions d'evaluation).
Dans ce genre de cas tre`s particuliers ou` l'e'galite' des fonctions
est de'cidable, il vous faut e'crire votre propre fonction de
comparaison: aucun syste`me automatique ne peut assurer cette pertinence.
> >Il me semble encore une fois que la construction cherche'e est la
> >construction when, une ge'ne'ralisation du if then else de'ja`
> >propose'e ici:
> Tout a fait d'accord. Je me souviens avoir soumis cette proposition du
> "when"
> l'annee derniere, votre conclusion etant "y a qu'a le faire !".
Je me souviens de l'avoir imple'mente' la premie`re fois en 1988 ...
[In english]
> >The problem is the ``comparison'': the actual pattern matching feature
> >has a precise semantics, bound to the structural comparison of
> >data. Your proposition means introducing implicit calls to more
> >semantical comparison functions. Thus, we have to choose this implicit
> >comparison: physical identity (==), recursive structural equality (=),
> >rational trees isomorphism (equal in Caml V3.1), or even some
> >semantical equality specialized to the type of ``patterns''. This
> >problem may not be trivial, if solvable at all, for functions or
> >abstract data types.
>
> I think structural equality would be preferable.
> It could not terminate, but this is another problem which is allready
> present in the two codes I want to replace.
We want to let the calls to equality explicit in the construction:
pattern matching guaranties termination, we don't want to introduce a
possibility of implicit loops via equality tests.
> >It seems that once more you are looking for the when construct, a
> >generalised if then else, already proposed here:
>
> I fully agree with this. Maybe for Caml-Light 0.72 or Ocaml 1.04 ?
Wait and see...
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis