Reprise du message précédent :
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 ?

Je crois pas que le compilo fasse des trucs pareils non

de maniere plus générale, si je veux modifier un champ d'un élément d'une liste, comment je fais, proprement ?

Ben comme ça à première vue, mais j'aurais essayé d'utiliser les hofs existantes, genre map/filter/reduce toussa, parce que là tu réinventes pas mal la roue.
 
Sinon, essaie de poser la question dans #haskell, ou de voir comment ce genre de trucs est fait dans xmonad

si ce n'est que ca...

Tu peux changer l'écriture de hit pour celle-ci qui se contente de copier unit en modifiant uniquement le champ nécessaire:

hit :: Int -> Unit -> Unit
hit amount unit = unit { hitPoints = hitPoints unit - amount }

Et +1 avec mask pour utiliser les fonctions faite pour. Tu peux changer un peu la logique comme ça aussi par exemple (en supprimant la dépendance entre Army et Unit au niveau des update)

updateUnit :: Coords -> (U.Unit -> U.Unit) -> [Unit] -> [Unit]
updateUnit c f = map (\u -> if U.coords u == c then f u else u)
 
updateArmyUnit :: Army -> Coords -> (U.Unit -> U.Unit) -> Army
updateArmyUnit army c f = army { units = updateUnit c f $ units army }
 
-- et pour utiliser le tout:
map (\a -> Army.updateArmyUnit a (x, y)  (hit 1)) armies

J'ai du mal à imaginer une amélioration des perfs liées à ça par contre, mais bon déjà tu gagnes en taille et lisibilité du code

Edit: j'ai changé updateArmyList pour ne s'appliquer qu'à une armée à cause du nom de la fonction et parce que ça me paraîssait plus logique de n'agir que sur une armée à la fois, mais bien sûr, tu peux la repasser sur armies et bouger l'appel à map dedans

Edit2: inversion de la fonction et de la coordonnée dans updateArmyUnit...
Edit3: et correction de l'exemple. Comme quoi je ferais vraiment mieux de tester avant de mettre ça ici

c'est vrai que c'est plus clair, je n'avais pas encore vu la copie en modifiant qu'un champs, ca aide pas mal.

pour les perfs, c'est surement un faux problème, je n'ai pas constaté de lenteur (vu la taille des données de toutes facons...), je me demandais juste.

finalement j'ai mis 2 iorefs : un data Game qui contient la carte et les armées (donc les unités, leur etat et positition), et la selection courante (un Maybe (Army, Unit)).
 
Ca marche bien

C'est bon à savoir, merci

je pense que j'en mettrais un 3eme quand je commencerais la gestion des tours, pour savoir qui doit jouer, mais je n'en suis pas encore la.

J'ai fait du caml, du prolog et de l'alpha-calcul, j'ai le droit de dawater et de foutre ma merde?

Pas sûr, ici, c'est strict

T'auras pas juste à cycler une liste de x joueurs?

Ca va dépendre de comment je fais l'ihm en fait.
Si je veux pas que tu puisses sélectionner les units de ton adversaire, il faut que mon code appelé par gtk lors du dessin sache qui est le joueur courant, donc je suis obligé de le mettre en IORef par un moyen ou un autre pour que la fonction de dessin puisse le récupérer.

Non ?

Moui, toutafé; c'est moi qui pensais un niveau "plus bas" encore, désolé.

Je m'intéresse depuis peu à l'approche fonctionnelle (depuis que je suis tombé sur les vidéos du SICP en fait ) et suis à proprement parler sur le cul. J'adore la façon dont le LISP (et en particulier le Scheme) est construit : quelques prédicats et fonctions de bases, une  syntaxe super simple (enfin surtout pour la machine ) et la possibilité de redéfinir completement le langage. Ca change des ambiguités syntaxiques du C et des #define crados
 
