Reprise du message précédent :
Si tu veux jouer dans IO, il faut utiliser les liftM* (ou, ici, `ap` qui suffit largement, voir hoogle pour les signatures)

> let s = return (formatTime defaultTimeLocale "%D %T" ) `ap` getCurrentTime
> s
"03/31/08 13:21:18"

j'ai pas testé mon copier coller, mais dans mon code, c'était dans une monade a l'origine.
 

boom
 

boom.
 
j'ai l'impression que c'est le let qui me manquait, je l'ai pas encore vu celui la
 

Note finale, si tu veux commencer à jouer avec haskell, je ne peux que te conseiller d'aller dans #haskell@irc.freenode.net, les gens y sont très sympa

Ah non là tu fais plein de bêtises

"<-" c'est pour "unboxer", pour sortir un truc d'une monade (tout en restant dans un contexte monadique). Donc pour l'appel à getCurrentTime c'est nécessaire, histoire de sortir ton UTCTime de IO.

Donc t <- getCurrentTime est ok, et t va être de type UTCTime, pas IO UTCTime

Par contre formatTime defaultTimeLocale "%D %T" ne vit pas dans IO (voir son type: FormatTime -> String, un truc du style) donc tu peux pas utiliser <- avec, sauf à le lifter (avec liftM ou ap).

Dans ton 2e test, remplace simplement time <- formatTime defaultTimeLocale "%D %T" t par let time = formatTime defaultTimeLocale "%D %T" t et ça devrait rouler

j'ai pas irc au taff, et j'ai autre chose a faire a la maison  
 
faudrait que je lise plus de doc, mais comme j'avais un petit besoin immediat, je me suis dit que j'allais le faire avec haskell plutot qu'en shell, pour jouer

Bah installe un client, ça prend 2mn et franchement le channel #haskell est une ressource qui facilite grandement la découverte.

C'est ce que j'ai fini par faire. Ca marche tant que j'essaye pas de m'en servir plus tard.
 
la, time est de type IO(), alors que ca devrait être une chaine, et je vois pas comment passer de l'un a l'autre.
 
le but evidemment, c'est de faire cette bidouille :
 

ce que je voulais dire par la, c'est que le proxy n'autorise que le http, et qu'en plus les sites sont filtrés.

si y'a pas de réponse simple, laisse tomber, je continuerais ma lecture de la doc, ca devrait m'éclaircir.

Non, avec ce que je t'ai donné, time est de type String

Par contre, une fonction binde plus fortement qu'un opérateur, et putStrLn est une fonction, si ton erreur est un truc du style Couldn't match expected type `[a]' against inferred type `IO ()' le problème vient de là. Mets des parenthèses autour de ton "++" ou bien ajoutes un "$" après putStrLn

mais ouais, je suis trop con, je viens de le voir.
ca m'apprendra a mieux lire les messages d'erreur.

Bof

D'un autre côté les messages d'erreur de ghc sont pas nécessairement les plus clairs du monde non plus

En l'occurence, il l'était. La preuve, c'est que j'ai fini par trouver tout seul :

Oui mais je tentais de ménager ta sensibilité

l'ego, c'est pour les faibles

Ok, ben t'as loosé comme un gros moisi, faudrait que tu songes à retourner faire du PHP

je suis une brele en php, a part faire un include et 2/3 bricoles, je sais plus du tout comment ca marche.
 

bon, encore un truc pas clair dans ma tête.
 
Le contexte : un jeu de plateau, avec des unités, qui ont un etat (points de vie, point de deplacement, ...).
 
Est-ce que mes unités doivent être un type, et chaque fonction de modif d'état doit renvoyer un nouvelle unité, ou est-ce que je suis censé faire en sorte que mon unité soit une monade ?

1 je dirais, plus du conserves de pureté et plus c'est facile de raisonner. En bonus, ça facilite des trucs genre tests, et ça évite que tout ton code soit dans une monade.

Allez hop, up en moins d'une semaine. Inutile mais up quand même:
qtHaskell ==    
 
J'en suis qu'à porter les tutos de la doc, mais ça fleure bon d'avance...

http://www.mibbit.com/

proot

ca revient, mauvais bouton.

Bon, j'ai réussi a faire ce que je voulais, mais ca me semble super compliqué par rapport a ce que j'avais a l'origine en java. J'imagine qu'on peut faire mieux.

Donc j'ai une carte, qui ressemble à ca :

Mes chateaux sont représentés par des T. Je cherche a trouver toutes les cases qui font partie d'un chateau donné.

J'ai fait comme ca :

Mon main me calcule le chateau qui contient (0, 0) :
Castle {coords = [(2,1),(2,2),(1,3),(1,2),(0,2),(0,1),(0,0)]}

Ca marche bien, mais c'est bof.
Le point qui m'embete le plus, c'est que je me réappelle pour des coordonnées que j'ai déjà traité.

Des idées pour améliorer ca ?

Edit: erreur de copier/coller dans le code, ajout de gardes pour simplifier

lorill> la mémoïsation / programmation dynamique consiste à cacher les résultats pour que quand tu traites un truc déjà vu tu ne re-descende pas la branche.

