Tienes tres opciones.
Plataforma Haskell
Es una posibilidad pero no una opción popular por muchas razones que descubrirá a su debido tiempo si elige ir por este camino. Tendrás una experiencia mucho mejor y obtendrás mucho mejor soporte con Stack o Nix. Cuál de esas dos personas usan parece ser principalmente una preferencia personal. Son bestias diferentes, pero para un principiante las diferencias no serán inmediatamente obvias, por lo que hay pocas esperanzas de que pueda tomar una "decisión informada". Solo elige uno y vuelve a evaluar más tarde.
Apilar
Esto es lo que sugeriría a cualquier persona (que no esté familiarizada con Nix) que quiera comenzar a usar Haskell rápidamente. Período. No necesita instalar nada por separado, Stack se encargará de todas las cosas de Haskell por usted. Normalmente nunca usas cabal directamente con Stack. stack build usa cabal internamente pero no necesitas preocuparte por eso. Una cosa a tener en cuenta, Stack no es un administrador de paquetes. Es una herramienta de construcción. Normalmente no instala cualquier cosa. Sin embargo, obtiene todas las dependencias que necesita y las almacena en ~/.stack junto con otras cosas.
nada
Esto es lo que uso personalmente, por lo que puedo estar sesgado, pero creo que esta es la mejor solución en general a largo plazo. La advertencia es que hay una curva de aprendizaje bastante empinada y tienes muchas oportunidades de pegarte un tiro en el pie cuando empiezas.
Recomiendo encarecidamente comenzar con Stack, pero mantener la mente abierta sobre Nix a medida que continúa su viaje con Haskell.
Aquí hay una respuesta alternativa (larga). Tenga en cuenta que también solía recomendar Stack para principiantes, pero desde entonces cambié de opinión.
TL;RD: Ya sea Haskell Platform o una instalación pura de Stack pueden brindarle todo lo que necesita, y no se "perderá" nada al elegir uno u otro. Probablemente le resulte más fácil omitir Stack e instalar Haskell Platform usando el instalador de Linux "Genérico", porque viene con todo lo que necesita y la configuración se asemejará más a lo que se describe en el libro LYAH. Puede instalar Stack más adelante cuando esté realizando un desarrollo más serio en varios proyectos. Si prefiere quedarse con una instalación pura de Stack, le sugiero comenzar con un flujo de trabajo de "solo proyecto global". De cualquier manera, puede usar el "modo haskell" con algunas correcciones de configuración sugeridas a continuación (incluida una configuración clave que será necesaria si está trabajando en el proyecto global de una instalación solo de Stack).
Aquí está la respuesta larga...
Pila vs Plataforma vs Cabal
El libro de LYAH es anterior a Stack, que es sin duda la principal razón por la que no lo menciona. En haskell.org, recomiendan usar un instalador mínimo, Stack o la Plataforma Haskell. Los tres métodos son formas perfectamente razonables en 2018 para configurar un entorno Haskell que funcione. Difieren en la forma en que eligen aislar diferentes versiones del compilador y/o bibliotecas en "cajas de arena" para el trabajo de desarrollo, y en cuánto instalan inicialmente , pero no hay nada que "falte" en ninguno de ellos que no se pueda instalar a pedido. Dependiendo de lo que elija, habrá algunas diferencias en su flujo de trabajo (ver más abajo).
Tanto Stack como Cabal son administradores de paquetes combinados y herramientas de compilación. (Stack tiene la capacidad adicional de iniciar una instalación completa de Haskell, por lo que también es un método de instalación por derecho propio). Mientras trabaja a través de LYAH, en realidad no usará la funcionalidad de "herramienta de compilación" directamente en sus propios proyectos. (Las instalaciones de compilación integradas de GHC son más que adecuadas para crear proyectos pequeños de varios módulos). Solo necesitará la funcionalidad del administrador de paquetes para instalar bibliotecas adicionales.
Dado que Stack y Cabal administran sus paquetes por separado, si usa Stack, no tendrá una necesidad particular de usar Cabal directamente. Puede instalarlo si lo desea (y, de hecho, Stack utiliza Cabal para algunas funciones esotéricas, como "solucionador de pila", y requerirá que esté instalado en esos casos):
$ stack install cabal-install
Pero, a pesar de que esto pondrá "cabal" en "$HOME/.local/bin" (y querrás asegurarte de que esto esté en tu camino), encontrarás que necesitas saltar a través de aros para ejecutarlo. :
$ stack exec --no-ghc-package-path cabal -- list
y realmente no hace nada útil en lo que respecta a su entorno de pila.
Actualización: Una nota sobre la ruta "$HOME/.local/bin". Parece que el script de instalación de https://get.haskellstack.org/ puede instalar Stack en /usr/local/bin/stack por defecto si no hay una instalación existente. Sin embargo, debería mostrar una advertencia para poner $HOME/.local/bin en tu camino Si actualiza Stack en el futuro con stack upgrade , instalará la nueva versión de stack allí, y ese directorio también se usará si instala paquetes que incluyen archivos binarios. Por ejemplo, stack install hlint instalará el programa Haskell Lint hlint a ese directorio. Por lo tanto, es una buena idea tenerlo en tu camino y en algún lugar antes del /usr/local/bin .
Qué le falta a Stack
Creo que eso cubre sus tres primeras preguntas. Por último, lo principal que le falta al haber instalado Stack en lugar de Haskell Platform es que, por diseño, Stack realmente no instala nada globalmente más que "stack" en sí. Por lo tanto, todo su trabajo de Haskell, incluida la ejecución del intérprete de Haskell ("ghci") o el compilador ("ghc"), debe realizarse dentro de un entorno de pila, ya sea utilizando un comando de pila correspondiente específico:
$ 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!
$
o bien usando "stack exec" para ejecutar un programa genérico dentro de un entorno Stack apropiado. Por ejemplo, a veces puede ser útil ejecutar un shell Bash debajo de la pila, después de lo cual las cosas se comportan como un entorno de plataforma Haskell instalado globalmente:
$ 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. ...
$
La otra cosa que te estás perdiendo es que Haskell Platform instala un montón de bibliotecas comunes de forma predeterminada, mientras que un nuevo entorno de Stack comienza casi sin nada (ni siquiera el compilador, antes de ejecutar stack setup ). Mientras trabaja con LYAH, es posible que necesite instalar periódicamente bibliotecas adicionales. Por ejemplo, en la Entrada y Salida capítulo, los ejemplos usando números aleatorios (módulo System.Random ) requerirá que ejecute:
$ stack install random
y reinicie su intérprete.
Recomendación para usar la plataforma Haskell
Debido a que Stack es un poco complicado y realmente no necesitará las instalaciones que proporciona al principio, es posible que la Plataforma Haskell le resulte más fácil de usar cuando esté comenzando. (El instalador "Genérico" debería funcionar bien en su distribución). Viene con todo instalado, y la forma en que lo use coincidirá más con la forma en que se describen las cosas en LYAH. Junto con haskell-mode , debería tener un entorno Haskell bastante decente.
En general, no debería haber ningún problema con Stack y Haskell Platform instalados uno al lado del otro (como lo demuestra el hecho de que Haskell Platform en realidad incluye Pila). Stack mantendrá todo por separado en el subdirectorio "$HOME/.stack", por lo que no habrá interferencia entre compiladores o paquetes ni nada. Tenga en cuenta que en esta configuración, usará cabal para administrar los paquetes instalados en el lado de la plataforma de las cosas, y stack -- obviamente -- para administrar paquetes en el lado de la pila.
Flujo de trabajo para principiantes para una instalación de pila pura
Si desea seguir con su instalación pura de Stack, podría sugerirle el siguiente flujo de trabajo cuando esté comenzando:
Verá referencias a proyectos de Stack, creados con "stack new" o "stack init". Evítelos al principio y quédese con la pila "proyecto global". Este es el proyecto implícito que tendrá efecto cuando ejecute "stack" en un directorio que no tenga un archivo "stack.yaml" (directamente o en un directorio principal):
$ cd
$ stack path --project-root
/u/buhr/.stack/global-project
$
Cuando está trabajando en el proyecto global (es decir, no en algún lugar bajo un stack.yaml archivo), puede invocar el intérprete y el compilador con:
$ stack exec ghci
$ stack ghc -- -O2 Hello.hs
y ambos tendrán acceso a cualquier biblioteca adicional (paquetes) que hayas instalado usando comandos como:
$ stack install random
Actualizado: Una nota sobre la diferencia entre stack ghci y stack exec ghci . El primero está destinado a ejecutar GHCi dentro del contexto de un proyecto local (es decir, trabajando bajo un stack.yaml expediente). Pasa algunas banderas adicionales para ocultar paquetes instalados globalmente y para hacer que los módulos estén disponibles automáticamente desde su paquete. Cuando se trabaja en el proyecto global, no creo que haya ninguna diferencia práctica excepto que stack ghci genera una advertencia; y no importa cuál use, deberá cargar sus propios módulos explícitamente con :load Whatever.hs . Hay un poco más de información sobre la diferencia en esta página de documentación de Stack, particularmente en la parte inferior donde trata de explicar la diferencia.
Eventualmente, puede cambiar a un flujo de trabajo que use proyectos de Stack. Esto implicará usar stack new para crear un nuevo directorio de proyectos de Stack, stack setup para instalar/vincular una versión privada del compilador en ese directorio y luego modificar el xxx.cabal del proyecto (y posiblemente su stack.yaml file) para indicar qué paquetes adicionales se requieren, en lugar de usar stack install . Todo es un poco complicado cuando solo quieres empezar a escribir código.
También puede ver una referencia a Intero, un modo de Emacs diseñado específicamente para Stack. Intero es muy agradable, pero no funciona muy bien cuando se trabaja con archivos en el proyecto global. Tenderá a querer iniciar el intérprete en el directorio "~/.stack/global-project", lo cual es bastante inútil. (Uso Intero, pero lo he parcheado para que se comporte mejor en este sentido).
Configuración del modo Haskell (para plataforma o pila)
Probablemente sea mejor seguir con el "modo haskell" y pensar en Intero cuando comience a usar proyectos no globales. Sugeriría instalar "modo haskell" de MELPA según las instrucciones, pero agregando lo siguiente a su .emacs archivo en lugar de lo que se sugiere en la documentación:
(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))
Probé esto con una instalación Stack pura usando "haskell-mode-20171022.26", y parece funcionar bien. Puedo cargar un nuevo archivo Haskell en el proyecto global, enviarlo a una sesión interactiva con "C-c C-l" y explorar los errores resaltados en el archivo fuente con "M-n" y "M-p". (Los errores aparecen en el minibúfer.)
Si decide usar la Plataforma Haskell en su lugar, creo que toda esta configuración de "modo haskell" se seguirá aplicando, excepto que debe eliminar la última línea de personalización. (El haskell-process-type predeterminado de auto elegirá algo apropiado.)
¡Espero que eso ayude!