Discussion :

[InOCamlWeTrust]

Mmmmouais... dans une certaine mesure... ça me fait penser à ces cours de PROLOG où on oblige l'étudiant à manipuler des entiers à la Peano pendant une centaine de pages, pour enfin se rendre compte que l'on a inventé mieux depuis, la notation arabe !

La grosse limite dans ton exemple, c'est que je ne peux pas définir de fonction de ce type...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
val matrix_multiply : (n, m) matrix -> (m, p) matrix -> (n, p) matrix

... sous-entendu, pour tous n, m et p. Or c'était bien la question initiale lorsque notre ami parlait des n-upplets.

[gasche]

Mmmmouais... dans une certaine mesure... ça me fait penser à ces cours de PROLOG où on oblige l'étudiant à manipuler des entiers à la Peano pendant une centaine de pages, pour enfin se rendre compte que l'on a inventé mieux depuis, la notation arabe !

On peut aussi utiliser des notations décimales ou binaires : je n'ai ici qu'un seul type abstrait ('a s), mais avec un ('a d0) et un ('a d1) tu as du binaire. Un vieil exemple en décimal. Par contre, je ne suis pas sûr que tu puisses alors exprimer la somme dans le langage des types OCaml (alors que c'est possible en unaire) de façon totalement inférée : la retenue pose sans doute des problèmes d'uniformité.