Je vais peut-être dire une grosse bêtise, mais au moins je le saurais
 
Pourquoi ne pas passer par une fonction d'implémentation qui prend en paramètre un tableau des coordonnées déjà testées? Tu peux ajouter la non-appartenance de la coordonnée au dit tableau dans la garde de la génération du tableau pour éviter de repasser dessus?
 
Genre:

buildCastle :: Map -> Castle -> Coord -> Castle
buildCastle = buildCastle' []
              where buildCastle' :: [Coord] -> Map -> Castle -> Coord -> Castle
                    buildCastle' vc m c xy
                      | not (isCastle m xy) = c
                      | xy `elem` (coords c) = c
                      | otherwise = foldl (buildCastle' (xy:vc) m) c' (near xy)
                      where
                        c' = Castle (xy:(coords c))
                        variations x = [x-1, x, x+1]
                        near (x, y) = [(a, b) | a <- variations x, b <- variations y,
                                                (a, b) `isInMap` m && (a, b) /= (x, y) && not((a,b) `elem` vc)]

(disclaimer: non testé etc... )

ce n'est pas nécéssaire en fait, puisque ton vc, je le retrouve dans c.
 
par contre je peux effectivement rajouter un  

dans la construction de liste dans "near".

Ah ok, j'avais pas percuté... S'il y a autre chose je vois pas alors

bon ben je me suis bien amusé :
 

 
dommage que les paquets de Gtk2Hs soient foireux sous ubuntu...

bon, je vais être obliger de passer par des IORef pour gérer mes modifications d'état.
 
Il vaut mieux un seul IORef avec une grosse structure dedans, ou plein d'IORefs avec a chaque fois un élément plus simple ?

Le problème principal de plusieurs IORef, c'est la verbosité de la déclaration. A part ça, je préfère partir sur l'utilisation d'IORef sur des types de base pour l'instant.

Je préfére, par exemple:
xy <- readIORef $ coords castle
que
c <- readIORef castle
let xy = coords c

J'imagine aussi que tu gardes la possibilité de conserver un peu de pureté dans les fonctions s'appliquant à un type dont certains des attributs sont en IORef. Après s'ils le sont tous, je dirais que ça relève d'une préférence syntaxique.

je ne serais pas descendu jusqu'au type de base, en fait.
si j'ai ces types :
 

 
mes unités sont mutables (points de vie & deplacement, coordonnées)
mes armées sont mutables (unités recrutés, unités mortes)
 
je peux faire :
* un ioref par unité + un ioref par armée
* un ioref par armée
* un ioref unique pour toutes les armées
 
les autres types sont immutables.

Je dirais solution 1 (le max d'IORef). Mais tant que tu es dans le code du gameplay, tu peux pas te permettre de t'en passer?

je ne pense pas, parce que comme je fais du gtk, mes fonctions sont appelées par gtk directement, donc mes parametres sont fixes.
 
ou alors j'ai zappé un truc, ce qui est aussi fort possible.

Ah oui forcément. J'ai le même dilemne avec Qt... Et la meilleure chose que j'ai trouvée, c'est de trimballer un type normal embarqué dans un IORef, eg:

Mais ça revient à la première solution... Avoir un data type propre te permet tout de même de gérer les fonctions du gameplay de façon pure, et c'est juste les fonctions côté GUI qui gère la mise à jour de la variable.
 
Bref, je ne vois (pour l'instant du moins) rien de plus propre.

en fait, ca ne m'aide pas a choisir, parce que je peux avoir mon gameplay pur peu importe ce que je mets en ioref, mon callback fait le readIORef, appelle la/les fonctions pures, et fait le writeIORef derriere.
 
donc de ce coté là, que je mettes juste mes unités en ioref, ou les armées en ioref (qui contiennent donc les unités), ou tout l'état du jeu dans une  seule ioref, ca ne change rien par rapport a ca.
 
je tourne en rond en fait, parce que les 3 sont possibles, mais je n'arrive pas a voir lequel est le "mieux"

Euh, joker
Je pense que prendre la bonne décision nécessite une meilleure connaissance d'haskell que ce que j'ai... Si t'as accès à irc, tu peux toujours demander sur #haskell tu obtiendras sans doute des réponses fondées voire argumentées

j'ai pas.
 
je pense que je vais mettre les armées uniquement en ioref, et il sera toujours temps de changer si c'est trop pénible à l'usage.  
 
merci de tes réponses en tout cas

Avec plaisir; tiens nous (moi? je sais pas si y'a des lurkeurs ici ) au courant, ton expérimentation me sera d'une grande aide quand je me déciderais à lâcher un peu l'apprentissage d'haskell en mode console...

bon, j'ai un doute sur ce que je fais, je crains un peu pour les perfs, parce que je ne comprends pas ce qui se passe derrière :
 
J'ai toujours mes mêmes types :

 
J'ai ce code (le U, c'est le module Unit, qui contient mon type & quelques bricoles)

 
et a l'utilisation, si l'unité en (x, y) se fait attaquer, j'ai ca

 
Et si j'imagine bien ce qui se passe, je n'arrete pas de reconstruire mes listes et mes Army, non ?
ou alors le compilateur est vraiment très fort ?