RE: match values

RE: match values

[QUERCIA Michel (T) Math]

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

match values

[Quercia]

If you can't read french, please do skip the 51 following lines.

En francais :

Le code Caml suivant ne fonctionne pas comme on pourrait le vouloir :

     let f(x,y,z) = match x with
     | y -> ...
     | z -> ...
     | _ -> ...
     ;;

le compilateur signale que les cas 2 et 3 sont inutiles car le "y"
du match est pris comme un identificateur nouveau et non comme le
deuxieme parametre de "f".

La solution est d'ecrire :

     let f(x,y,z) =
          if x = y then ...
     else if x = z then ...
     else ...
     ;;

ou aussi :

     let f(x,y,z) = match 0 with
     | _ when x=y -> ...
     | _ when x=z -> ...
     | _ -> ...
     ;;

mais ces deux formes ne me plaisent pas !
Peut-on envisager ?

1. de modifier la syntaxe de "match" de sorte que les identificateurs
soient evalues s'ils ne sont pas precedes de "as" comme dans :

     match x with
     | y      -> ... (* comparaison des valeurs x et y   *)
     | _ as t -> ... (* definition de l'identificateur t *)

1'. sans pour autant modifier les autres formes de filtrage comme :

     let (u,v) = ... in ... (* definition des identificateurs u et v *)
     let f(u,v) = ... (* idem *)

Il est probable que 1 et 1' sont inconciliables ?

2. d'introduire une nouvelle forme de filtrage "matchval" qui evaluerait
les motifs avant de proceder a la comparaison, en conservant la
possibilite
de definir un nouvel identificateur par "_ as <ident>" ?

==============================================================================

In english :

The following Caml code does not work as one would expect :

     let f(x,y,z) = match x with
     | y -> ...
     | z -> ...
     | _ -> ...
     ;;

the compiler warns that cases #2 & #3 are useless because "y" in the
match
construct is interpreted as a new identifier and not as the second
parameter
of "f".

The solution is to write :

     let f(x,y,z) =
          if x = y then ...
     else if x = z then ...
     else ...
     ;;

or :

     let f(x,y,z) = match 0 with
     | _ when x=y -> ...
     | _ when x=z -> ...
     | _ -> ...
     ;;

but I don't like these constructs !
May I dream about ?

1. modify "match" syntax so that identifiers are evaluated unless they
are
precededed by "as" as in :

     match x with
     | y      -> ... (* comparison of the values of x and y *)
     | _ as t -> ... (* definition of identifier t          *)

1'. without modifying other patern-matching forms as :

     let (u,v) = ... in ... (* definition of identifiers u and v *)
     let f(u,v) = ... (* idem *)

I think that 1 and 1' are incompatible ?

2. introduce a new form of pattern-matching "matchval" which would
evaluate
the patterns before comparison, preserving the possibility to define a
new
identifier with a "_ as <ident>" construct ?

-- 
Michel Quercia
Lycee Carnot  16 bd Thiers  21000 Dijon
e-mail = querciam@l-carnot1.ac-dijon.fr

Re: match values

[Pierre Weis]

[En francais]

> Le code Caml suivant ne fonctionne pas comme on pourrait le vouloir :
> 
>      let f(x,y,z) = match x with
>      | y -> ...
>      | z -> ...
>      | _ -> ...
>      ;;
[...]

> 1. de modifier la syntaxe de "match" de sorte que les identificateurs
> soient evalues s'ils ne sont pas precedes de "as" comme dans :
> 
>      match x with
>      | y      -> ... (* comparaison des valeurs x et y   *)
>      | _ as t -> ... (* definition de l'identificateur t *)

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 ?)

> 2. d'introduire une nouvelle forme de filtrage "matchval" qui evaluerait
> les motifs avant de proceder a la comparaison, en conservant la
> possibilite
> de definir un nouvel identificateur par "_ as <ident>" ?

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) ?

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:
Syntaxe:
 when
 | cond1 -> e1
 | cond2 -> e2
 ...
 (| condn -> en) | (| _ -> en)
Se'mantique:
 if cond1 then begin e1 end else
 if cond2 then begin e2 end else
 ...
 begin en end, dans le cas | _ -> en
 if condn then begin en end else (), dans le cas | condn -> en

Ainsi la fonction d'e'galite' est explicite et laisse'e au choix du
programmeur. Votre exemple devient:

let f(x,y,z) =
 when
 | x = y -> ...
 | x = z -> ...
 | _ -> ...;;

L'avantage est que maintenant la condition peut e^tre plus ge'ne'rale qu'une
e'galite':

let f(x,y,z) =
 when
 | x < y -> ...
 | x + y >= z -> ...
 | _ -> ...;;

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

[In english]

> The following Caml code does not work as one would expect :
> 
>      let f(x,y,z) = match x with
>      | y -> ...
>      | z -> ...
>      | _ -> ...
[...]

> 1. modify "match" syntax so that identifiers are evaluated unless they
> are
> precededed by "as" as in :
> 
>      match x with
>      | y      -> ... (* comparison of the values of x and y *)
>      | _ as t -> ... (* definition of identifier t          *)

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 ?

> 2. introduce a new form of pattern-matching "matchval" which would
> evaluate the patterns before comparison, preserving the possibility
> to define a new identifier with a "_ as <ident>" construct ?

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.

It seems that once more you are looking for the when construct, a
generalised if then else, already proposed here:
Syntax:
 when
 | cond1 -> e1
 | cond2 -> e2
 ...
 (| condn -> en) | (| _ -> en)

Se'mantics:
 if cond1 then begin e1 end else
 if cond2 then begin e2 end else
 ...
 begin en end, dans le cas | _ -> en
 if condn then begin en end else (), in the case | condn -> en

Now the equality test is explicit and written by the programmer:

let f(x,y,z) =
 when
 | x = y -> ...
 | x = z -> ...
 | _ -> ...;;

Moreover, the conditions are not restricted to be equality tests:

let f(x,y,z) =
 when
 | x < y -> ...
 | x + y >= z -> ...
 | _ -> ...;;

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.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis