Conférence lundi 14 sur le langage Haskell

Haskell est un langage de programmation... vraiment très particulier, qui a choisi de s'appuyer de façon quasi-intégriste sur des fondements mathématiques (en particulier le lambda-calcul) incontestablement démontrables, mais élaborés par de brillants théoriciens (comme Alonzo Church) avant même les ordinateurs les plus rudimentaires. Haskell s'interdit de façon presque psycho-rigide les solutions empiriques héritées des premiers temps de l'informatique (qui, pour lui, relèvent du bricolage), pourtant employées de façon systématique dans la quasi-totalité des langages d'emploi courant (de Cobol à Scala en passant par C, C++, Java, Perl, Python, etc.): un programme Haskell est construit presque exclusivement sur la notion d'égalité au sens mathématique du terme, et a une sainte horreur du mélange de la logique et du chronologique; il n'emploie pas de variables temporaires, pas même de simples compteurs, ignore superbement les boucles for et while et leur substitue un usage systématique de la récursivité.

A la surprise générale, le résultat est que la quasi-totalité des informaticiens jugent le projet incompréhensible, voire délirant, et que Haskell n'a fait son (maigre) trou que grâce à l'engouement de rares matheux amoureux d'une certaine forme d'élégance et de dépouillement logique, avec un immense dédain pour la cuisine informatique.

Pourtant, Haskell n'est vraiment pas particulièrement compliqué. Sa logique dépouillée est même par bien des côtés d'une admirable simplicité, mais elle force la plupart des informaticiens à se défaire d'habitudes de pensée qui sont devenues totalement réflexes pour eux. C'est pour cela que des zèbres peuvent s'y intéresser avec délectation, car ça force à utiliser des démarches intellectuelles que l'on n'emploie presque jamais et, comme dit un des gourous du langage, "it twists your mind in a delightful way".

J'essaierai d'expliquer tout ça dans une petite conférence que je donnerai entre 18:45 et 21:00 à l'Espace public numérique du 7e arrondissement, 105 avenue de La Bourdonnais, Paris VIIe (métro Ecole militaire). Le cycle de conférences est organisé par l'association parisienne de partisans du logiciel libre Parinux.

Je viendrais, ça a l'air passionant.
Des processeurs parlent-ils ce langage, ou est-il interprété ou compilé ?

Il est interprété ou compilé, au choix.
Et si tu connais, ça ressemble à Erlang.

J'ai joué un peu avec des langages fonctionnels. Étant habitué à raisonner avec des langages "normaux", j'ai tendance à bloquer pour faire des tâches simples. Je crois que c'est une question d'entraînement, mais encore faut-il passer le mur du "j'y arrive pas donc c'est de la merde" contre lequel je me suis écrasé.

À vrai dire, si je vois l'intérêt du fonctionnel, j'ai du mal à voir pourquoi un langage voudrait s'y limiter (faire des preuves d'algorithmes ?). OCaml ou Python permettent plus ou moins la même chose tout en acceptant la programmation impérative.

Bonne conf à tous les Parisiens chanceux qui peuvent y aller!

korppi a écrit:J'ai joué un peu avec des langages fonctionnels. Étant habitué à raisonner avec des langages "normaux", j'ai tendance à bloquer pour faire des tâches simples. Je crois que c'est une question d'entraînement, mais encore faut-il passer le mur du "j'y arrive pas donc c'est de la merde" contre lequel je me suis écrasé.

Oui, c'est ça le challenge... En fait, c'est surtout pour expliquer comment on passe le mur que j'espère que ma conférence peut servir à quelque chose.

À vrai dire, si je vois l'intérêt du fonctionnel, j'ai du mal à voir pourquoi un langage voudrait s'y limiter (faire des preuves d'algorithmes ?).

Tout à fait bien vu! (tu serais pas un peu zèbre?) Oui, c'est en effet pour cette raison que beaucoup de matheux s'intéressent à Haskell. Ce n'est pas la seule raison d'y mettre son nez, mais c'est la motivation de la plupart des matheux.