Je trouve dommage de pas avoir (encore) eu l'occasion de tomber sur du fonctionnel pendant mes études, je sors d'un IUT info et tout ce qu'on attends de nous c'est de pouvoir pisser des kilomètres de Java

La mécanique des fluides n'est pas au programme du CAP plomberie non plus...  

Attention, les Lisp ont un certain nombre de spécificités (la syntaxe et les macros, principalement) qui sont spécifique aux lisp, et pas au domaine fonctionnel. Tu ne les retrouvera pas nécessairement, ou tout du moins pas nécessairement sous la même forme, dans les autres langages fonctionnels.
 
En attendant, si tu as apprécié les vidéos SICP, je te conseille de te payer le bouquin, c'est un excellent investissement

Les langages fonctionnels, c'est pas vendeur, c'est pas que ce les SSII et autres demandent, et la méthode actuelle (surtout en IUT, mais les écoles d'ingé info de bas de tableau sont dans la même optique ) c'est pas de sortir des gens ayant la culture et les connaissance pour apprendre ce qui sera vendeur pendant leur carrière, c'est de sortir des gens qui pissent du code permettant de les vendre

GHC a des (morceaux de) messages d'erreurs totalement compréhensibles:

Je crois que je lui ai fait vraiment mal là

Haskell est toujours autant totozifiant...
 
J'ai une petite question liée à la rapidité et à la consommation mémoire. La routine qui m'intéresse est l'écriture dans un fichier targa d'une liste de couleur (une couleur étant un tuple (Float,Float,Float,Float)).
 
Je me sers de 2 helpers:
* roundClamp: transforme une liste de float compris entre 0 et 1 en une liste de char
* writeColors: applique roundClamp récursivement à une liste de Color4 pour générer une liste de Char
 
Les fonctions concernées dans leur totalité:

roundClamp :: Float -> Char
roundClamp = (toEnum . round . min 255 . (*) 255)

writeColors :: [Color4] -> [Char]
writeColors ((Color4 (r,g,b,a)) : colors) = (map roundClamp [r,g,b,a]) ++ (writeColors colors)
writeColors [] = []

writeTga :: String -> Int -> Int -> [Char] -> IO ()
writeTga filename width height colors =
        let tgaDefaultHeader :: [Char]
            tgaDefaultHeader = map (toEnum.fromIntegral)
                                   [0,0,2,0,0,0,0,0,0,0,0,0,
                                    ( width  .&. 0x00FF),
                                    ((width  .&. 0xFF00) `div` 256),
                                    ( height .&. 0x00FF),
                                    ((height .&. 0xFF00) `div` 256),
                                    32, 0]
         in do h <- openFile filename WriteMode
               hPutStr h tgaDefaultHeader
               hPutStr h colors
               hClose h

 
Si je mets roundClamp et writeColors dans le let de de writeTga, il faut ajouter ~0.5s d'exécution et 140 MB de mémoire consommée.
 
La question est simple: pourquoi?
Je pensais naïvement qu'une fonction déclarée dans un let était juste une fonction locale à la fonction contenant le let et que la seule incidence serait liée à la portée. De toute évidence non, et j'éviterais à l'avenir de faire ce genre de trucs. Mais je suis assez curieux de l'explication si quelqu'un en a une

heuu tu les utiliserais comment exactement, roundClamp et (surtout) writeColors?

Actuellement (avec le code ci-dessus), je les utilise ainsi:

main = writeTga "test.tga" resX resY $ writeColors $ draw rayt

(Edit: draw rayt est une méthode qui dessine une scène et renvoit une liste de Color4, c'est un petit raytracer)

Résumé du profil avec ce code:

Précédemment, le code était:

writeTga :: String -> Int -> Int -> [Color4] -> IO ()
writeTga filename width height colors =
        let tgaDefaultHeader :: [Char]
            tgaDefaultHeader = map (toEnum.fromIntegral)
                                   [0,0,2,0,0,0,0,0,0,0,0,0,
                                    ( width  .&. 0x00FF),
                                    ((width  .&. 0xFF00) `div` 256),
                                    ( height .&. 0x00FF),
                                    ((height .&. 0xFF00) `div` 256),
                                    32, 0]
            roundClamp :: Float -> Char
            roundClamp = (toEnum . round . min 255 . (*) 255)
            writeColors :: [Color4] -> [Char]
            writeColors ((Color4 (r,g,b,a)) : colors) =
                        (map roundClamp [r,g,b,a]) ++ (writeColors colors)
            writeColors [] = []
         in do h <- openFile filename WriteMode
               hPutStr h tgaDefaultHeader
               hPutStr h $ writeColors colors
               hClose h

main = writeTga "test.tga" resX resY $ draw rayt

Résumé du profil avec ce code:

(Les 2 versions du projet sont compilées en -O2)

PS: les noms de fonctions ne sont plus très explicite dû à certains tests, avoir des noms plus clair est parmi les choses à faire

Je commence à me demander si ce serait pas parce qu'il y aurait une copie de moins... J'ai bon? (Je pensais que ce genre de trucs était compris par le compilo)

Je sais pas en fait, par contre je me dis que t'as intérêt à pas avoir trop de couleurs dans ton truc.

Si tu parles de la résolutions, y'a des chances que ça reste à peu prés stable (je fais mes tests en 800x600 actuellement).

A part le temps d'exécution, tu vois un autre risque? Est-ce que passer une fonction à draw qui servirait de "convertisseur" pour basculer chaque pixel dans sa représentation finale serait intéressant?

No se, tu devrais coller ton truc dans hpaste et aller demander sur #haskell, je suis sûr que tu trouveras des gens qui t'expliqueront très bien ce qui se passe (surtout si e.g. dons est présent)

Ok, je ferais ça. Juste pas du taf, ce serait un peu abusé

Pourquoi?

Parce que j'ai arrêté de me démonter au taf, mais qu'il faudrait tout de même que j'assure un "service minimum" avant de trouver mieux </my_life>

Ouais enfin c'est pas aller poser une question et lire 3 réponses sur #haskell qui t'empêche de bosser

C'est peut-être pas de les lire qui prend du temps mais de les comprendre ...
(je suis déjà dehors)

Yop,
 
Je viens tout juste de découvrir Erlang et les langages fonctionnels.
Pour m'amuser je veux filtrer une list pour récupérer uniquement les nombres pairs.
J'ai commencé par écrire deux fonctions, even et odd.
 

even(X) ->
    case X of
       0 ->
         true;
       N ->  Y = N -1,
         odd(Y)
    end.

odd(X) ->
    case X of
        0 ->
         false;
    N -> Y = N - 1,
         even(Y)
    end.

 
Donc je me demande s'il n'est pas possible d'écrire ces fonctions autrement? (Sans utiliser le "case" par exemple)

donc filter : http://www.trapexit.org/Filter_All [...] n_Criteria

Je connais filter, celà dit ce n'est pas la que réside ma question

J'ai ré écrit even comme suit :

even(X) when X rem 2 == 0 ->
    true;
even(_X) -> 
    false.

Edit :

D'où

odd(X) ->
    even(X) == false;
odd(_X) ->
    false.

Ma question c'est "Est ce que je procède correctement (le code fonctionne, mais est ce qu'il est bien écrit)"

even(X) -> X rem 2 == 0.
odd(X) -> not even(X).

nan ?

even(X) -> X rem 2 == 0.
odd(X) -> not even(X).

Ouaip
Je savais pas qu'on pouvait écrire ça

Ben ta fonction retourne un booléen... Le fait que tu ne types pas explicitement ne te dispense pas d'avoir en tête que tes variables sont typées.

Le monsieur il comprends pas pourquoi tu dis ça

+1 je vois pas le rapport

concept error, abort