Discussion :

[SpiceGuid]

Dans son chapitre L05 Laurent Le Brun présente 4 opérateurs standards en F# :

Code :

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

1
2
3
4
5
let (<<) g f x = g (f x)
and (>>) f g x = g (f x)
and (|>) x f = f x
and (<|) f x = f x
;;

Puis-je utiliser ces mêmes définitions en OCaml sans compromettre la portabilité vers F#, la priorité respective de ces 4 opérateurs est-elle exactement identique dans les deux langages ?

[Garulfo]

Dans son chapitre L05 Laurent Le Brun présente 4 opérateurs standards en F# :

Code :

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

1
2
3
4
5
let (<<) g f x = g (f x)
and (>>) f g x = g (f x)
and (|>) x f = f x
and (<|) f x = f x
;;

Puis-je utiliser ces mêmes définitions en OCaml sans compromettre la portabilité vers F#, la priorité respective de ces 4 opérateurs est-elle exactement identique dans les deux langages ?

C'est quoi dans F# ?
Je trouve que c'est un mauvais choix >> et << pour la composition. Était-ce un exemple de cours ?
C'est ce genre de choix qui fait qu'il y des détracteurs de la surcharge d'opérateurs en C++ par exemple. Il faut essayer de garder un sens « classique » au symbole. Maintenant, il faut reconnaître que << et <| n'est pas vraiment de sens classique.

[LLB]

Il me semble que les règles de priorité sont assez proches. Je ne peux pas garantir, mais je pense que c'est compatible. Je viens de tester le code suivant, Caml l'accepte sans problème :

Code :

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

1
2
3
4
 
[1; 2; 3; 4] |> List.map succ
               |> List.map (( * ) 2)
               |> List.iter (Printf.printf "%d")

J'ai fait quelques autres tests, ça me semble avoir le même comportement.

Je trouve que c'est un mauvais choix >> et << pour la composition. Était-ce un exemple de cours ?

Non, c'est défini dans la bibliothèque standard de F#. Ces opérateurs sont régulièrement utilisés, et je trouve ça dommage que Caml ne les ait pas par défaut.

C'est ce genre de choix qui fait qu'il y des détracteurs de la surcharge d'opérateurs en C++ par exemple. Il faut essayer de garder un sens « classique » au symbole. Maintenant, il faut reconnaître que << et <| n'est pas vraiment de sens classique.

Ce n'est pas de la surcharge d'opérateurs ici : << et >> n'ont qu'un seul sens (contrairement à C++). En Caml, ces opérateurs n'ont pas de définition par défaut. Leur en donner une n'est donc pas malsain (à mon avis).

Tu fais peut-être allusion aux décalages de bits du C. Il me semble que les décalages de bits sont rarement utilisés (beaucoup moins qu'en C, en tout cas) dans les langages de haut-niveau ; utiliser >> et << pour des opérateurs fonctionnels me semblent donc une bonne idée, dans un langage fonctionnel.

Tu peux critiquer ces symboles, mais je les trouve relativement clairs. Le chevron indique le sens. "abs >> succ" indique que le résultat de abs est renvoyé dans succ. C'est relativement clair, je trouve. Et le "|>" a la même logique que que le pipe. Ce qui est assez intuitif (plus que les symboles utilisés dans Haskell, à mon gout).

[Jedai]

Et car et cdr c'est des bons choix de noms de fonctions je suppose ?
(>>) et (|>) n'ont pas d'interprétation classique, néanmoins ils ont au moins une orientation évidente. Ils sont plutôt bien choisis tant qu'on autorise pas unicode pour avoir les vrais opérateurs mathématiques (compositions...).

Franchement les critiques de la surcharge d'opérateur m'ont toujours semblé assez faibles, effectivement on peut faire du grand n'importe quoi avec, effectivement il n'aident pas à la compréhension si on ne connait pas la librairie employée, mais franchement même avec des fonctions bien nommées, il est difficile de déchiffrer une application écrites avec des API inconnues, et une fois dépassé cet obstacle initial, les opérateurs permettent une concision et une lisibilité supérieures à mon sens.

Par ailleurs (>>) ou (|>) ne sont pas des opérateurs ad hoc choisis pour le cours, ce sont des opérateurs standards en F#.

Quand à la question, a priori tu peux attribuer la précédence et l'associativité que tu veux aux opérateurs en OCaml.

--
Jedaï

[LLB]

Quand à la question, a priori tu peux attribuer la précédence et l'associativité que tu veux aux opérateurs en OCaml.

Ah ? C'est possible sans jouer avec Camlp4 ? Quelles sont les règles utilisées par défaut ? Pour F#, les règles de priorité sont ici (la priorité et l'associativité dépend du premier caractère) :
http://research.microsoft.com/fsharp...spx#Precedence

