Discussion :

[info_sara]

bonjour,
est ce que les concepts de langages fonctionnels tel que Fonctions d’ordre supérieur, Lazy evaluation, Pattern matching, Polytypes et inférence de types,lamda-calcul se trouvent dans Caml, lisp et sheme?
je sais que lamda-calcul se trouve dans lisp ,scheme et ne se trouve pas dans caml mais les autre concepts???

[LLB]

Fonctions d'ordre supérieur : présent dans tous les langages fonctionnels
Lazy evaluation : ce n'est par défaut dans aucun des 3 langages. OCaml possède des outils pour l'avoir de façon explicite (j'imagine que dans Scheme/Lisp on trouve la même chose).
Pattern matching : OCaml, oui. Lisp/Scheme, non, pas directement (des extensions comme Qi peuvent l'ajouter).
Polymorphisme : oui
Inférence de type : OCaml, oui. Lisp/Scheme, ça n'a pas de sens, puisque typage dynamique (mais Qi peut l'ajouter).
Le lamda-calcul est en natif dans OCaml.

[Jedai]

Si tu cherches un langage purement fonctionnel, tourne toi vers Haskell, c'est le seul langage fonctionnel pur à évaluation paresseuse à l'exception de Clean.
Haskell a un système de type très riche, plus que Caml (bien qu'il n'ait pas d'objet comme OCaml, c'est à dire pas de sous-typage), de l'inférence de type presque totale, des fonctions d'ordre supérieur, de l'évaluation paresseuse par défaut, basé sur un lambda-calcul typé, pattern-matching...
Tu peux jeter un coup d'oeil à notre forum Haskell pour plus d'information et quelques ressources.

--
Jedaï

[gasche]

Attention, les premières versions de Lisp (et encore certaines de nos jours, hum hum elisp) utilisaient une portée dynamique, alors que le lambda-calcule utilise une portée lexicale. Ce n'était donc pas un véritable lambda-calcul. Scheme relève un peu tout ça.

Ce que tu décris ressemble plus à un langage fonctionnel statiquement typé (polymorphisme, pattern matching...) : OCaml, SML, Haskell, Clean, etc. Si tu veux en plus de l'évaluation paresseuse comme stratégie par défaut, Haskell est en effet un bon choix (de plus c'est sans doute celui qui sert la le plus été utilisé comme "jouet" par les gens qui testent des fonctionnalités louches pour le système de typage; du coup c'est un peu bloated mais bon, on ne peut pas tout avoir).

[info_sara]

Le lamda-calcul est en natif dans OCaml.

mais j'ai trouvé cette notion dans lisp, puisque j'ai fait une étude sur les 3 langages

[InOCamlWeTrust]

Oui, et ben écoute un peu ce qu'on te dit : en OCaml, tu la trouves en dûr, en vrai ! mais avec une syntaxe différente.

Honnêtement, quand tu connais un tout petit peu, même si tu ne les as jamais vus, les gens qui ont fait Caml, tu ne peux pas en douter !

[gasche]

Ceci dit, il faut reconnaître que pour l'étude du simple lambda-calcul, l'évaluation paresseuse est plus pratique puisqu'elle a l'avantage de terminer quand c'est possible. Après si on veut étudier spécifiquement le call-by-value, OCaml est sans doute plus adapté (même si Haskell peut le faire avec les opérateurs stricts, tout comme OCaml peut expliciter une stratégie paresseuse), et dans la plupart des cas la stratégie d'évaluation ne joue pas (donc il suffit de prendre celui des deux qu'on connaît et de s'amuser, en essayant de ne pas laisser le typage nous brutaliser), mais par exemple si tu veux écrire un combinateur de point fixe lambda-calcul-esque, c'est légèrement plus facile en call-by-name ou équivalent.

Après, il y a aussi des désavantages "de fond" qui viennent avec la paresse, comme les problèmes de lifting : si on veut avoir un point de vue simple sur les types algébriques, qu'on est jeune et innocent et qu'on pense que quand A et B ont un nombre finis Na et Nb d'habitants, alors A * B devrait en avoir (Na * Nb), il vaut mieux utiliser un langage strict.

Le mieux serait encore d'utiliser un langage total, mais donner Coq au gentil curieux débutant, ça s'apparente sans doute à de la maltraitance.

[Alp]

Le mieux serait encore d'utiliser un langage total, mais donner Coq au gentil curieux débutant, ça s'apparente sans doute à de la maltraitance.

Et FoCal ?

[Garulfo]

Attention, les premières versions de Lisp (et encore certaines de nos jours, hum hum elisp) utilisaient une portée dynamique, [...] Scheme relève un peu tout ça.[...]

c'est un peu plus complexe que ça. Dans le PLT-scheme, les variables définies au top-level sont à portée dynamique, car le pointeur d'environnement est remis sur le top-level et qu'un define est en fait un set!. Enfin, à moins que le R6RS est changé ça. Mais je ne crois pas.

[Garulfo]

Fonctions d'ordre supérieur : présent dans tous les langages fonctionnels

Tu pourrais même ajouter que sans ça, il est difficile de parler de langage fonctionnel.

Lazy evaluation : ce n'est par défaut dans aucun des 3 langages. OCaml possède des outils pour l'avoir de façon explicite (j'imagine que dans Scheme/Lisp on trouve la même chose).
Pattern matching : OCaml, oui. Lisp/Scheme, non, pas directement (des extensions comme Qi peuvent l'ajouter).

Je confirme pour l'évaluation paresseuse (couple delay/force) et je précise qu'il y a du pattern matching sans utiliser Qi dans Scheme. Il suffit de savoir où le trouver.

http://docs.plt-scheme.org/reference/match.html

[Garulfo]

mais j'ai trouvé cette notion dans lisp, puisque j'ai fait une étude sur les 3 langages

Et d'ailleurs on voit bien qu'on t'aide pour ton travail. Ton étude semble relativement superficiel pour ne pas avoir de réponse aux questions que tu nous poses. Tu aurais pu aussi annoncer que c'est un travail quand même C'est plus honnête.

[gasche]

il y a du pattern matching sans utiliser Qi dans Scheme. Il suffit de savoir où le trouver.
http://docs.plt-scheme.org/reference/match.html

Je connaissais la possibilité de faire du pattern-matching (ainsi que tout le reste) avec les capacités de metaprog, et j'ai déjà vu des gens coder leur propre extension maison pour ça pour s'amuser, mais je dois dire que je suis assez impressionné. C'est un matching puissant, qui a l'air bien intégré au langage (ils ont pensé au match-lambda et match-let qui sont d'un intérêt pratique non négligeable) qui couvre un bon nombre de choses (plus que les matching natifs ML/Haskell) et qui est extensible.

Ceci dit, on ne peut pas tout avoir, il faut s'attendre à ce que dans le cas courant (à savoir du pattern-matching sur l'équivalent de types algébriques) ce soit sensiblement plus lent qu'un matching "hardcodé" dans un langage typé, qui n'utilise pas de généricité, et utilise les informations de typage ainsi que de bonnes techniques de compilation pour offrir de très bonnes performances. Une partie de cela peut être retrouvée par un très bon compilateur pour les patterns, mais il faut quand même s'attendre à ce que ce soit plutôt difficile (par exemple j'ai des doutes sur la présence de tests d'exhaustivité). C'est, comme toujours, la question du compromis entre puissance, simplicité et efficacité; je suis surpris par la bonne intégration des patterns dans PLTscheme, mais pour du code symbolique avec des besoins en perfs j'utiliserais encore un langage typé.

[LLB]

je précise qu'il y a du pattern matching sans utiliser Qi dans Scheme. Il suffit de savoir où le trouver.

Je ne connaissais pas, merci beaucoup !

[avavrin]

je précise qu'il y a du pattern matching sans utiliser Qi dans Scheme. Il suffit de savoir où le trouver.

http://docs.plt-scheme.org/reference/match.html

Mais ça match pas sur le type comme en Caml ?

[Garulfo]

Mais ça match pas sur le type comme en Caml ?

Ça n'aurait pas de sens puisqu'il n'y a pas de type en Scheme -_-
Cependant je te ferais remarquer que tu ne fais pas de matching sur le type non plus en ocaml. En fait, tu utilises les constructeurs. Dans ce sens, ça existe aussi dans Scheme, si tu en utilises.