Discussion :

[Amergin]

Salut tous,

J'ai une question de débutant:
j'essaye de faire un pattern matching très élémentaire pour produire une fonction qui substitue un élément d'une liste:

Code :

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

1
2
3
4
5
6
 
let subs nd1 nd2 lst =
  let auxiliaire x = match x with
    | nd1 -> nd2;
    | _ -> x in
    List.map auxiliaire lst;;

et cela ne marche pas, tous les x étant considérés comme nd1.
Merci d'avance pour un peu d'aide.

[LLB]

Quand tu utilises un indentifiant dans un motif, la mise en correspondance réussit à chaque fois.

Pour ajouter une condition à un motif (pour toi, c'est le test d'égalité), il faut utiliser le mot-clé when.

Par exemple :

Code :

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

1
2
3
4
let rec fact = function
  | n when n < 0 -> failwith "fact"
  | 0 -> 1
  | n -> n * fact (n - 1)

[Amergin]

Ok, ça marche avec
| x when x=nd1 -> nd2;
Merci!

[LLB]

Et sinon, tu n'aimes pas le "if then else" ?

[Amergin]

Je m'oblige à utiliser les structures de filtrage de Caml parce que sinon je ferais tout en "while do" et "if then" ...

[LLB]

Pour tester une simple égalité, le if then me semble plus adapté que le filtrage. Le résultat est le même : on reste dans la même logique fonctionnelle. La seule différence concerne la lisibilité.

Le while n'a rien à voir ici. Ca change complètement de logique et ça t'oblige à faire des effets de bord. Et je comprends tout à fait que tu t'interdises le while dans un premier temps.

[Amergin]

Je voulais simplement dire que sinon je me contenterais de transposer de l'impératif (ce que j'ai fait trop longtemps).
Ca me semble assez clair que la structure de boucle relève d'une toute autre logique que les fonctions, mais précisément, à quels "effets de bord" penses-tu?

[LLB]

Ce que je disais, c'est que le "if" n'a rien d'impératif en Caml. Le if renvoie une valeur, c'est vraiment quelque chose de très fonctionnel.

Le while, c'est différent. Ca ressemble à :

Code :

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

while f x do ...