|> et >> ont donc une priorité relativement faible.

[Jedai]

Tu peux critiquer ces symboles, mais je les trouve relativement clairs. Le chevron indique le sens. "abs >> succ" indique que le résultat de abs est renvoyé dans succ. C'est relativement clair, je trouve. Et le "|>" a la même logique que que le pipe. Ce qui est assez intuitif (plus que les symboles utilisés dans Haskell, à mon gout).

Il est vrai que le ($) n'est pas intuitif (on s'habitue vite tout de même), par contre le (.) pour la composition est plus proche du symbole mathématique, bien sûr pour un langage avec des objets, son usage pose d'autres problèmes...

Par ailleurs (>>) est déjà pris pour le 'then' des monades, où il est assez "intuitif" également.

--
Jedaï

[SpiceGuid]

J'essaye sur le problème des 8 reines.
D'abord quelques fonctions auxiliaires:

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
16
17
18
19
20
21
22
23
let rec exists_commutative p l =
  match l with
  | []   -> false
  | h::t -> (List.exists (p h) t) or exists_commutative p t;;
 
let rec distribute a l =
  match l with
  | []   -> [[a]]
  | h::t -> (a::l) :: (List.map (fun x -> h::x) (distribute a t));;
 
let rec permute l =
  match l with
  | []   -> [[]]
  | h::t -> List.flatten (List.map (distribute h) (permute t));;
 
let rec mapi f n l =
  match l with
  | [] -> []
  | h::t -> f n h::mapi f (n+1) t;;
 
let check_queens (xa,ya) (xb,yb) =
  (xa - xb) = (ya - yb) or
  (ya - yb) = (xb - xa) ;;

Ma solution sans pipe:

Code :

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

1
2
3
4
5
6
7
8
let safe_boards queens =
  let no_pair f l = exists_commutative f l = false
  and pair a b = a,b in
  let map_pair i = mapi pair 1 in
    filter
    (no_pair check_queens) 
    (mapi map_pair 1 (permute queens))
  ;;

Ma solution avec pipe:

Code :

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

1
2
3
4
5
6
7
8
9
let safe_boards queens =
  let no_pair f l = exists_commutative f l = false
  and pair a b = a,b in
  let map_pair i = mapi pair 1 in
    queens  |>
    permute |>
    mapi map_pair 1 |>
    (check_queens |> no_pair |> filter)
  ;;

Ca doit être une question d'habitude parce que là j'ai un peu du mal à reconnaître mon code. Et en cas d'erreur de typage, on retrouve ses petits ?
En tout cas ça a l'air portable.

[gasche]

Le standard mathématique est de mettre la fonction avant l'argument. Il arrive qu'il soit plus pratique de faire l'inverse, par exemple quand on met bout à bout (que ce soit par composition ou piping) des fonctions de "traitement" : entree |> prepare |> compute |> sortie, par exemple.

Cependant, ce n'est pas toujours le cas. En particulier la fonction "filter" gagne à être immédiatement suivie du prédicat de filtrage : "filtre suivant la condition machin" est une action que l'on imagine bien, "génère la condition machin et applique lui la fonction qui crée un filtre" est beaucoup moins clair.

Je suggère plutôt quelque chose du style :

Code :

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

queens |> permute |> mapi map_pair 1 |> filter (no_pair check_queens)

Tu peux même si ça t'amuse coder l'ensemble de ta fonction en style point-free :

Code :

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

1
2
3
4
let safe_boards =
  let pair a b = a, b in
  permute >> mapi (mapi pair 1) 1 >> filter (not << exists_commutative check_queens)
  ;;

Par ailleurs, j'ai le sentiment que des tableaux seraient plus adaptés au problème.