Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: match values (fwd)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Pierre Weis <Pierre.Weis@i...>
Subject: Re: match values (fwd)
[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