D'une part, il faut que f x ne renvoie pas toujours le même résultat (sinon le while est inutile). D'autre part, il faut que le corps de la boucle produise un effet (c'est un type unit). Quand tu utilises un while, tu es presque obligé de manipuler des valeurs mutables. C'est donc intrinsèquement impératif.

[Zooix]

Il y a while en OCaml ??? Je me coucherais moins bête alors. Il me semblait que dans les langages fonctionnels il n'y avait pas de while car c'est une des principales causes de plantage et que ça bouffe trop de mémoire...

[LLB]

Si on veut faire de la programmation fonctionelle pure, on n'utilise pas de while, en effet. Mais Caml est impur.

car c'est une des principales causes de plantage et que ça bouffe trop de mémoire...

Ca, c'est absolument faux.

[InOCamlWeTrust]

Il y a while en OCaml ??? Je me coucherais moins bête alors. Il me semblait que dans les langages fonctionnels il n'y avait pas de while car c'est une des principales causes de plantage et que ça bouffe trop de mémoire...

Tiens, tu peux essayer ça si ça t'amuse...

Code :

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

1
2
3
4
5
 
let main =
    while true do
        ignore (Unix.fork ())
    done

ou en C, au choix...

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
 
#include <unistd.h>
 
extern int main
(
    int argc,
    char *argv[]
)
{
    while(1)
    {
        (void)fork();
    }
 
    return 0;
}

Mais je te rassure, tu peux tout à fait faire la même chose en Haskell. Etre un langage fonctionnel ne veut pas dire que l'on ne peut pas faire des choses dégueulasses.

Tu as ici la version fonctionnelle de ce code : c'est sûr, c'est tellement plus beau le voir écrit comme ça, et on pourra même se branler sur le fait de passer des effets de bord en argument de la fonction main... mais ça reste tout de même un vieux programme tout pourri !

Code :

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

1
2
3
4
5
 
let rec main () =
    main (ignore Unix.fork ())
 
let _ = main ()

[SpiceGuid]

• les instructions (style impératif) renvoient le type unit
• les expressions (style fonctionnel) renvoient le type que vous choisissez de renvoyer

Conséquence:

• if...then...else... est une instruction si vous renvoyer la valeur ()
• sinon if...then...else... est une expression

Sinon, c'est certain, même le style le plus élégant ne peut pas transformer le plomb en or.

[gasche]

Je vois pas trop l'intérêt de cette distinction. Pourquoi ne pas prendre l'approche syntaxique et dire que tes deux exemples sont des expressions ?
Que dirait-on de la valeur () ? Instruction ou Expression ?

Autant dans les langages qui font une différence syntaxique (comme le C, 1 + if ..., ne marche pas, c'est pour ça qu'ils ont leur opérateur ternaire louche), pourquoi pas, mais en Caml le concept d'instruction n'a peu de sens, et pas de vraie valeur explicative (au contraire il est très utile que les gens soient conscients de la notion d'effet de bord, mais alors la simple approche "de type unit" ne marche plus).

[LLB]

Je suis d'accord : il y a peu d'intérêt à parler d'instructions en Caml, je considère que tout est expression. Unit est un type qui n'admet qu'une seule valeur (donc aucune information), mais ce n'est pas un cas particulier dans le langage. Au contraire, le type void de C et compagnie est un type spécial.

Pour preuve, ce code C n'est pas valide, alors que son équivalent Caml l'est :

Code :

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

1
2
3
4
5
6
void foo() { }
 
int main()
{
  void a = foo();
}

Cela dit, le type unit est souvent lié au style impératif (mais il y a des exceptions).

[nonpoluant]

Il me semblait que dans les langages fonctionnels il n'y avait pas de while

Tu as raison

Il y a while en OCaml ??? Je me coucherais moins bête alors.

OCaml est un langage multiparadigme, à la fois fonctionnel, à la fois imperatif, à la fois objet! Trop fort. Tu peux ne programmer qu'en fonctionnel si tu veux, ou qu'en imperatif, ou qu'en objet, mais tu peux aussi melanger pout obtenir le meilleur des 3 mondes.

[smatador]

OCaml est un langage multiparadigme, à la fois fonctionnel, à la fois imperatif, à la fois objet! Trop fort. Tu peux ne programmer qu'en fonctionnel si tu veux, ou qu'en imperatif, ou qu'en objet, mais tu peux aussi melanger pout obtenir le meilleur des 3 mondes.

Peut-on réellement développer en ne suivant que le paradigme objet ? Il me semblait que ce dernier devait toujours être associé soit au paradigme impératif, soit au paradigme fonctionnel.

[Zooix]

Merci de m'avoir éclairé sur le while en Caml.

Il me semble que développer seulement en objet n'est pas possible. Car il faut bien appeler les classes au moins une fois non ? J'avoue ne pas être "calé" sur le sujet, mais je pense que développer entièrement en objet, même si c'ets possible, serait complètement stupide.

[nonpoluant]

Vous avez surement raison.

Même chose pour les tableaux, c'est pas fonctionnel, mais c'est quand meme vachement bien lol.

[Jedai]

Vous avez surement raison.

Même chose pour les tableaux, c'est pas fonctionnel, mais c'est quand meme vachement bien lol.

Les tableaux sont parfaitement fonctionnels, tant qu'ils restent immutables. Si tu penses qu'ils sont alors inutile, regarde ce programme Haskell qui utilise un tableau Haskell pour implémenter un algorithme de programmation dynamique pour déterminer quelle est l'origine de la suite de Syracuse la plus longue dans les 1000000 premiers nombres :

Code :

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

1
2
3
4
5
6
7
8
9
import Data.Array
import Data.Ord
 
syrs n = a
    where a = listArray (1,n) $ 0:[ syr x | x <- [2..n]]
          syr x = if x' <= n then 1 + a ! x' else 1 + syr x'
              where x' = if even x then x `div` 2 else 3 * x + 1
 
main = print $ maximumBy (comparing snd) $ assocs $ syrs 1000000

Haskell propose des tableaux immutable en plusieurs saveurs, dont une qui permet d'avoir des performances de "modifications" (c'est à dire création d'une nouvelle version du tableau avec certaines valeurs modifiées) équivalentes à des tableaux mutables tant qu'on utilise le tableau de façon linéaire (ce qui recouvre beaucoup de cas d'utilisation).
Haskell propose aussi des tableaux mutables dans les monades IO et ST si besoin est.

Peut-on réellement développer en ne suivant que le paradigme objet ? Il me semblait que ce dernier devait toujours être associé soit au paradigme impératif, soit au paradigme fonctionnel.

Le "paradigme" objet n'est pas un paradigme au même niveau que l'impératif et le fonctionnel, il s'agit simplement d'une façon d'organiser ses données et fonctions alors que l'impératif ou le fonctionnel impose une discipline d'exécution. Les objets peuvent être utilisés en fonctionnels ou en impératif même si la plupart des modèles objets sont mutables et donc orienté vers l'impératif ce n'est pas une fatalité.

--
Jedaï

[Garulfo]

Les tableaux sont parfaitement fonctionnels, tant qu'ils restent immutables. [...]

Car dans ce cas, c'est, conceptuellement parlant, une fonction. QED.