On est d'accord, ça reste des astuces assez lourdes et nettement moins élégantes et intéressantes que de vrais types dépendants, mais d'une part il faut parfois faire des acrobaties quand on est contraint par le typage (et une petite acrobatie est tolérable si elle fait gagner en sûreté à un endroit où c'est justifié), d'autre part il reste intéressant dans l'absolu de savoir distinguer ce qui a vraiment besoin de types dépendants de ce qui peut être fait sans, et cette recherche/bidouille apporte des idées/intuition sur la question.

Je ne comprends pas ta remarque sur matrix_multiply : ce n'est pas juste du polymorphisme sur le type "taille" comme dans la signature de mes fonctions "cons" et "map" ? Je n'ai pas dû comprendre ce que tu veux dire.

[prgasp77]

Oula, j'ai pas tout tout saisi, en quoi le bug dont il parle dans la première version du lamba calculus en est-il un ?

Sinon, autre truc amusant à propos des types et des warning : imaginez le code suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
let f s =
   print_endline s ;
   fun () -> print_endline (String.uppercase s)
;;

f est donc une fonction qui prend une string en entrée, l'affiche, et retourne une fonction qui affiche la même string mais en majuscule. Elle pourrait donc avoir le type string -> (unit -> unit), mais pour caml, ceci semble être équivalent à string -> unit -> unit. Ainsi, le code suivant est valide

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
let g = f "Ho ! Caml" ;;
g () ;;

Ce qui est équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

f "Ho ! Caml" ()

Mais imaginons un moment que nous n'avons que faire du retour de f, autant l'ignorer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ignore(f "plop") ;;
let _ = f "plop" ;;

Et là, incroyable : la première forme lève un warning F (partial application) alors que la première non. Et le plus incroyable, c'est que la première instruction de f est quand même exécutée dans les deux cas .

[Cacophrene]

Bonjour !

Et là, incroyable : la première forme lève un warning F (partial application) alors que la première non

Ce comportement est souhaitable. Les applications partielles combinées avec let permettent de créer des fonctions spécialisées à partir d'une fonction plus générale. Au contraire, en écrivant f (g ()), on s'attend à ce que g ne soit pas une application partielle (souvent, ça correspond à un oubli).

Évidemment les avertissements sont à considérer avec attention, mais pas toujours aussi cruciaux que les erreurs (je pense notamment au type S qui ressort massivement avec LablGTK).

Cordialement,
Cacophrène

[LLB]

Au contraire, en écrivant f (g ()), on s'attend à ce que g ne soit pas une application partielle (souvent, ça correspond à un oubli).

Non. Avec les fonctions d'ordre supérieur (List.map et compagnie), il est fréquent de passer en argument une fonction, et donc des applications partielles.

Le warning obtenu est un cas particulier de la fonction ignore. La fonction ignore permet d'ignorer le résultat d'une fonction, c'est-à-dire que l'on exécute l'expression pour obtenir un effet de bord. Si le résultat jeté est une fonction, c'est souvent louche (mais pas toujours). Avec les fonctions autres que ignore, pas d'avertissement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# ignore(f "plop") ;;
Characters 6-16:
  ignore(f "plop") ;;
        ^^^^^^^^^^
Warning F: this function application is partial,
maybe some arguments are missing.
plop
- : unit = ()
 
# let ig _ = ();;
val ig : 'a -> unit = <fun>
 
# ig(f "plop") ;;
plop
- : unit = ()

[Cacophrene]

Re,

Non. Avec les fonctions d'ordre supérieur (List.map et compagnie), il est fréquent de passer en argument une fonction, et donc des applications partielles.

Très juste, j'ai lu trop vite. Merci pour la correction

Edit: de plus c'est amusant parce qu'en redéfinissant ignore, l'avertissement disparaît.

Cordialement,
Cacophrène

[prgasp77]

Ha oui, amusant

J'aimerais revenir sur une de mes phrases

Elle pourrait donc avoir le type string -> (unit -> unit), mais pour caml, ceci semble être équivalent à string -> unit -> unit.

Je trouve ça un poil gênant au final : imaginez que je parcours rapidement l'interface d'une bibliothèque, et que je trouve une fonction dont le type est celui cité. Je me dis qu'enregistrer pour usage ultérieur la fonction partielle (sans le () final) n'aura aucun effet de bord, celle-ci n'était pas exécutée. Et bien BAM ! Erreur !

Dans un tel cas, pourquoi ne pas laisser les parenthèses ?

[Cacophrene]

Bonjour !

Je crois que ce problème touche avant tout la conception même de la bibliothèque considérée. En effet, les deux écritures suivantes ne sont pas équivalentes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
let f x = print_endline "foo"; fun () -> true
let g x () = print_endline "foo"; true

Une bibliothèque qui utiliserait une écriture comme celle de f (c'est-à-dire avec des effets de bord) devrait le signaler dans la documentation. Enfin bon il y a peut-être une autre explication (je suis un peu à l'ouest en ce moment ).

Cordialement,
Cacophrène

[SpiceGuid]

La présence d'un argument formel a pour effet de différer l'exécution du corps associé à cet argument jusqu'à l'application d'un argument réel.
Comme le suggère Cacophrène on préfère souvent placer tous les arguments avant le corps de la fonction :

Code ocaml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
let f s () =
   print_endline s ;
   print_endline (String.uppercase s)

Comme leur nom l'indique les types fonctionnels ne rendent compte que des valeurs et pas des effets.
Le type unit lui-même ne témoigne pas d'un effet, il témoigne seulement de ce qu'il n'y a qu'une valeur possible et le plus souvent ça trahi un effet.
On pourrait étendre les types fonctionnels avec des annotations pour rendre compte des effets.
Par exemple ce code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fun () -> ()

aurait le type unit -pure-> unit
Tandis que ce code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fun () -> print_endline "hello"

aurait le type unit -effect-> unit

[gasche]

Il y a quand même un certain nombre de cas où on veut justement que les applications partielles fassent quelque chose.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
let make_counter k =
  let count = ref (k - 1) in
  fun () -> incr count; !count
 
let memo f =
    let table = Hashtbl.create 10 in
    fun x ->
      try Hashtbl.find table x with Not_found ->
        let res = f x in
        Hashtbl.add table x res;
        res

Edit : je sais que vous le savez déjà très bien, je voulais seulement souligner que si on dit (à raison) "il faut le préciser dans la doc", et pas "c'est une mauvaise pratique", c'est parce que justement c'est parfois exactement l'effet recherché.

[InOCamlWeTrust]

On peut trouver 300 000 exemples de lignes de code tordues, mais rien, absolument rien, ne remplace les bonnes pratiques de programmation.

Coder simplement des algorithmes efficaces.

Dans les exemples montrés ici, il y a tout de même un grand nombre d'abhérations, comme mettre un argument unit () à une fonction qui possède déjà d'autres arguments... inutile, et surtout, ça n'a aucun sens !

[Cacophrene]

Bonjour !

Dans les exemples montrés ici, il y a tout de même un grand nombre d'abhérations, comme mettre un argument unit () à une fonction qui possède déjà d'autres arguments... inutile, et surtout, ça n'a aucun sens !

Il ne t'aura pas échappé qu'il s'agissait d'un exemple.

Cordialement,
Cacophrène

[InOCamlWeTrust]

Certes, tu as tout à fait raison. Mais je pense que les exemples, par leur statut, se doivent aussi d'être exemplaires !

Ca me fait penser à tous ces bugs que l'on trouve dans OCaml, ou que l'on trouvait, et qui ne concernaient que des exemples si tordus qu'ils ne servaient jamais en pratique et qui se situaient beaucoup de fois à la limite de la définition du langage, dans une zone de pénombre où la sémantique est floue, mal définie. La vraie question, dans ces cas-là, concerne plutôt la mentalité de ces esprits tordus capables de pondre de tels trucs !

[Cacophrene]

Il n'est malheureusement pas toujours facile de savoir quelle est la réponse la mieux adaptée à un interlocuteur donné sur un forum. Il y a des personnes qui apprécient les exemples « grandeur nature » et, comme tu le dis, exemplaires, parce qu'ils ont déjà un niveau suffisant qui leur permet de tirer parti d'un code de plus de 30 lignes (façon de dire) sans souci. D'un autre côté, on trouve des personnes qui seraient noyées par ces considérations annexes alors qu'un exemple maladroit mais percutant leur parle davantage.

Mais il ne fait aucun doute qu'OCaml (d'autres langages aussi sans doute, mais je ne les connais pas bien) permet de dériver lentement mais sûrement vers des codes quasi pervers à cause, précisément, de sa capacité à mélanger les genres. Un peu comme certains gourous du C qui utilisent à tort et à travers une montage de trucs et astuces bas niveau qui rendent illisibles des codes conceptuellement simples.

Et là, oui, tout le monde y perd : le langage, son (ses) implémentation(s), ses utilisateurs et donc son propre avenir !

Cordialement,
Cacophrène

[gasche]

Dans les exemples montrés ici, il y a tout de même un grand nombre d'abhérations, comme mettre un argument unit () à une fonction qui possède déjà d'autres arguments... inutile, et surtout, ça n'a aucun sens !

Je ne comprends pas. Que leur reproches-tu concrètement ?

[InOCamlWeTrust]

D'être tordus.