Coder-Studio - Forums

Hello,

Calvin1602 a écrit:

Ce message est, vous le comprendrez bien vite, destiné prioritairement à Alp, mais pourquoi ne pas vous en faire profiter ?

T'as bien eu raison. Comme ça si d'autres se mettent à Haskell...

Calvin1602 a écrit:

Je suis tombé sur Real World Haskell à la bibliothèque l'autre jour, et vu la pub qu'on a dessus sur le blog, je l'ai pris afin de ne pas mourir idiot. Et aussi parce que je me disais que, connaissant un peu l'OCaml, ça devrait pas être trop dur.

'tention, y'a pas un gouffre entre les deux, mais bon

Calvin1602 a écrit:

Je comprends à peu près tout ce que le bouquin dit, j'arrive à faire des trucs simples, les mêmes que je sais faire en Caml. Genre, parcourir une liste ou ce genre de connerie.

Maintenant, j'ai voulu faire le même "hello world" que j'avais posté il y a longtemps pour Lua/LuaBind : une classe Player avec quelques champs et un PlayerManager qui les gère.

Ok. Mais avant qu'on cause du code, je t'arrête.
En Haskell, tu bannis le terme "classe" Enfin, dans ce contexte-là. En Haskell, t'as les "type classes" et c'est tout ce à quoi on peut référer en disant "class", même si on utilise en général carrément "typeclass" plutôt que "class".

En Haskell, t'as 3 types de données, en gros.
- type algébrique, du genre : data direction = Up | Down | Left | Right ou encore data Maybe a = Nothing | Just a
- type 'record' : data Personne = Personne { age :: Integer, prenom :: String, nom :: String }
- type tuple : data Point3D = Point3D Double Double Double

A côté de ça, t'as 3 façons de déclarer des types : data, type et newtype, chacune avec leur utilisation.
Cf http://www.haskell.org/haskellwiki/Type

Calvin1602 a écrit:

Bon. Maintenant, je veux une fonction play qui m'enlève une cartouche. Ah. Problème.
- les données sont "immutables" en Haskell. Donc je suis obligé de reconstuire un Player identique, mais avec une munition en moins. Je n'ai pas (encore) trouvé le moyen de faire ça proprement.
- Je n'ai pas trouvé comment ajouter des fonctions membres. Ni dans la CHeatSheet, ni dans le bouquin. Ce qui me porte à penser que mon approche est mauvaise de A à Z.

Etant donné que ce ne sont pas des classes, tu n'as pas de fonctions membres. Ton type de données va encapsuler des données, et tu vas ensuite définir des fonctions qui constitueront ce que l'on appellerait son "interface" en OO, qui permettront de le manipuler. (et le fait de mettre un "attribut" dans ton type qui soit une fonction n'en fait pas une fonction membre, c'est vraiment un attribut quoi).

Calvin1602 a écrit:

Code:

play p@(Player {munitions = m, nom = n}) =
    if m>0
    then Player (m-1) n
    else p

C'est ignoblissime. Là je n'ai que deux membres donc ça va, mais si j'en avais 100, je serais obligé de déconstruire les 100 membres avec le @, et de les reconstuire après. Là encore, soit ya plus simple, soit j'applique au Haskell des idiomes de C++ et c'est mal, soit Haskell c'est tout pourri.

En fait, quand tu définis un type avec le style 'record', donc genre ton Player, tu as quelque chose qui se fait automatiquement... Pour chacun des champs, tu as une fonction 'Player -> TypeDuChamps' qui est automatiquement crée, et qui porte le même nom que le champs.
Donc là genre tu peux faire, si p est de type Player :

munitions p

et ça te renvoie le nombre de munitions de ton Player.
Du coup, ta fonction play devient :

play p = let m = munitions p in 
                     if m > 0 then Player (m-1)  (nom p)
                     else p

Mais il y a une façon de ne modifier qu'un nombre fini de champs d'un record, c'est en faisant :

monInstance { attr1 = foo1, attr2 = foo2 }

ça va retourner monInstance, mais en ayant mis la valeur de attr1 à foo1 et la valeur de attr2 à foo2. Attention, ça ne modifie pas monInstance, ç'en retourne une nouvelle avec les updates demandés.
Du coup, ta fonction play peut aussi s'écrire :

