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 LAA21824 for caml-redistribution; Mon, 18 Nov 1996 11:07:12 +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 LAA21808 for <caml-list@pauillac.inria.fr>; Mon, 18 Nov 1996 11:06:53 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.7.6/8.7.1) with ESMTP id LAA19035; Mon, 18 Nov 1996 11:06:52 +0100 (MET)
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA21804; Mon, 18 Nov 1996 11:06:51 +0100 (MET)
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)
Cc: caml-list@inria.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: weis

[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