OCaml ou Python permettent plus ou moins la même chose tout en acceptant la programmation impérative.

Absolument exact. A vrai dire, Haskell aussi permet la programmation impérative, sauf qu'il oblige à la confiner dans des routines spécifiques. Pour moi, c'est là l'intérêt du langage: il force à se demander "comment faire ça en fonctionnel?", alors que tout programmeur dont l'esprit a été formé par la programmation impérative ne peut jamais s'empêcher de se poser la question "mais pourquoi diable le ferais-je en fonctionnel alors que j'y arrive en impératif?" -- et du coup, on n'entre pas vraiment dans la logique fonctionnelle. J'ai moi-même fait du Python pendant des années sans jamais trouver le moindre intérêt au lambda-calcul qu'on peut pourtant y pratiquer; c'est Haskell qui m'a obligé à comprendre, et je n'y serais jamais parvenu sans y être obligé... Alors que justement, quand on a compris, on s'aperçoit que non seulement c'est possible, mais que dans pas mal de cas c'est préférable.

Bonne conf à tous les Parisiens chanceux qui peuvent y aller!

Merci.

Lundi 14 c'est jour du Haskell

Je serai à un meetup organisé le même jour par Haskell-Paris à Af83 (2e).

http://meetup.haskell-paris.fr/events/98528482/

Mimic Cordylus a écrit:Je serai à un meetup organisé le même jour par Haskell-Paris à Af83 (2e).

Oui, c'est un hasard étonnant (et un peu dommage, évidemment)... J'ai appris votre existence en préparant la conférence (malheureusement, la date était déjà arrêtée), et j'ai eu quelques échanges de mails avec Lucas Di Cioccio. La prochaine, fois, nous tâcherons de coordonner nos efforts!