play p = let m = munitions p in 
                     if m > 0 then p { munitions = m-1 } -- tout peut même être résumé à p { munitions = if m > 0 then m-1 else m } je pense
                     else p

Calvin1602 a écrit:

Maintenant, j'aimerais faire une fonction playall qui fasse un forall sur la liste de TPlayer de PlayerManager. Ce que j'ai naturellement écrit comme ça :

Code:

playall pm = map play pm

mais là :     Couldn't match expected type `[TPlayer]'
           against inferred type `TPlayerManager'

voilà ...

Le fait est que tu as utilisé data pour définir TPlayerManager. Et même s'il n'y a qu'un type sous-jacent, un TPlayerManager n'est pas pareil que [Player].
Je te conseille de re-regarder la page sur les types en haskell dont j'ai donné le lien plus haut.
En particulier, si tu veux vraiment faire un bête synonyme de [Player], il faut utiliser 'type'. Newtype permet juste de vraiment faire un nouveau type, pas un bête synonyme, sans introduire d'overhead au runtime comme le fait data. En gros c'est vraiment un nouveau type pour le système de type mais tu dis au compilo 'mon gars, te prends pas la tête, en fait ça encapsule juste <le type sous-jacent>'.
Bref, si tu changes ta déclaration de TPlayerManager en :

type TPlayerManager = [Player]

ça marchera.
Sinon t'es obligé de faire une fonction qui récupère la liste sous jacente depuis un TPlayerManager, genre

getPlayerList (PlayerManager playerList) = playerList

Mais de toute manière la page wiki que je t'ai donnée devrait vraiment t'éclairer sur tout ça.

Calvin1602 a écrit:

Aide, remarques et commentaires débiles bienvenus

J'ai surement mis un peu de tout

Je pense avoir répondu à toutes tes questions mais si j'ai oublié quelque chose ou si d'autres te viennent n'hésite pas. Et si je mets trop de temps, ping moi par mail

Non ce n'est psa une fonction en argument.
Quand tu as qqch comme PlayerManager là, tu as donc ton constructeur de valeur ("PlayerManager") qui te permet d'obtenir une valeur de type TPlayerManager. Hé bien, tout ce qu'on va faire, c'est définir la fonction getPlayerList avec tu pattern matching !
On va matcher un objet de type TPlayerManager sur (PlayerManager playerList) où justmement playerList est le nom qu'on donne à la liste, juste la liste de Player, la [Player] quoi, sans le "PlayerManager" devant.

C'est comme quand on définie une fonction comme ça :

f [] = 0
f (x:xs) = 1 + f xs

sauf que dans le cas de la liste on a 2 alternatives possibles, tandis que dans le cas du player manager on n'en a qu'une, car c'est forcément de la forme "PlayerManager uneListe".

Donc quelque part, c'est un peu la même idée qu'avec le @, mais pas tant que ça. Dans ton cas on donne juste un alias. Ici, on fait du pattern matching. C'est à dire qu'on "déconstruit" le TPlayerManager pour avoir d'une part "PlayerManager" et d'autre part la liste de Player.

Rho la mauvaise langue ! Et puis laisse le, tu vois pas qu'il est à fond dedans là ? C'est bien ! Ca apporte un recul considérable sur la programmation !

Dernière modification par Alp (17-11-2009 19:43:23)

En Haskell t'as les monades. En particulier, toutes les entrées/sorties t'obligent à passer par IO. C'est super contraignant au début, mais très pratique par la suite. Ca sépare vraiment le code métier de tout ce qui est IO.

Si tu veux afficher les player, tu peux le faire par exemple dans main car elle retourne IO.

Mais de toute manière, je te conseille de (re)lire le chapitre sur les monades de RWH pour bien piger tout ça, et je crois même qu'il y a aussi tout un passage sur l'IO.

Après si t'as plus envie tant pis

Hors-sujet:

Je plussoie le Wett ! Le Haskell a l'air d'être pire que le VB (troll inside). Je suis très bien avec mon C :-)

Hors-sujet:

Pire que le VB ? Faut pas abuser non plus

Hors-sujet:

Waou 2 jours là-dessus ? Qui dit mieux ?