[Caml-list] Re: Deux types de pattern-matching ?

[Luc Maranget <luc.maranget@inria.fr>]

> 
> < C'est très intéressant, car le pattern matching n'a qu'une seule
> < définition.
> 
> Je ne suis pas informaticien de formation, encore moins spécialiste de
> la sémantique des langages. Mon approche pour cette raison est
> purement pragmatique :
Bon j'en ai rajouté. Mais mon point reste de proposer une
vue simple et uniforme du filtrage. Nul besoin d'être spécialiste
de la sémantique, je vais essayer un point de vue de compilation de
Caml dans lui même.

> 
> let structure = function
>   | [ ] -> 0
>   | [x; 1] -> x
>   | _ -> 2
> ;;
> 
> on ne peut pas transformer en « if then else » seul, il faut
> utiliser un let destructurant (pour faire l'unification)
> 
Ben c'est pas comme ça que je présenterais les choses

> let structure = function liste ->
>   if (liste = [ ]) then 0
>   else
>       let (x :: reste) = liste in
>       if (reste = [1]) then x else 2
> ;;
Ça ne résoud pas le pb du pt de vue de la compilation, car il reste un
filtrage.
Supposons en plis du if, données deux fonctions ``car'' et ``cdr''
(qui sont en fait de facons plus génerales des fonction d'accès aux 
champs d'une cellule de liste, ie des accès indexés)
car x est (getfield 0 x)
Alors la compilation de structure est
 let structure = function liste ->

   if (liste = [ ]) then 0
   else
      let x = car x and reste = cdr list in
      if (reste = []) then 2
      else
        let tmp1 = car reste and tmp2 = cdr reste in
        if tmp1 = 1 then
           if tmp2 = [] then
             x
           else
             2
        else
          2
> 
> Pour moi un code comme :
> 
> match couple with
> | (0, 1) -> 0
> | (1, y) -> y
> | (x, y) -> x
> 
> commence par destructurer couple puis fait un filtrage de valeurs
> 
> let (x,y) = couple in
>   match (x,y) with
>   | (0,1) -> 0
>   | (1, _) -> y
>   | (_, _) -> x
> 
> Une seule liaison des variables x et y puis comparaisons (les
> unifications multiples ne se justifient pas)
> C'est d'ailleurs ce que fait la définition d'une fonction
> 
> let valeurs = function (x,y) -> [...]
> let valeurs = function couple -> let (x,y) = couple in [...]
> 
> Autrement dit, je décompose le filtrage de motif en deux opérations
> élémentaires :
>   i) l'unification
>   ii) disjonction de cas
Non c'est,
   filtrage (et non pas unification, c'est pas pareil)
   avec liasons éventuelle de variables des variables des filtres
   aux champs correspondants des valeurs filtrées.

J'ai l'air d'un vieux chouf, mais je crois que c'est comme ça
qu'on comprend le mieux.


> 
> Je proscris pour les raisons déjà expliquées le mélange (risques
> d'erreur liées aux variables muettes...) et recommande au lieu
> l'enchaînement des deux opérations élémentaires
> 
> Bien sûr, formellement le code suivant
>   match liste with
>   | [x; 1] -> x
> est équivalent à une disjonction de cas infinie
>   ...
>   | [0; 1] -> 0
>   | [1; 1] -> 1
>   | [2; 1] -> 2
>   ...
Non. La définition complète du filtrage (reporter vous au
prédicat ``<='' du message précédent) n'a pas besoin de ce truc
pour définir le filtrage par un motif contenant une variable.
(Même si en un sens l'équivalence est valide, mais elle n'aide pas
à comprendre ce qui se passe.
au niveaux élémentaire un filtre ``_::_'' est équivalent au prédicat
``c'est un cons'' (consp en lisp).



> Ce qui en ferait un filtrage de structure serait l'utilisation dans le
> second membre d'un motif interne au premier membre, cela dit
> 
> let valeur = function
>  | [ ] -> 0
>  | [ _ ; 1] -> 1
>  | _ ->2
> 
> ne peut pas se transformer en « if then else » sans unification et
> n'utilise pas de motif interne au premier membre ce qui finit
> d'achever la séparation des deux notions  : d'un point de vue
> théorique elle est parfaitement vaseuse.
> 
> De toutes les façons, vous ne pouvez pas demander aux utilisateurs
> d'un langage de comprendre parfaitement les fondements théoriques de
> celui-ci pour l'utiliser correctement, sous peine de produire un
> langage qui - comme Caml actuellement - ne dépassera jamais le cadre
> des universitaires. Il faut résoudre un certain nombre de problèmes
> pragmatiques liés à l'usage, et les erreurs (nombreuses) liées au
> pattern matching en sont un.
> 
C'est bien le problème. Pour avoir un langage de programmation
pas trop bizarre, un peu de théorie ne nuit jamais.
La « théorie » n'est pas le mal, n'est pas hors de portée.
Je ne crois pas que l'on puisse réellement programmer en utlisant le
filtrage, sans tout à fait comprendre ce qui se passe.

prenons un exemple extrêment simple qui évite les motifs trop
compliqués (c'est aussi un pb)

let f liste = match l with
| [] -> 0
| x::_ -> x

c'est

let f liste =
  if liste = [] then 0
  else
    




>         Diego Olivier
> 
> 
> 
> 
> 
> 

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