Bonjour,

2013/12/21 Gautier DI FOLCO <gautier.difolco@gmail.com>

Une sorte de fonction curryfiée à laquelle il manquerait un paramètre ?

C'est exactement ça, simplement ça se passe au niveau des types oui. Le dernier paramètre n'est pas "donné" au type, on laisse ça en suspens en quelque sorte.

instance Applicative (Foo Int String) where -- ça nécessite {-# LANGUAGE FlexibleInstances #-}, je peux t'expliquer pourquoi si ça t'intéresse.
...

Je veux bien.

Alors, si on essaie d'écrire cette instance sans activer cette extension, normalement on se choppe quelque chose du genre dans la tête:

Illegal instance declaration for `Applicative

(Blah Int String Char)'

(All instance types must be of the form (T a1 ... an)

where a1 ... an are *distinct type variables*,

and each type variable appears at most once in the instance head.

Use -XFlexibleInstances if you want to disable this.)

Ca veut dire que par défaut, quand tu définis une instance t'es pas vraiment libre, ça doit être de la forme qu'ils donnent: "T a1 ... an", i.e:

> instance MaTypeClass (T a1 ... an) where

où T est le nom d'un type ("type constructor"), et les "ai" sont des type variables. Ca veut dire que tu n'as pas vraiment le droit de fixer *un* des types (encore moins plusieurs). Tu as le même genre de restrictions sur le contexte (dans "instance (Blah a, Foo b) => MaClasse (Either a b) where", le contexte ce sont les deux contraintes à gauche de "=>"), qui ont donné lieu à l'extension "FlexibleContexts".

Voilà pour la petite disgression.

Je vois mieux, mais du coup, quel est l'avantage par rapport à un Either ?

Bah Errors là, c'est équivalent à Either a (Constant e) :

> type Errors e a = Pure a | Other (Constant e)

> type Either a b = Left a | Right b

donc on voit que ça marche si on prend 'b = Constant e'. Donc Errors est un cas particulier de Either en fait tout simplement. Il n'y a pas énormément d'avantages à utiliser Errors là plutot que Either, ErrorT & compagnie, parce qu'il y a pleins de fonctions utilitaires pour les autres, et puis de toute façon y'a 150 façons de gérer les erreurs en haskell et chacun à la sienne ou suit celle d'un gourou qu'il aime bien.

En fait mon soucis c'est de trouver comment l'appliquer au-delà des structures "triviale" (IO, Maybe, List, etc.)

Essaye de googler "applicative parsers" ça peut être intéressant. 'aeson', 'attoparsec', 'parsec' etc illustrent tous cela il me semble. Mais sinon te focalise pas trop dessus, avance, écris du code, continue à apprendre des choses, ça fera vraiment "clic" le moment venu ne t'inquiètes pas. Il y a encore quelques trucs que après 5 ans de Haskell j'ai encore du mal à comprendre, c'est un peu ce qui fait son charme d'ailleurs mais bon.

Lequel de ses livres ?

"Types and Programming Languages" je suppose (affectueusement appelé 'TAPL").

Quand je tombe sur quelque chose comme :

> instance Applicative (Lift f) where

Cela signifie-t-il "pour tout type Lift encapsulant un type quelconque 'f', je définis les fonction de son typeclass Applicative" ?

Applicative représente la possibilité de pouvoir effectuer certaines opérations, un peu comme tu pourrais avoir une "Interface" (au sens OO) en Java. Une instance se lit souvent comme "voilà comment on définit ces opérations pour mon type". En l'occurence, dans ton exemple, on définit une infinité d'instances, en qq sorte, puisqu'on laisse varier 'f'.

Du coup le Alternative sont un sorte de Monoïde pour les Applicative ?
Il faut qu'il y en ai un de bon sur un couple ou un ensemble, c'est ça ?

Ça sert à définir une valeur par défaut, si je comprends.

Alternative fournit d'une part une "valeur par défaut" en effet ('empty'), et une façon d'exprimer une sorte de "combinaison", l'opérateur <|>, qui souvent agit comme une sorte de "ou". Par exemple, l'exemple des Alternatives pour les parsers: si tu as un code du genre :

> parseA <|> parseB

typiquement il essayera de parser un "A" et si ça échoue, ça essayera de parser un "B".

--
Alp Mestanogullari