Re: [Caml-list] Pattern matching

["Diego Olivier Fernandez Pons" <FernandezPons@iFrance.com>]

An english abstract follows

Fabrice Le Fessant a écrit :

>  (* couples 4 = (1,2) (1,3) (1,4) (2,3) (2,4) (3,4) *)
>  let couples = function n ->
>    let rec couplesCPS = function
>      | (n,_) -> [ ]
>      | (i,n) -> (i,n) :: couplesCPS (i+1, i+2)
>      | (i,j) -> (i,j) :: couplesCPS (i, j+1)
>    in    couplesCPS (1,2)
>  ;;
[...]

let succ n = n + 1;;

Le langage introduit nombre de quantificateurs existentiels ou
universels, ne serait-ce que dans la définition même des fonctions :
je lis la définition de la fonction successeur : « soit successeur la
fonction qui a tout n de N associe (n + 1) ». Cela n'a jamais posé la
moindre difficulté aux programmeurs qui, dans la fonction couple - à
votre image - comprennent tous que n est déjà liée tandis que i et j
ne le sont pas.

D'accord, j'utilise quand je peux la syntaxe :
let succ = function n -> n + 1;;
(mais le compilateur en n'admettant pas let f = function x y -> vous
force parfois à utiliser cette horreur de syntaxe)

J'emprunte l'exemple (terrifiant !) suivant à David Alexander Madore,
lequel d'ailleurs dans son message original servait à illustrer autre
chose mais peu importe

let x = 42;;
let lot f x =
  print_string "Madame Irma va maintenant répondre à la grande
question :\n";
  print_string "Le CAML a-t-il une syntaxe aberrante ?";
  print_string "(Has CAML a weird syntax ?)";
  x+1;;
let f x = x+1;;
lot f x = x+1;;

# val x : int = 42
# val lot : 'a -> int -> int = <fun>
# val f : int -> int = <fun>
# Madame Irma va maintenant répondre à la grande question :
# Le CAML a-t-il une syntaxe aberrante ?
# (Has CAML a weird syntax ?)  - : bool = true

Revenons au sujet : le problème est que la définition du
pattern-matching est déjà en soi étrange
let delta = function
  | 0 -> 1
  | _ -> 0
;;
D'accord car on a disjoint l'ensemble de définition

let delta = function
  | i when (i = 0) -> 1
  | i -> 0
;;
à mettre en parallèle avec :
let delta = function
  | i when (i = 0) -> 1
  | j -> 0
;;
Etrange car on a attrappé deux fois de suite une variable qui prend
des valeurs sur tout l'ensemble de définition et on ne comprend pas
très bien pourquoi cette variable est muette. Si l'on accepte cela
(qui est conséquence de l'absence de liaison explicite de i une seule
fois pour toutes), pourquoi n'accepterait-on pas qu'une variable dans
le motif soit déjà liée : ce serait tout aussi pratique.

Ou alors adopter pour unique syntaxe quelque chose comme
let couple = function n ->
   let rec coupleCPS = function (i,j) ->
     match (i,j) with
       | (n,_) -> [ ]
       | (_,n) -> (i, j) :: coupleCPS (i+1, i+2)
       | (_,_) -> (i, j) :: coupleCPS (i, j+1)
     in
   coupleCPS (1,2)
;;

On peut utiliser i, j et n dans les motifs et dans le reste du code
car les trois variables ont été liés correctement au préalable

< alors le simple fait de definir 'i' avant la fonction
< change le sens de la fonction par rapport a quand
< 'i' n'etait pas defini ?

Voyez un peu le code de Madore ! L'égalité change de sens dans chacune
des propositions
    let f x = x+1;;
    lot f x = x+1;;

        Diego Olivier

Fabrice said « (It is my translation) How could the compiler know than
"i" is a free variable while "n" is not ? And even if he could notice
the difference, defining "i" would then change the meaning of the
function »
The problem is that in the pattern matching, variables i and j seem to
be bounded several times (see the delta example).The "let" declaration
is omitted (which is very usefull anyway). A strange program by David
Madore is provided as well as an alternate syntax for the pattern
matching.






-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr