Discussion :

[_SamSoft_]

Bonjour, cela fait une petite semaine que j'ai débuté en OCaml. Moi qui vient du C, j'ai assez bien compris son fonctionnement. Maintenant que je maitrise la "console" dirons nous, j'aimerai bien faire ce que je faisais en C, c'est à dire des programmes à interfaces graphiques. En C, j'utilisais la SDL et pour le réseau j'utilisais un header dont j'ai oublié le nom.

J'aimerai savoir si je peux faire des programmes à interface graphique et du réseau en OCaml avec une lib (comme SDL ou d'autres [merci de m'en proposer], j'ai entendu parler de tcl\tk) et si cela est bien documenté car OCaml ne semble pas très documenté en ce qui concerne les libs externes.

Merci d'avance

PS: S'il n'existe pas de documentation pour cela, tant pis, je continuerai à utiliser ocaml pour certains programmes (consoles) et le C pour d'autres programmes.

[Garulfo]

Bonjour, cela fait une petite semaine que j'ai débuté en OCaml. [...]

Je doute qu'en une semaine tu ai une bonne compréhension de ce qu'implique la programmation fonctionnelle. À moins que tu n'ai déjà fait de la programmation fonctionnelle, tu dois probablement programmer en ocaml comme tu programmerais en C. Je serais toi j'attendrais un peu pour me lancer ailleurs et j'explorerais plus le paradigme.

Cependant, pour répondre à ta question, il existe effectivement des bibliothèques qui permettent de faire ce que tu veux en ocaml.
Une simple recherche sous google renvoie ça en premier résultat avec « network ocaml » et il y en a d'autres.
http://sourceforge.net/projects/ocnae/
Plus simplement le module Unix te permettra de faire du réseau.
Le défi fonctionnelle numéro 3 peut te donner quelque exemple
http://www.developpez.net/forums/sho...d.php?t=410704
Pour les interfaces, il y a aussi de quoi.

Mais encore une fois, tu devrais approfondir l'essence d'ocaml avant d'aller chercher ça.

[_SamSoft_]

Vous avez raison dans la mesure où mes connaissances en OCaml se rapprochent du C, je n'ai pas cherché à comprendre les classes... Tout simplement car pour le moment, je n'en ai pas besoin m'enfin c'est ok, je vais d'abord me concentrer sur ocaml pour disons, autre chose et j'utiliserai le C pour d'autres projets.

Puis-je utiliser l'ocaml pour certaines actions et le C pour d'autres dans un même projet ? Ca se fait ?

[SpiceGuid]

OCamlSDL, tu l'avais sans doute déjà trouvé par toi-même:

http://ocamlsdl.sourceforge.net/

À ton âge il est difficile de conseiller un quelconque tutoriel car la plupart visent plutôt les étudiants du supérieur. À tort dirait sans doute InOCamlWeTrust, et quand je regarde mon propre tutoriel (qui n'est pas si mauvais mais qui ne s'adresse pas à ta tranche d'âge) je me souviens qu'il m'avait mis en garde dès le début contre le penchant à placer la barre trop haut.

InOCamlWeTrust si tu nous lis, tu te fais trop rare.

PS: je voulais faire une suite à mon jeu, en OCaml cette fois, mais je ne suis pas assez motivé, si tu le souhaite le projet est à toi (contacte-moi par message privé)

[Garulfo]

Vous avez raison dans la mesure où mes connaissances en OCaml se rapprochent du C, je n'ai pas cherché à comprendre les classes...

En fait je ne pensais pas aux classes, mais à tout ce qu'offre le fonctionnel qui lui est propre.

Donc prends le temps de comprendre la programmation par flots (map, fold, filter etc.) et l'utilisation des fonctions de haut niveau.

[alex_pi]

Bonjour, cela fait une petite semaine que j'ai débuté en OCaml. Moi qui vient du C, j'ai assez bien compris son fonctionnement.

Juste pour faire un test, soit l une liste d'entier, peux tu m'écrire la fonction récupérant les entiers pairs de cette liste ?

A coté de ça, soyons honnêtes, les interfaces graphiques sous OCaml, c'est pas la panacé.. Mais un binding Qt est en préparation ! Mmmh!!

[_SamSoft_]

Merci pour tout, je vais donc suivre vos conseils et apprendre en profondeur ce langage si super !

En ce qui concerne la reprise du jeu, je ne pense pas mais merci quand même

En ce qui concerne le code, je m'y met de suite

PS: Désolé pour la réponse tardive.

[_SamSoft_]

Code :

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

1
2
3
4
5
6
7
8
9
10
let i = [| 2 ; 0 ; 20 ; 172 ; 4 ; 29 ; 256 ; 1024 ; 89 ; 2078 ; 64 ; 4096 ; 22 ; 7 ; 1 ; 9029 |] in
let indice = ref 0 in
    for x = 1 to (Array.length i) do
        print_int (i.(!indice));
        if i.(!indice) mod 2 = 0
        then print_string "pair\n"
        else print_string "impair\n";
        indice := !indice+1;
    done;
;;

Voilà Ca fonctionne, si j'ai pris un peu de temps c'est parce que j'avais écrit ca et je trouvais pas l'erreur:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
let i = [| 2 ; 0 ; 20 ; 172 ; 4 ; 29 ; 256 ; 1024 ; 89 ; 2078 ; 64 ; 4096 ; 22 ; 7 ; 1 ; 9029 |] in
let indice = ref 0 in
    for x = 1 to (Array.length i) do
        if i.(!indice) mod 2 = 0
        print_int (i.(!indice));
        then print_string "pair\n"
        else print_string "impair\n";
        indice := !indice+1;
    done;
;;

[Jedai]

D'une part ce n'est pas ce qu'a demandé alex_pi (il a demandé une liste, pas un tableau, et il a demandé de récupérer les entiers pairs dans cette liste, pas de les afficher), d'autre part c'est très lourd, une solution fonctionnelle serait :

Code :

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

let getEvens xs = let even n = n mod 2 = 0 in List.filter even xs

Tu peux l'appliquer sur une liste comme ça :

Code :

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

getEvens [ 2 ; 0 ; 20 ; 172 ; 4 ; 29 ; 256 ; 1024 ; 89 ; 2078 ; 64 ; 4096 ; 22 ; 7 ; 1 ; 9029 ]

et tu obtiendras la liste des entiers pairs de la liste d'entrée : [2; 0; 20; 172; 4; 256; 1024; 2078; 64; 4096; 22].

Tu comprends ce qu'on veut dire par "changement de paradigme" ? Ton code est impératif, écrire de l'impératif en OCaml est un peu mieux qu'en C ou autre langage de bas niveau, mais n'exploite pas vraiment la puissance du langage.

--
Jedaï

[SpiceGuid]

Pour Gtk2 il y a déjà LablGtk avec un tutoriel dedié.

Maintenant que j'ai installé Puppy Linux ça commence à m'intéresser, quels sont vos retours d'expérience avec LablGtk ?
Ou bien alors vous êtes tous sur KDE à attendre un binding Qt ?

[alex_pi]

Voilà Ca fonctionne,

Comme l'a dit Jedai, ce n est pas ce que j ai demande, mais en tout cas, ca prouve effectivement que, je suis desole, tu n'as pas dutout effectue la transition du C vers OCaml, tu as juste fait un changement de syntaxe.

La reponse que j'attendais etait

Code :

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

1
2
 
let pairs = List.filter (fun n -> n mod 2 = 0)

Un peu plus court non?

Bref, tente de te trouver un bon tutoriel/bouquin pour vraiment t'impregner du langage, et surtout, oublie tes reflexes de codeur C !!

[LLB]

Un conseil : dans un premier temps, essaie de n'utiliser aucun "ref", "for", "while".
Essaie de comprendre ce qu'est une fonction anonyme (mot clé "fun" ou "function"). Apprends aussi à utiliser les fonctions du module List.

Normalement, un bon cours Caml devrait commencer par ces aspects.

Quand tu auras bien compris tout ça, tu pourras utiliser les "ref", les boucles, les objets, et découvrir les bibliothèques graphiques.

[InOCamlWeTrust]

Moi j'adore comment code Jedaï : c'est très Haskellien, hyper ramassé, compact. Honnêtement, ce genre de code ne me vient jamais à l'esprit : je pense que ça doit être mon éducation trop orientée OCaml.

En OCaml pur, je pense qu'on écrirait quelque chose dans ce style...

Code :

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

1
2
3
4
5
 
let rec get_evens = function
    | [] -> []
    | n :: l when n mod 2 = 0 -> n :: (get_evens l)
    | _ :: l -> get_evens l

ou plus classique...

Code :

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

1
2
3
4
5
6
7
8
9
10
 
let rec get_evens = function
    | [] -> []
    | n :: l ->
        let evens = get_evens l in
 
        if n mod 2 = 0 then
            n :: evens
        else
            evens

ou encore...

Code :

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

1
2
3
4
5
6
7
8
 
let rec get_evens = function
    | [] -> []
    | n :: l ->
        if n mod 2 = 0 then
            n :: (get_evens l)
        else
            get_evens l

À ton âge il est difficile de conseiller un quelconque tutoriel car la plupart visent plutôt les étudiants du supérieur. À tort dirait sans doute InOCamlWeTrust, et quand je regarde mon propre tutoriel (qui n'est pas si mauvais mais qui ne s'adresse pas à ta tranche d'âge) je me souviens qu'il m'avait mis en garde dès le début contre le penchant à placer la barre trop haut.

En français, il y a le bouquin de référence de O'Reilly : il décrit tout de façon assez simple, et je pense qu'il peut effectivement convenir à une personne de 16 ans, étant donné qu'aucun formalisme mathématique n'est abordé (juste deux mots à propos des grammaires, mais ça peut se sauter allègrement).

Sinon, je crois que des tutos en anglais seraient meilleurs, étant donné que les anglo-saxons, pour peu qu'ils ne soient pas Haskelliens, ont une vision très pragmatique des choses.

InOCamlWeTrust si tu nous lis, tu te fais trop rare.

Rare, je sais pas, mais j'ai, comment dire, changé de voie dernièrement... donc c'est peut-être un peu pour ça aussi. Mais promis, dès que je trouve un stage qui me convient, je me remets un peu à la programmation.

[LLB]

Je ne suis pas d'accord : en "Ocaml pur", on utilise les fonctions fournies, au lieu de les recoder. Naturellement, j'aurais écrit exactement la même chose qu'alex_pi.

Recoder les fonctions du module List, c'est bien quand on apprend le langage et que le découvre le fonctionnement des listes. Dans la vraie vie, on préfère généralement utiliser les fonctions d'ordre supérieur. Les fonctions d'ordre supérieur sont quand même un grand intérêt de la programmation fonctionnelle.

Je code tous les jours en fonctionnel et j'utilise de moins en moins d'utiliser la récursion. Et une récursion sur une liste, c'est encore beaucoup plus rare : les fonctions de la bibliothèque standard suffisent dans la majorité des cas.

(Oui, ça rejoint l'autre discussion, avec les tables de hachage)

[_SamSoft_]

Bonjour, d'après ce que j'ai lu, je pense encore en C quand je code en OCaml Je vais pas le cacher, c'est vrai. Je vais donc essayer de trouver ce bouquin d'O'Reilly et m'y mettre durant les vacances d'été en attendant sur mon temps libre (qui commence à se faire rare à cause du bac français qui approche...) je vais chercher des petits tutos et coder par moi même pour me préparer à mon grand apprentissage via l'ouvrage que vous m'avez proposé.

Merci pour tout

[InOCamlWeTrust]

Recoder les fonctions du module List, c'est bien quand on apprend le langage et que le découvre le fonctionnement des listes. Dans la vraie vie, on préfère généralement utiliser les fonctions d'ordre supérieur. Les fonctions d'ordre supérieur sont quand même un grand intérêt de la programmation fonctionnelle.

Il ne s'agit pas de recoder les fonctions de List, mais tout simplement de coder une fonction qui fait quelque chose de petit et précis. Les codes avec itérateurs ne sont pas si naturels que ça (en tous cas, moi, ils ne me viennent pas toujours à l'esprit du premier coup) et obligent parfois de devoir coder une fonction auxiliaire devant être itérée (celle que l'on passe en argument en général). Pour un cas aussi simple que celui-ci, je suis d'accord que ça peut se discuter, mais pour des programmes plus gros... En tous cas, dans le code de OCaml lui-même, ça itère bien à la main pour les traitements un peu plus costauds.

C'est juste une question de mentalité. Encore une fois, on ne code pas en Haskell comme en OCaml, et vice-versa (ceci est vrai d'ailleurs pour tout autre langage).

[LLB]

Je trouve en général les itérateurs plus clairs à lire. Ça dépend bien sûr des cas (et le fold est parfois peu évident à comprendre), mais c'est souvent intéressant de les utiliser. D'une part, le nom de la fonction indique ce que tu veux faire. Dès que l'on voit le mot "filter", "map", "iter" ou autre, on comprend tout de suite l'intention du développeur. Ça réduit souvent aussi les risques d'erreurs.

D'autre part, ça ajoute de l'abstraction. Si tu veux changer de type de structure plus tard, c'est beaucoup plus simple. Tu as juste à remplacer List par Array ou autre pour que tout marche. Tu n'as pas à réécrire tout le code.

Enfin, ça présente un certain nombre d'avantages au niveau de la composition du code. Tu peux combiner tes fonctions plus facilement, tu peux mieux les réutiliser. Ce point est plus pertinent en F#, car les opérateurs pour manipuler les fonctions sont plus utilisés, mais ça reste vrai pour OCaml.


Bien sûr, ça dépend aussi du style de programmation. Je n'ai pas encore étudié le code du compilateur Caml ; mais celui de F# utilise pas mal d'itérateurs. Je suis d'accord que ça dépend de la mentalité. Mais je ne crois pas que ce soit lié à Caml vs. Haskell.

[Jedai]

Il ne s'agit pas de recoder les fonctions de List, mais tout simplement de coder une fonction qui fait quelque chose de petit et précis. Les codes avec itérateurs ne sont pas si naturels que ça (en tous cas, moi, ils ne me viennent pas toujours à l'esprit du premier coup) et obligent parfois de devoir coder une fonction auxiliaire devant être itérée (celle que l'on passe en argument en général). Pour un cas aussi simple que celui-ci, je suis d'accord que ça peut se discuter, mais pour des programmes plus gros...

C'est bien n'importe quoi... considère ton code et le mien, lequel trouves-tu le plus lisible ? Il arrive parfois qu'on ait besoin de recoder un traitement de liste un peu particulier ou que l'emploi d'un fold obscurcisse plus qu'autre chose un traitement, mais recoder filter ou map à chaque fois qu'on a besoin de leurs fonctionnalités ? C'est ridicule.

Il n'est pas question ici d'Haskell, qui a effectivement un style de programmation assez différent d'OCaml pour certaines choses, je programmais déjà en OCaml comme ça avant même de connaître quoi que ce soit d'Haskell.

Réemployer la récursion explicite à chaque fois qu'on doit traiter une liste n'est pas fonctionnel, c'est juste lourd et lassant, c'est bon pour les initiation au fonctionnel pour comprendre comment ça marche, après on doit savoir réutiliser ses fonctions d'ordre supérieur.

Heureusement OCaml est suffisamment performant pour que tu n'ais pas besoin de recoder ce genre de parcours. Si jamais ton programme est trop lent, ce ne sera pas parce que tu auras utilisé quelques fonctions d'ordre supérieur, mais bien pour des questions d'algorithmes ou de structure de donnée mal choisies.

--
Jedaï

[Garulfo]

C'est bien n'importe quoi... [...] Il arrive parfois qu'on ait besoin de recoder un traitement de liste un peu particulier ou que l'emploi d'un fold obscurcisse plus qu'autre chose un traitement, mais recoder filter ou map à chaque fois qu'on a besoin de leurs fonctionnalités ? [...]
Réemployer la récursion explicite à chaque fois qu'on doit traiter une liste n'est pas fonctionnel, c'est juste lourd et lassant, c'est bon pour les initiation au fonctionnel pour comprendre comment ça marche, après on doit savoir réutiliser ses fonctions d'ordre supérieur.

Je suis complètement d'accord. C'est comme certains de mes collègues qui refusent d'utiliser foreach parce qu'ils n'en ont pas besoin... on a pas besoin non plus d'un langage de haut niveau, mais c'est bien pratique. Ce sont bien sûr essentiellement des profs d'un certains ages le genre qui refuse à tout prix les GC parce qu'ils sont convaincus que ça ne sera jamais efficace.

De plus, si le fold pour une certaine structure est une primitive, il est possible qu'il déjà soit fortement optimisé (complètement sous forme itérative). Dans ce cas, son utilisation est plus efficace que copier son comportement.

Là où je comprends IOCWT c'est qu'il faut une certaine habitude. Mais, d'après moi, c'est dans ce genre de détail où on voit la maîtrise en programmation fonctionnelle.

[gasche]

Il existe quand même des cas où la recursion explicite est à mon avis bienvenue, faute de mieux.

La récursion est un outil extrêmement puissant, qui permet des comportements très riches. C'est d'ailleurs précisément l'argument des gens qui déconseillent la récursion explicite; ils disent qu'il ne faut pas l'utiliser quand on peut résumer notre utilisation de la récursion à un schéma simple, que l'on rencontre souvent, et qui a son opérateur haut-niveau associé (map, filter, fold...). La formule choc ici est "la récursion explicite est le goto de la programmation fonctionnelle".

Certes, mais, tout comme goto, il existe des cas où on n'a pas d'opérateur adapté sous la main, parce qu'on veut faire quelque chose d'un peu différent. Par exemple :

Code :

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

1
2
3
let rec split = function
| ([] | [_]) as li -> li, []
| ha::hb::tl -> let a, b = split tl in ha::a, hb::b

Ce code "ressemble" à un fold_right. On pourrait, à l'aide d'un outillage un peu plus important, l'exprimer comme un fold_right : il s'agit de découper la liste en une liste de paire d'éléments, puis de faire un fold_right sur ces paires.
J'imagine qu'un haskellien penserait par exemple à un fold_right sur "iterate (drop 2) ...".

Mais est-ce qu'on y gagne vraiment quelque chose ? Je ne connais pas tout l'outillage de GHC mais je doute qu'on puisse produire une fonction plus courte que celle que j'ai proposée, et je suis certain qu'elle ne sera pas plus compréhensible.

Plus généralement, il y a une idée de "rapport qualité/prix" derrière. Effectivement, on pourrait créer un opérateur pour chaque type de parcours récursif connu, et en rajouter au besoin. Mais plus on ajoute d'opérateurs, plus il est difficile pour un programmeur d'avoir tous les opérateurs à l'esprit en même temps (un débutant a déjà pas mal de mal à différencier un fold_right d'un fold_left, et pour troller je dirais que les confirmés aussi, puisque les haskelliens n'ont pas été foutu de mettre l'ordre correct des arguments de fold_right), et plus l'ajout de nouveaux opérateurs perd de l'intérêt.

Il faut donc trouver un bon compromis : un nombre raisonnable d'opérateurs le plus utiles possibles, sans en être complètement dépourvus, mais sans faire dans l'excès (des myriades d'opérateurs quasiment inutiles n'aident pas). OCaml pourrait certainement se doter d'un peu plus d'opérateurs (et c'est d'ailleurs le but de plusieurs projets, donc ExtLib), mais il restera forcément des cas où la récursion explicite est le choix le plus simple, et c'est très bien.