Ca tombe bien, cela fait un petit moment que j'avais envie de réveiller un peu mes (maigres) souvenirs d'Haskell... Je serais là avec plaisir (si j'arrive à me libérer) !

.... Je viens de lire un peu de documentation, qu'est-ce que ça apporte vraiment ce langage
(à part permettre d'avoir des programmes qui tournent correctement tout en ayant des sous-doués mal payés pour programmer) ?
Les exemples que j'ai trouvé sont du niveau "hello, world".

Alors, pour moi... (note: désolé si j'enfonce des portes ouvertes, je vais essayer de rester clair pour quiconque lit...)

L'intérêt d'Haskell en tant que langage, c'est d'être la lingua franca de la programmation fonctionnelle.

Ensuite, son intérêt provient plus du type de programmation (fonctionnelle) que du langage à proprement parler, pour faire bref:
- Il permet de faire grandir le logiciel par composition fonctionnelle (vs organique), ce qui permet de contenir le degrés de complexité requis pour le faire évoluer.
- En augmentant la granularité de l'expression, il permet aux programmeurs de déléguer aux outils (compilo, etc) davantage de tâches.

Ce dernier point ne doit pas être pris à la légère, il a potentiellement un impact sociétal: dans une ère ou tant de choses sont optimisées par des logiciels, la puissance de calcul disponible à un impact sur la société (ex: puissance dispo pour la finesse d'analyse des images IRM), or on ne tire plus parti de la loi de More en augmentant la puissance d'un fil de calcul mais quasi uniquement en diminuant la taille et la consommation des processeurs - ils ne vont pas plus vite mais sont plus petits et consomment moins (d'où smartphones et tablettes). Pour continuer à exploiter la loi de More en vue d'un accroissement de puissance de calcul dispo, il faut tirer parti non pas d'un seul processeur, mais d'une ribambelle (vive le parallélisme!).

Une piste pour cela est de déléguer la parallélisation automatique du code à nos outils (compilo), un peu à la manière dont fonctionnent les requêtes de bases de données: si on ouvre cette voie au programmeur lambda, on rouvre par là même l'augmentation de la puissance de calcul grâce à la loi de More... Et pour cela, il faut une granularité d'expression élevée, comme en (bon) SQL et comme en (bonne) programmation fonctionnelle...

Just my 2 cents...

p'tet que ce sera plus clair après la conf ...

Est-ce qu'SQL est un de ces langages fonctionnels ?

Bingo ! En fait, c'est un peu ça le rêve de la prog. fonc. : programmer tout aussi facilement qu'en SQL; en décrivant plus le résultat recherché plus que les détails de la procédure à appliquer pour y parvenir...

N'exagérons pas, Haskell n'est pas la Lingua Franca des langages fonctionnels.

C'est un langage fonctionnel à la mode dans le milieu académique, parce que soutenu par les anglo-saxons, qui sont beaucoup plus forts que les français pour le marketing. Un exemple: la communauté Haskell met en avant la gestion du multicoeur, mais au final, un programme Haskell parallèlisé tourne moins vite sur un quadcore qu'un programme en OCaml, qui ne gère pas encore le multicoeur (ce qui devrait être règlé dans l'année 2013).

Je conseillerais sans réserve d'apprendre OCaml plutôt qu'Haskell. OCaml est développé à l'INRIA (à Versailles et Saclay), et utilisé dans le monde industriel, bien plus qu'Haskell : Jane Street trade 10 milliards de $ par jour automatiquement en OCaml, Citrix gère ses serveurs Xen avec OCaml (15% du Cloud, Amazon EC2 par exemple), Airbus vérifie une partie de son soft embarqué avec OCaml (Astrée développé à l'ENS ou Frame-C au CEA), etc.

OCaml est un langage multiparadigme, i.e. fonctionnel, mais aussi impératif et objet, le tout typé complètement statiquement. Contrairement à Haskell, il permet de faire du paresseux, mais ne l'est pas par défaut. Ça permet aux débutants de comprendre comment un programme s'exécute, tout en ayant la puissance d'un langage fonctionnel sous le capot quand ça devient utile... et la performance d'un moteur de course (compilateur optimisant, runtime hyper-optimisé). Une autre différence importante, c'est que Haskell est au final asses peu lisible, seul le programmeur comprend son programme, alors qu'OCaml met l'accent sur la lisibilité, ce qui peut rendre les programmes un peu plus verbeux, mais beaucoup plus faciles à maintenir sur le long terme ou en équipe.

Et puis, OCaml se compile en Javascript (js_of_ocaml), ce qui permet de faire du WEB complètement typé, et de faire tourner ses algos en ligne aussi bien que dans un terminal. On peut même faire ses premiers pas en ligne, sans l'installer (tapez "try ocaml" sur Google).

Bref, allez voir cette conférence, pour voir l'élégance d'Haskell, mais dans la pratique, utilisez plutôt OCaml, qui marie élégance et performance !

Fabrice Le Fessant a écrit:N'exagérons pas, Haskell n'est pas la Lingua Franca des langages fonctionnels.

C'est un langage fonctionnel à la mode dans le milieu académique, parce que soutenu par les anglo-saxons, qui sont beaucoup plus forts que les français pour le marketing. (...)

Bref, allez voir cette conférence, pour voir l'élégance d'Haskell, mais dans la pratique, utilisez plutôt OCaml, qui marie élégance et performance !

Merci de cet avis solidement argumenté. Je ne suis pas en mesure de confirmer tes propos, faute d'avoir tâté d'OCaml, mais ce que tu dis me paraît très convaincant -- et d'autant plus que l'un des gourous de Haskell, Simon Peyton-Jones, n'est pas seulement un délicieux Britannique qui fait penser à John Cleese, mais aussi un employé de... Microsoft, mais oui (ce qui, normalement, aurait dû déclencher chez moi une éruption de boutons... mais ça n'a pas été le cas car le type est délicieux comme le sont les Britiches quand ils ont décidé de l'être).

Je crois quand même pouvoir maintenir que, pour quelqu'un qui vient de la programmation impérative, l'obligation de rentrer dans la logique fonctionnelle est indispensable pour s'y mettre vraiment. Donc, si tu me dis qu'en OCaml on n'est pas absolument obligé, ça peut être tenu comme une faiblesse sur le plan pédagogique (en revanche, pour ce qui est de l'efficacité, tes arguments me paraissent pleinement valides). Or, c'est bien pour ses vertus pédagogiques que je me suis frotté à Haskell, et c'est pour chanter les louanges d'Haskell de ce seul point de vue-là que j'ouvrirai le bec à la conférence.

En tout cas, je suis agréablement surpris de la qualité que peut atteindre une discussion techniquement pointue sur ZC, et même dans la seule section "Ile-de-France". Je vais finir par croire que c'est vraiment rempli de surdoués par ici.

Petitagore a écrit:
[...] et d'autant plus que l'un des gourous de Haskell, Simon Peyton-Jones, n'est pas seulement un délicieux Britannique qui fait penser à John Cleese, mais aussi un employé de... Microsoft [...]

Oui, Simon est un personnage charismatique, auquel Haskell doit bien plus que son code. C'en est d'autant plus surprenant que Microsoft ait choisi de se baser sur le noyau d'OCaml pour concevoir le seul langage fonctionnel disponible dans son Visual Studio, à savoir F#.

J'ai souvent vu des programmes se planter ou au moins avoir des performances inacceptables car les volumes à traiter étaient peu spécifiés et le programmeur n'en avait cure. Donc le truc tourne bien ave quelques données de test mais dans la réalité c'est inutilisable tel quel.
A mon avis aucun langage ne permettra jamais d'éviter cela.
Je vais jeter un oeil sur Ocaml. Allusion au caméléon ce nom ? Au chameau ??

Si la programmation fonctionnelle doit se démocratiser, je m'attends plus à ce que ça passe par l'ajout du paradigme fonctionnel dans la norme de langages impératifs/objet déjà très répandus, que par l'adoption d'un nouveau langage, quitte à utiliser un langage purement fonctionnel pour l'apprentissage. Même si ce nouveau concurrent permet aussi la poo (comme OCaml, qui est, je suis d'accord, une synthèse de plein de bons aspects), il aura du mal à lutter face aux "anciens", bien incrustés à leur place, et qui bénéficient de tonnes de librairies et de frameworks. C'est le poids l'existant.

Fabrice Le Fessant a écrit:Et puis, OCaml se compile en Javascript (js_of_ocaml), ce qui permet de faire du WEB complètement typé, et de faire tourner ses algos en ligne aussi bien que dans un terminal. On peut même faire ses premiers pas en ligne, sans l'installer (tapez "try ocaml" sur Google).

Plutôt de la traduction que de la compilation du coup, non? Ce serait plus efficace d'avoir un javascript plus complet, ou alors un meilleur langage client standard pour le web, que de devoir passer par des langages intermédiaires pour pouvoir coder proprement... (il faut que je regarde ou en est dart)

Je changerais peut-être d'avis avec l'expérience, mais pour l'instant, j'ai un mauvais à priori sur cette tendance qui consiste à empiler les langages/interpréteurs/VMs. Enfin, ici, c'est du web, il faut un standard, ça bouge doucement, c'est une autre histoire, je comprends. La seule solution c'est bien de traduire. Et encore une fois, le poids de l'existant est là...

Je ne pourrai sans doute pas être présent, mais, si tu pouvais rendre accessible le texte de ton exposé, cela m'intéressait.

J'ai préparé autrefois une thèse sur le lambda-calcul typé, mais sans donner suite. Dans le séminaire de l'équipe de logique de Paris VII, j'ai eu l'occasion d'entendre des exposés sur les ancêtres du langage OCaml, ML et Caml, de la part notamment d'un thésard de l'INRIA.
J'avais trouvé la forme des exemples de code informatique particulièrement élégante du point de vue de la clarté et de l'expressivité, en totale opposition avec ce qui a dominé depuis (l'ignoble C et ses dérivés).

Si j'avais été persévérant, je me serais orienté vers des recherches en linguistique appliquée aux langages de programmation. Dans le principe, je serais assez radical, peut-être dans la voie du langage Haskell, pour tout ce qui est proprement fonctionnel. Mais pourtant je suis convaincu, d'un point de vue philosophique, que tout ce qui est réel n'est pas rationnalisable dans un langage qui fait abstraction du temps.

C'est beau le C .
Pourquoi ce qualificatif d'ignoble, Pieyre ? Parce que tu ne comprends pas ? Parce qu'il y a "trop" de liberté à ton goût ?

Si on veut, comme la langue anglaise : tout à l'envers de tout et réciproquement.
La liberté dans les expressions à effets de bord, c'est amusant. Mais ce n'est pas ça. Le problème, c'est le typage et le minimalisme inutile.
Pourquoi ne pas laisser l'optimisation syntaxique au compilateur et écrire de façon la plus naturelle possible ?
J'ai l'impression que le langage informatique souffre d'un complexe d'infériorité par rapport au langage mathématique. Mais, dans ce dernier, seul le calcul est formalisé. Les définitions et les propositions sont écrites en langage naturel.

Il me semble justement qu'en mathématiques le langage est avant tout le langage humain, français, anglais ou autre. Et les symboles ne sont là que pour raccourcir le texte, ou pour faciliter l'expression, mais jamais pour la contraindre. C'est juste plus commode d'écrire = plutôt que tout ce qu'implique une égalité.
Il me semble qu'en informatique un élément important est "qui va lire ce programme que j'écris". Si c'est seulement moi ou si il y a plusieurs personnes qui doivent intervenir, les libertés ne sont plus les mêmes, et les besoins non plus. Le besoin de clarté est là, dans la nécessité qu'un programme soit lu par d'autres.
Certains langages imposent de mettre une majuscule au début des noms des fonctions, je trouve ça inélégant, et ça ne correspond pas à ma logique de programmation. Je mettrais plutôt les variables en majuscules. Ma logique c'est d'abord de m'occuper des données. Un programme ça sert à manipuler des données, pas juste à aligner du code qui fasse "joli".
J'aime bien la notion de dictionnaire. Mais nos éditeurs ne gèrent pas vraiment ça. On gère des kilomètres de source et on s'y perd un peu, voilà tout.
Est-ce qu'il y a une longueur maximum d'un programme en Haskell, OCaml ou autres ?

Le langage mathématique consiste en une exposition de formules, selon des sous-parties de définition ou de démonstration, – je veux dire que tout cela peut être imbriqué indéfiniment.
À chaque niveau, il y a donc un langage englobant, celui du discours, et un langage de contenu formel, qui est fonctionnel.
Sans doute pourrait-on établir un langage formel concernant l'exposition elle-même, mais on n'y gagnerait pas tellement je pense à moins d'avoir à effectuer un traitement automatique applicable à l'ensemble des expositions de théories.

Le symbole = correspond à une relation d'arité 2 sur tous les ensembles d'expressions de même nature. Mais le mot soit qui débute une définition n'est pas fonctionnel. Il fait partie d'un discours d'exposition de ce que l'on compte faire avec les formules.

Le problème en informatique, c'est qu'on ne distingue pas autant. C'est justifié dans la mesure où les mots, de même que les symboles, sont réduits à des constructions élémentaires. D'ailleurs un programme est censé être équivalent à une démonstration. Sauf que ce qui est strictement impératif ne correspond pas à la même logique que ce qui est fonctionnel (de la même façon que le libre arbitre déborde le cadre du déterminisme de la physique).

Alors, la lisibilité, c'est bien un enjeu important pour moi.

Prends un truc comme :

int t[10][4];
int (*p)[4] = t;

Je le recopie à partir d'un site, sinon je risquerais de me tromper. Et encore, il y a beaucoup plus tordu. Tu connais sans sans doute le concours du programme C le plus dense et le plus incompréhensible... ou quelque chose comme ça.
Là, au bout d'un certain temps, je parviens à comprendre de quoi il s'agit. Il y a une logique particulière, comme dans les casse-têtes logiques. On est content de maîtriser mais, quand on ne fait pas ça tout le temps, comme c'est mon cas, au bout de cinq minutes on a oublié de quoi il s'agissait et il faut se farcir à nouveau le décorticage.

Non, mais franchement, pourquoi ne pas écrire quelque chose comme :

soit t : tab (10, 4) de ent
soit p : pt sur tab de tab (4) de ent
p := adr (t)

Ça pose vraiment un problème qu'il y ait quelques caractères de plus ?

Par ailleurs, pour moi la composition des lettres des identifiants doit être libre, que ce soit pour les constantes, les variables, les données, les termes structurels, les types ou ce qu'on appelle les mots réservés, cela dans le respect de la langue naturelle de référence.

La verbosité devient très chiante (c'est mon meilleurs mot :p) pour qui code toute la journée. La langue naturelle n'est verbeuse que parce qu'elle est parlée.

J'aime bien la conversion ocalm vers javascript !

Sexy ruby is beautiful::

Pour les "matheux" qui veulent vraiment programmer comme on fait une preuve mathématique, il existe une autre solution... c'est d'utiliser Coq, l'assistant de preuve développé par l'INRIA, qui permet de générer du code OCaml exécutable à partir d'une preuve mathématique de l'algorithme.

Ça peut sembler tiré par les cheveux, mais c'est vraiment utilisé en pratique dans l'industrie : Xavier Leroy, l'un des auteurs d'OCaml, a développé un compilateur C vers assembleur comme ça. Quel intérêt ? Ce compilateur est utilisé par Airbus pour compiler leurs codes sources, avec la garantie mathématique que la compilation ne va pas introduire de bug dans le code...

Y a le prolog aussi avec le prédicat du premier ordre qui permet pas mal de travailler avec la logique mathématique...

Cette petite conf a donc eu lieu (avec dans l'assistance certaines personnes déjà rencontrées sur ZC et à Mensa). Ça vaut ce que ça vaut, c'est-à-dire sensiblement le prix que vous aurez à payer pour vous les procurer, mais le diaporama et même l'enregistrement MP3 du commentaire ('tention, deux heures de son ça pèse 118 Mo) sont disponibles sur mon serveur perso.

L'un ne va guère sans l'autre... en revanche il est très facile de passer de l'un à l'autre, notamment pour trouver en quelques secondes l'emplacement exact des trois ou quatre minutes de son qui seules vous intéressent au milieu des deux heures d'enregistrement: l'en-tête de chaque écran du diaporama porte en effet un chronométrage précis, permettant de vous reporter à l'emplacement correspondant du fichier audio (on appelle ça un slidecast; slide show + podcast = slidecast).

Bonne lecture-écoute.  

Merci pour cette conférence sur Haskell.
(x:xs) n'est qu'une simple notation:
et  x et xs convient  tout autant que boule et bill ou dalai et lama...
Si on prend une liste disons [1,2,3,4], qui est sucre syntaxique de  1:2:3:4:[], ensuite on plie cette structure à gauche, ce qui revient à rajouter quelques parenthèses , on obtient ceci :
1:(2:(3:(4:[])))
x:xs

C'est exact. Cela dit, je ne suis pas très convaincu que ça paraisse plus simple une fois qu'on le sait.

Petitagore a écrit:C'est exact. Cela dit, je ne suis pas très convaincu que ça paraisse plus simple une fois qu'on le sait.

Si on implémentait un  type liste maison, cela donnerait un truc comme cela :

Code:

infixr 7 :-:
data Liste a = ListeVide|a :-: Liste a deriving Show

instance Functor Liste where
  fmap _ ListeVide = ListeVide
  fmap f (x :-: y) = f x :-: fmap f y

taille :: Liste a -> Int
taille ListeVide = 0
taille (_:-:xs) = 1 + taille xs
  
tete :: Liste a -> a
tete ListeVide = error "Liste vide!"
tete (head :-: _) = head

additionner1 :: Num a => Liste a -> Liste a
additionner1 = fmap (+1)

Prelude définit son type liste []
ainsi:

Code:


data [] a = [] | a : [a]


plutôt concis ...

Petitagore a écrit:Haskell est un langage de programmation... vraiment très particulier, qui a choisi de s'appuyer de façon quasi-intégriste sur des fondements mathématiques (en particulier le lambda-calcul) incontestablement démontrables, mais élaborés par de brillants théoriciens (comme Alonzo Church) avant même les ordinateurs les plus rudimentaires. Haskell s'interdit de façon presque psycho-rigide les solutions empiriques héritées des premiers temps de l'informatique (qui, pour lui, relèvent du bricolage), pourtant employées de façon systématique dans la quasi-totalité des langages d'emploi courant (de Cobol à Scala en passant par C, C++, Java, Perl, Python, etc.): un programme Haskell est construit presque exclusivement sur la notion d'égalité au sens mathématique du terme, et a une sainte horreur du mélange de la logique et du chronologique; il n'emploie pas de variables temporaires, pas même de simples compteurs, ignore superbement les boucles for et while et leur substitue un usage systématique de la récursivité.

A la surprise générale, le résultat est que la quasi-totalité des informaticiens jugent le projet incompréhensible, voire délirant, et que Haskell n'a fait son (maigre) trou que grâce à l'engouement de rares matheux amoureux d'une certaine forme d'élégance et de dépouillement logique, avec un immense dédain pour la cuisine informatique.

As-tu retouché à ce langage.
Pour moi je l'ai quelque peu délaissé mais je sentais que ce langage avait quelque chose de vraiment particulier, qui n'existe dans aucun autres langages, y compris les langages fonctionnelles, car ce n'est en fait qu'une caractéristique  parmi  plusieurs autres,

D'abord on a la gestion des types les plus avancées qui existe actuellement.
Le plus impressionnant est la possibilité de décrire des structures mathématiques

Ensuite l'évaluation paresseuse, qui permet de décrire informatiquement des objets infinis,
liste de tous les nombres premiers,etc ...
des exemples traînent sur internet montrant des exemples de résolveur du jeu countdown (chiffres et les lettres (sans les lettres)), on a un moment la liste de tous les opérations possibles ...


Dans ton descriptif, tu parles du lambda-calcul comme source moteur de ce langage, c'est le propre de tous les langages fonctionnelles et de quelques amélioration récentes de certains langage , javascrpt notamment.

Or il semble évident qu'Haskell s'appuie sur une théorie mathématique bien plus puissante, la théorie des catégories, ceci est ce qui rend son typage aussi performant, plus que des langages qui se base sur le lambda calcul ( ML Scheme, OCAML ..)


On peut faire de la programmation impérative, une monade IO est disponible pour faire cela.
On peut isoler ce qui peut avoir des effets de bord.



Un fait marquant:  
La plupart des langage considèrent les types  ainsi
entier, liste, chaines de caractères, caractères, double , etc ...
haskell fait une énorme distinction Int est de type * alors que les listes que l'on écrit [] est de type
* -> * , une liste est en fait un type de type.
Par contre une liste d'entier sera un type simple  *
ceci a l'air d'être rien du tout mais cela change tout.

Si l'on prend la fonction map , fonction qui existe dans beaucoup de langage.

Code:


map (f, [x1,x2,x3]) = [f(x1),f(x2),f(x3)]


cette fonction s'applique sur chaques éléments de la liste.


le type de map en haskell est

Code:

map:: ( a -> b ) -> [a] -> [b]

Haskell permet l'abstraction.
[] est de genre * -> *

L'idée est que l'on peut remplacer  le type [] par n'importe quel type de la forme * -> *
On généralise map en une fonction fmap

( a -> b ) -> f a -> f b

et on définit une classe (très different des classes dans les langages objets)

Code:


class Functor f where
  fmap :: ( a -> b ) -> f a -> f b


Si on définit par exemple un type  arbre binaire ,

disons défini ainsi:

Code:


data Tree a = Node a (Tree a) (Tree a) |  EmptyTree


on peut faire une opération similaire à map mais agissant maintenant sur une structure d'arbre.

Code:


instance Tree a where
 fmap _ EmptyTree = EmptyTree
 fmap f (Node x left right)  = Node (f x) (fmap f left)(fmap f right)