J'essaie d'apprendre Haskell dans le livre Learn You a Haskell par Miran Lipovača. Le livre et haskell.org recommandent d'installer la Haskell Platform mais il n'y a pas de téléchargement pour Manjaro Linux (basé sur Arch) que j'utilise.
J'ai trouvé cela guide de 2014 et j'ai décidé d'installer les packages du référentiel de Manjaro. Cela a bien fonctionné jusqu'à ce que je veuille utiliser le mode haskell dans Emacs. J'ai résolu ce problème et découvert que c'était un problème avec les packages (Stack principalement).
En cherchant des moyens de résoudre ce problème, j'ai trouvé ce fil Reddit , qui décrit les moyens d'installer Haskell (pas la plate-forme), et les problèmes avec les packages. J'ai suivi l'un des commentaires et j'ai fini par installer Stack (et GHC) avec le script comme décrit ici :
wget -qO- https://get.haskellstack.org/ | sh
stack setup
stack update
Mes questions sont liées à cela:
$HOME/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2
beaucoup d'entre eux semblent déjà installés.Voici une (longue) réponse alternative. Notez que je recommande également Stack pour les débutants, mais j'ai depuis changé d'avis.
TL; DR: La plate-forme Haskell ou une installation Stack pure peut vous fournir tout ce dont vous avez besoin, et vous ne manquerez de rien en choisissant un ou l'autre. Vous trouverez probablement plus facile de sauter Stack et d'installer Haskell Platform à l'aide du programme d'installation Linux "générique", car il est livré avec tout ce dont vous avez besoin et la configuration correspondra plus étroitement à ce qui est décrit dans le livre LYAH. Vous pouvez installer Stack plus tard lorsque vous effectuez un développement plus sérieux sur plusieurs projets. Si vous préférez vous en tenir à une installation Stack pure, je vous suggère de commencer avec un flux de travail "projet global uniquement". Dans les deux cas, vous pouvez utiliser le "mode haskell" avec quelques correctifs de configuration suggérés ci-dessous (y compris un paramètre clé qui sera requis si vous travaillez dans le projet global d'une installation Stack-only).
Voici la longue réponse ...
Le livre de LYAH est antérieur à Stack, ce qui est certainement la principale raison pour laquelle il ne le mentionne pas. Sur haskell.org, ils recommandent d'utiliser un programme d'installation minimal, Stack ou la plate-forme Haskell. Les trois méthodes sont des moyens parfaitement raisonnables en 2018 pour configurer un environnement Haskell fonctionnel. Ils diffèrent à la fois dans la façon dont ils choisissent d'isoler différentes versions du compilateur et/ou des bibliothèques dans des "bacs à sable" pour le travail de développement, et dans la quantité qu'ils installent initialement, mais il n'y a rien de "manquant" de l'un d'eux qui ne peut pas être installé sur demande. Selon votre choix, il y aura des différences dans votre flux de travail (voir ci-dessous).
Stack et Cabal sont des gestionnaires de packages et des outils de construction combinés. (Stack a la capacité supplémentaire de réellement bootstrap une installation Haskell entière, c'est pourquoi c'est aussi une méthode d'installation à part entière.) Pendant que vous travaillez via LYAH, vous ne utiliser la fonctionnalité "outil de construction" directement sur vos propres projets (les fonctions de construction intégrées de GHC sont plus que suffisantes pour la construction de petits projets multi-modules). Vous aurez juste besoin de la fonctionnalité du gestionnaire de paquets pour installer des bibliothèques supplémentaires .
Étant donné que Stack et Cabal gèrent leurs packages séparément, si vous utilisez Stack, vous n'aurez pas particulièrement besoin d'utiliser Cabal directement. Vous pouvez l'installer si vous le souhaitez (et en fait, Stack utilise Cabal pour certaines fonctionnalités ésotériques, comme le "solveur de pile", et exigera qu'il soit installé dans ces cas):
$ stack install cabal-install
Mais, même si cela mettra "cabale" dans "$ HOME/.local/bin" (et vous voudrez vous assurer que c'est sur votre chemin), vous constaterez que vous devez sauter à travers des cerceaux pour l'exécuter :
$ stack exec --no-ghc-package-path cabal -- list
et cela ne fait rien d'utile en ce qui concerne votre environnement Stack.
Mise à jour: Une note sur le chemin "$ HOME/.local/bin". Il ressemble au script d'installation de https://get.haskellstack.org/ peut installer Stack lui-même dans /usr/local/bin/stack
Par défaut s'il n'y a pas d'installation existante. Cependant, il devrait afficher un avertissement pour mettre $HOME/.local/bin
Dans votre chemin. Si vous mettez à niveau Stack à l'avenir avec stack upgrade
, Il y installera la nouvelle version de stack
, et ce répertoire sera également utilisé si vous installez des packages qui incluent des binaires. Par exemple, stack install hlint
Installera le programme Haskell Lint hlint
dans ce répertoire. C'est donc une bonne idée de l'avoir sur votre chemin et quelque part avant /usr/local/bin
.
Je pense que cela couvre vos trois premières questions. Pour votre dernier, la principale chose qui vous manque après avoir installé Stack au lieu de la plate-forme Haskell est que, par conception, Stack n'installe vraiment rien d'autre que la "pile" elle-même. Ainsi, tout votre travail Haskell, y compris l'exécution de l'interpréteur Haskell ("ghci") ou du compilateur ("ghc"), tout doit être fait dans un environnement Stack, soit en utilisant une commande Stack correspondante spécifique:
$ echo 'main = putStrLn "Hello, world!"' > Hello.hs
$ stack ghc -- Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o )
Linking Hello ...
$ ./Hello
Hello, world!
$
ou bien utiliser "stack exec" pour exécuter un programme générique dans un environnement Stack approprié. Par exemple, il peut parfois être utile d'exécuter un shell Bash sous pile, après quoi les choses se comportent un peu comme un environnement Haskell Platform installé globalement:
$ stack exec bash
$ ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Prelude> :quit
$ ghc -O2 Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o ) [flags changed]
Linking Hello ...
$ exit
$ ghc
The program 'ghc' is currently not installed. ...
$
L'autre chose qui vous manque, c'est que la plate-forme Haskell installe tout un tas de bibliothèques communes par défaut, tandis qu'un nouvel environnement Stack démarre avec presque rien (pas même le compilateur, avant d'exécuter stack setup
). Lors de l'utilisation de LYAH, il se peut que vous deviez installer régulièrement des bibliothèques supplémentaires. Par exemple, dans le chapitre Input and Output, les exemples utilisant des nombres aléatoires (module System.Random
) Vous obligeront à exécuter:
$ stack install random
et redémarrez votre interprète.
Parce que Stack est un peu compliqué et que vous n'aurez pas vraiment besoin des fonctionnalités qu'il fournit au début, vous pouvez trouver la plate-forme Haskell plus facile à utiliser lorsque vous commencez. (Le programme d'installation "générique" devrait fonctionner correctement sur votre distribution.) Il est livré avec tout ce qui est installé, et la façon dont vous l'utilisez correspondra mieux à la façon dont les choses sont décrites dans LYAH. Avec haskell-mode
, Vous devriez avoir un environnement Haskell assez décent.
En général, il ne devrait y avoir aucun problème à ce que Stack et la plateforme Haskell soient installés côte à côte (comme en témoigne le fait que la plateforme Haskell inclut Stack). Stack conservera tout séparément dans le sous-répertoire "$ HOME/.stack", donc il n'y aura aucune interférence entre les compilateurs ou les packages ou quoi que ce soit. Notez que dans cette configuration, vous utiliserez cabal
pour gérer les packages installés du côté Plateforme, et stack
- évidemment - pour gérer les packages du côté Stack.
Si vous souhaitez vous en tenir à votre installation pure Stack, je pourrais suggérer le flux de travail suivant lorsque vous commencez:
Vous verrez des références aux projets Stack, créés avec "stack new" ou "stack init". Évitez-les au début et respectez la pile "projet global". Il s'agit du projet implicite qui sera en vigueur lorsque vous exécuterez "stack" dans un répertoire qui n'a pas de fichier "stack.yaml" (directement ou dans un répertoire parent):
$ cd
$ stack path --project-root
/u/buhr/.stack/global-project
$
Lorsque vous travaillez dans le projet global (c'est-à-dire pas quelque part sous un fichier stack.yaml
), Vous pouvez appeler l'interpréteur et le compilateur avec:
$ stack exec ghci
$ stack ghc -- -O2 Hello.hs
et ils auront tous les deux accès à toutes les bibliothèques (packages) supplémentaires que vous avez installées à l'aide de commandes telles que:
$ stack install random
Mise à jour: Une note sur la différence entre stack ghci
Et stack exec ghci
. Le premier est destiné à exécuter GHCi dans le contexte d'un projet local (c'est-à-dire en travaillant sous un fichier stack.yaml
). Il passe des drapeaux supplémentaires pour masquer les packages installés globalement et pour rendre automatiquement les modules disponibles à partir de votre package. Lorsque je travaille dans le projet global, je ne pense pas qu'il y ait de différence pratique sauf que stack ghci
Génère un avertissement; et peu importe ce que vous utilisez, vous devrez charger explicitement vos propres modules avec :load Whatever.hs
. Il y a un peu plus d'informations sur la différence sur cette page de documentation Stack , en particulier en bas où il essaie d'expliquer la différence.
Finalement, vous pouvez basculer vers un flux de travail qui utilise des projets Stack. Cela impliquera d'utiliser stack new
Pour créer un nouveau répertoire de projet Stack, stack setup
Pour installer/lier une version privée du compilateur dans ce répertoire, puis modifier le fichier xxx.cabal
Du projet (et éventuellement son fichier stack.yaml
) pour indiquer les packages supplémentaires requis, au lieu d'utiliser stack install
. C'est un peu compliqué quand vous voulez juste commencer à écrire du code.
Vous pouvez également voir une référence à Intero, un mode Emacs conçu spécifiquement pour Stack. Intero est très agréable, mais cela ne fonctionne pas très bien lorsque vous travaillez sur des fichiers dans le projet global. Il aura tendance à vouloir démarrer l'interpréteur dans le répertoire "~/.stack/global-project", ce qui est assez inutile. (J'utilise Intero, mais je l'ai corrigé pour mieux se comporter à cet égard.)
Il est probablement préférable de s'en tenir au "mode haskell" à la place et de penser à Intero lorsque vous commencez à utiliser des projets non globaux. Je suggère d'installer "haskell-mode" de MELPA selon les instructions, mais en ajoutant ce qui suit à votre fichier .emacs
Au lieu de ce qui est suggéré dans la documentation:
(require 'haskell)
;; add capability to submit code to interpreter and mark errors
(add-hook 'haskell-mode-hook 'interactive-haskell-mode)
;; add missing keybindings for navigating errors
(define-key interactive-haskell-mode-map (kbd "M-n") 'haskell-goto-next-error)
(define-key interactive-haskell-mode-map (kbd "M-p") 'haskell-goto-prev-error)
(define-key interactive-haskell-mode-map (kbd "C-c M-p")
'haskell-goto-first-error)
;; merge this with your existing custom-set-variables
(custom-set-variables
;; NOTE: include following line to work around haskell-mode
;; bug if using GHC >= 8.2.1.
;; See: https://github.com/haskell/haskell-mode/issues/1553
'(haskell-process-args-stack-ghci
'("--ghci-options=-ferror-spans -fshow-loaded-modules"
"--no-build" "--no-load"))
;; some options suggested in the haskell-mode documentation
'(haskell-process-auto-import-loaded-modules t)
'(haskell-process-log t)
'(haskell-process-suggest-remove-import-lines t)
;; make sure "stack ghci" is used, even in the global project
'(haskell-process-type 'stack-ghci))
J'ai testé cela avec une installation Stack pure en utilisant "haskell-mode-20171022.26", et cela semble bien fonctionner. Je peux charger un nouveau fichier Haskell dans le projet global, le soumettre à une session interactive avec "C-c C-l" et parcourir les erreurs surlignées dans le fichier source avec "M-n" et "M-p". (Les erreurs apparaissent dans le mini-tampon.)
Si vous décidez d'utiliser la plate-forme Haskell à la place, je pense que toute cette configuration en "mode haskell" s'appliquera toujours, sauf que vous devez supprimer la toute dernière ligne de personnalisation. (La valeur par défaut haskell-process-type
De auto
choisira quelque chose de approprié.)
J'espère que ça t'as aidé!
Vous avez trois choix.
C'est une possibilité mais pas un choix populaire pour de nombreuses raisons que vous découvrirez en temps voulu si vous choisissez de suivre cette voie. Vous aurez une bien meilleure expérience et obtiendrez beaucoup un meilleur support avec Stack ou Nix. Laquelle de ces deux personnes utilise semble être principalement une préférence personnelle. Ce sont des bêtes différentes, mais pour un débutant, les différences ne seront pas immédiatement évidentes, il y a donc peu d'espoir que vous puissiez prendre une "décision éclairée". Choisissez-en un et réévaluez plus tard.
C'est ce que je suggérerais à quiconque (ne connaissant pas Nix) souhaite commencer rapidement avec Haskell. Période. Vous n'avez pas besoin d'installer séparément quoi que ce soit, Stack s'occupera de tout le matériel Haskell pour vous. Normalement, vous n'utilisez jamais la cabale directement avec Stack. stack build
utilise la cabale en interne mais vous n'avez pas à vous en préoccuper. Une chose à noter, Stack n'est pas un gestionnaire de paquets. C'est un outil de construction. Il ne fait normalement installer rien. Il récupère cependant toutes les dépendances dont il a besoin et les stocke dans ~/.stack
avec d'autres choses.
C'est ce que j'utilise personnellement, donc je peux être partial mais je pense que c'est la meilleure solution dans l'ensemble à long terme. La mise en garde est qu'il y a une courbe d'apprentissage assez abrupte et vous avez de nombreuses chances de vous tirer une balle dans le pied au début.
Je recommande fortement de commencer par Stack mais gardez un esprit ouvert sur Nix pendant que votre voyage avec Haskell se poursuit.