En francais

>Je ne comprends pas bien la ligne ``_ as t -> ...''
>que vaut t ? que signifie le souligne' ?

>La seule re'ponse plausible me semble e^tre
 >``t vaut x'' et ``_'' ne sert a` rien.
>(mais si t est un alias pour x alors pourquoi de'finir t ?)

Exact, en fait je pensais a un match sur une expression calculee, le   
match
faisant partie d'un code plus gros, et pas specifiquement a un parametre   
d'une
fonction.


>Le proble`me est justement dans le terme comparaison: le filtrage
>posse`de une se'mantique bien pre'cise lie'e a` la comparaison
>structurelle des donne'es, alors que votre proposition introduit un
>appel implicite a` des fonctions de comparaison plus se'mantiques. 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.

Par ailleurs, a propos de l'impossibilite de tester l'egalite   
structurelle des
fonctions, ni de toute structure comportant une valeur fonctionnelle   
quelle
est la raison de cette impossibilite ?
Je peux comprendre qu'on ne puisse verifier si deux codes differents
produisent le meme resultat, mais 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).

>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:
>...
>Cette construction est simple a` imple'menter (4 lignes dans
>l'analyseur syntaxique suffisent) et permet d'e'crire e'le'gamment les
>tests complexes. Son seul inconve'nient est d'offrir une alternative
>supple'mentaire au if then else. Pour ma part, j'e'changerais
>volontier le if then else (avec ses lourdes parenthe`ses begin end en
>cas de se'quences) contre le when (et ses e'le'gants symboles | et ->,
>re'miniscents du filtrage et moins sensible aux se'quences).

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 !".

================================================================
[In english]


>I don't understand the last line ``_ as t -> ...'': what means the
>underscore and what's the value of t ?

>My interpretation: t is a useless alias for x ? ``_'' is useless ?

True, actually I was thinking about a "match" included in some bigger   
code, and "x" could be
some calculated expression.
   

[Here should come some consideration about functionnal comparison, but
that's too hard english for me ...]

>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.

>It seems that once more you are looking for the when construct, a
>generalised if then else, already proposed here:
>...
>By the way, this construct is simple to implement (4 lines in the
>parser) and provides a clear way to write complex tests. Its only
>drawback is to be a bit redundant with if. In my opinion, the when
>construct is a profitable alternative to if then else: its separator
>symbols | and -> are intuitive to the Caml programmer, since they are
>reminiscent to those of pattern matching. Moreover, in the presence of
>imperative sequences of expressions, the when construct is
>syntactically superior.

I fully agree with this. Maybe for Caml-Light 0.72 or Ocaml 1.04 ?

>Pierre Weis

Michel Quercia
Lycee Carnot
querciam@l-carnot1.ac-dijon.fr