I could use some examples maybe. So I do Prelude> :show paths current working directory: /home/galaxybeing/Dropbox/org/RealWorldHaskell module import search paths: . ...and there is no *.yaml file in this directory. I'm saying there's a disjoint between where my ghci REPL inside of Emacs is working and the actual :! pwd. And I when I do find the appropriate yaml I'd need some examples on the way to add the correct lines to get the packages, the ghc/ghci platform. I've tried just a generic stack command from the command prompt, which I assumed would apply to wherever my "global" Haskell is -- to no avail, just cryptic errors talking about downloaded code examples. On Sun, Jun 6, 2021 at 4:01 PM Jeff Clites via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

Run ‘stack ghci’ and it will log the path to the YAML file you can edit to customize what configuration it uses when run outside of a project. Here you can specify additional packages you want to be available, and you set the resolver version which controls the GHC version. (Then you configure emacs to run ‘stack ghci’ instead of ‘ghci’.)

Jeff

On Jun 6, 2021, at 12:45 PM, Galaxy Being wrote:

As a beginner, I was told to use stack. And I seemed to get something Haskell installed initially on my Ubuntu 21.04. But stack seems to be geared toward projects and compiling executables with ghc, and not a global ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a very nice "literate" programming in tandem with a running REPL in many REPL-friendly languages, e.g., here are code blocks in an org-mode file

#+begin_src haskell :results silent :exports code data Peano = Zero | Succ Peano deriving (Show) #+end_src

#+begin_src haskell :results silent :exports code myThree = Succ (Succ (Succ Zero)) #+end_src

#+begin_src haskell :results verbatim :exports both myThree #+end_src

#+RESULTS: : Succ (Succ (Succ Zero))

I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a running ghci REPL started up in another Emacs buffer. Supposedly, a haskell-mode and a specific Babel ob-haskell package are working together to enable this. And so it works okay, once quirks (must enclose multi-lined code in :{..:} and every REPL session seems to need a :set +m as well). I'm really quite happy with this way of doing things and have resisted the whole monolithic 1) create project in a directory, 2) put code into .hs file, 3) compile with ghc.

But what I'm constantly having problems with is getting additional packages beyond the Prelude basics. My org files are in various directories, but I want (like most languages offer) to simply interact with that language on a global level wherever I am, whatever files and directories and Haskell code I'm working on. Sometimes doing an import works; often enough not. Then I have to do something with stack -- hopefully globally . . . and there the confusion and inconsistencies begin. Lately I can't seem to get Safe installed. And all docs about editing some yaml stuff get me lost in the weeds quickly. What yaml where for my "global" situation?

If you simply say to me, Don't try to work outside of the project--hs files--compile to executable framework I'll say okay, then have to decide whether I want to stay within the org-mode world or leave Haskell for an org-mode friendlier language. And no, lhs and jupyter are primitive compared to org-mode literate programming. Both are a step backwards.

Any help on working outside the project box with stack, e.g., how to install and use packages (and even how to update/upgrade ghc and ghci would be a start!).

- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com

The Stack configuration that is used outside of projects is stored in the following location: ~/.stack/global-project/stack.yaml This configuration file is used when you run `stack ghci` outside of a project. Such project configuration files can specify the Stackage snapshot to be used (`resolver`), any packages that should be used that are different from or not in the specified Stackage snapshot (`extra-deps`), a list of packages that are being developed (`packages`, none by default in the "global project"), as well as some other settings documented at the following location. https://docs.haskellstack.org/en/stable/yaml_configuration/ Such a project configuration file determines what packages are *available* for use. The motivation is to provide an environment where all of the available packages work together, saving you from having to deal with dependency conflicts. It does not *expose* packages to the compiler or REPL. Packages are usually exposed by specifying them in a `.cabal` file (or `package.yaml` file when using hpack). In my experience, the `~/.stack/global-project/stack.yaml` configuration is most often used when installing executables using Stack. For example, one can install the version of `hlint` that is in the Stackage snapshot configured in the configuration file as follows: stack install hlint What you would like to do is not normal usage of Stack, but I understand your motivation. It is possible to do what you want by configuring a global project with the packages that you would like to make available. First, create file `~/.stack/global-project/global-project.cabal` with the following content: name: global-project version: 0.0.0.0 cabal-version: 1.24 build-type: Simple library build-depends: base , safe default-language: Haskell2010 Add any packages that you would like to expose to the `build-depends` list. Next, configure `~/.stack/global-project/stack.yaml` as follows: resolver: lts-17.14 packages: - . Update the `resolver` configuration whenever you want to change Stackage snapshots. Note that you will need to add `extra-deps` configuration to this file if you ever want to expose a package that is not in the configured snapshot, in addition to adding it to the `build-depends` list. With this configuration, the listed packages should be exposed when you run `stack ghci` to run a REPL. Good luck! Travis

Was there a stack.yaml file in the directory you were in when you ran stack? If it finds a stack.yaml in your current directory when you run stack, it uses it. Jeff

On Jun 7, 2021, at 2:22 PM, Galaxy Being wrote:

I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs. Good. I duplicated

packages: [] resolver: lts-17.15

on my Ubuntu 21.04 in the .stack/global-project/stack.yaml. Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.). But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says

Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section. Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section. You can omit this message by removing it from stack.yaml

Stack looks for packages in the directories configured in the 'packages' and 'extra-deps' fields defined in your stack.yaml The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/, but no .cabal or package.yaml file could be found there.

Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only

packages: [] resolver: lts-17.15

Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.

...

On Sun, Jun 6, 2021 at 7:10 PM Travis Cardwell wrote: The Stack configuration that is used outside of projects is stored in the following location:

~/.stack/global-project/stack.yaml

This configuration file is used when you run `stack ghci` outside of a project. Such project configuration files can specify the Stackage snapshot to be used (`resolver`), any packages that should be used that are different from or not in the specified Stackage snapshot (`extra-deps`), a list of packages that are being developed (`packages`, none by default in the "global project"), as well as some other settings documented at the following location.

https://docs.haskellstack.org/en/stable/yaml_configuration/

Such a project configuration file determines what packages are *available* for use. The motivation is to provide an environment where all of the available packages work together, saving you from having to deal with dependency conflicts. It does not *expose* packages to the compiler or REPL. Packages are usually exposed by specifying them in a `.cabal` file (or `package.yaml` file when using hpack).

In my experience, the `~/.stack/global-project/stack.yaml` configuration is most often used when installing executables using Stack. For example, one can install the version of `hlint` that is in the Stackage snapshot configured in the configuration file as follows:

stack install hlint

What you would like to do is not normal usage of Stack, but I understand your motivation. It is possible to do what you want by configuring a global project with the packages that you would like to make available. First, create file `~/.stack/global-project/global-project.cabal` with the following content:

name: global-project version: 0.0.0.0 cabal-version: 1.24 build-type: Simple

library build-depends: base , safe default-language: Haskell2010

Add any packages that you would like to expose to the `build-depends` list. Next, configure `~/.stack/global-project/stack.yaml` as follows:

resolver: lts-17.14

packages: - .

Update the `resolver` configuration whenever you want to change Stackage snapshots. Note that you will need to add `extra-deps` configuration to this file if you ever want to expose a package that is not in the configured snapshot, in addition to adding it to the `build-depends` list.

With this configuration, the listed packages should be exposed when you run `stack ghci` to run a REPL.

Good luck!

Travis

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Sorry to hear that it is still not working for you yet. On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:

I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs.

Stack provides functionality to initialize a project with a "template" so that you do not have to start from scratch. For example, if you want to start a new project called "HaskellTest" in your `~/Dropbox/org` directory, run the following commands: $ cd ~/Dropbox/org $ stack new HaskellTest The default template provides you with a `stack.yaml` file that includes documentation and examples. The template also provides you with a `package.yaml` file (used to generate the `.cabal` file using hpack) that has a library, executable, and test suite configured, as well as stub source code and various other files. Note that in cases where you already have a Haskell project (with a `.cabal` or `package.yaml` file), the `stack init` command can be used to add just the `stack.yaml` to the existing project.

Good. I duplicated

packages: [] resolver: lts-17.15

on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.

Note that this `stack.yaml` file is for the "global-project" as it does not have any packages configured. The `stack.yaml` file for any (other) project should list at least one package.

Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.).

The resolver snapshot in the "global-project" is set when you first run Stack. After that, it is up to you to update it *if/when* you would like to use a different snapshot. Similarly, the resolver snapshot for a project `stack.yaml` is set when you run `stack new` or `stack init`, and then it is up to you to maintain it as desired.

But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says

Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section. Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section. You can omit this message by removing it from stack.yaml

Stack looks for packages in the directories configured in the 'packages' and 'extra-deps' fields defined in your stack.yaml The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/, but no .cabal or package.yaml file could be found there.

Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only

packages: [] resolver: lts-17.15

These errors indicate that `~/.stack/global-project/stack.yaml` is *not* being used. It is likely that you are running `stack` commands in a directory that contains a `stack.yaml` file which references these other directories, and that file is being used. Try (re)moving that `stack.yaml` file and trying again. Do the errors persist? Once you (re)move the project `stack.yaml` configuration, the `stack ghci` will use the `~/.stack/global-project/stack.yaml` configuration. With the above content, the LTS 17.15 resolver will be used, with no packages configured. As explained in my previous email, this does *not* expose libraries to GHCi. If you want to expose libraries in the global project, you need to follow the instructions I gave previously for configuring the global project.

Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.

Indeed. Installation is tricky, particularly across multiple operating systems. Most book authors avoid writing about it, as writing about it in sufficient detail would likely fill a book itself. Most beginner books even stick with the `base` package so that readers do not even have to worry about packages. Global installation of packages leads to a *lot* of trouble when you get to more complex development. When I first learned Haskell, I would occasionally completely remove my package database when I got into a situation that was difficult to resolve. The situation improved a lot when Cabal introduced sandbox features, allowing dependencies to be managed separately per project. Stack is project-based for the same reason: allowing each project to use separate sets of packages makes things a lot easier. The "global-project" is called "global" because it is used when outside of any other Haskell project (determined by the existence of a `stack.yaml` file in the current working directory), but note that it is actually a project. Following the instructions that I wrote in my previous email, you can configure Stack to work in the way that you want *without* running into the aforementioned trouble even when you start to develop other projects. Good luck! Travis

On Jun 8, 2021, at 9:20 AM, Galaxy Being wrote:

If I'm understanding correctly, I can follow the stack way of setting up a project in a directory, then if I start a ghci REPL in that directory, I'm in that project's sandbox, true? But if I start a ghci REPL in some directory that has no stack project already set up, then that REPL is relying on the global "project," so to speak.

Yes. The point of Stack is to allow different projects to use different versions of GHC and different versions of libraries and have those projects never interfere with each other. To do this it’s logically necessary for Stack to always run based on a configuration file that tells it which set of versions you want to use for this run.

It's somewhat confusing since the project way of doing Haskell is to compile with ghc, and run at a shell (same as C) and not have a running ghci. Two different cultures.

In both cases you are compiling some Haskell code and running it. It’s just that in the ghci case it’s doing both of those for you in one step. Really ghci is just meant for experimentation. I think this is similar for most languages I’ve encountered that have a REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not directly using the REPL, even if the REPL happens to be built into the same tool you use to run your program. The REPL is mostly a tool for quick experimentation. Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a loop around compiling and running some code. From that perspective, the compile and run steps are the fundamental steps and the REPL is just a bit of automation around those. It’s not the fundamental thing.

It's difficult for me as a Haskell beginner to understand why beginner tutorials all have me working with the ghci REPL

It’s because that’s the way to run small experiments quickly. They are trying to teach you the language as concisely as possible, and not the overall development environment. (Also, as a practical matter, the instructions for setting up a development environment change and printed books don’t, so including detailed setup instructions would be a waste because they’d become out of date.)

-- but then that's apparently not how real-world Haskell works. Or is it?

Correct; you don’t use the REPL to run large programs. You use it to try things out.

So Emacs is a running ball of C and Elisp code with an Elisp REPL that gives you control over the running system.

Right. The Emacs case is different than others in that in this case your elisp programs are (typically) extending the functionality of this particular text editor, basically acting as plugin, rather than functioning as separate programs that have nothing to do with a text editor. I wouldn’t use Emacs as a model for conceptualizing other languages; it’s quite a special case. Jeff

...

On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell wrote: Sorry to hear that it is still not working for you yet.

On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:

...

I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs.

Stack provides functionality to initialize a project with a "template" so that you do not have to start from scratch. For example, if you want to start a new project called "HaskellTest" in your `~/Dropbox/org` directory, run the following commands:

$ cd ~/Dropbox/org $ stack new HaskellTest

The default template provides you with a `stack.yaml` file that includes documentation and examples. The template also provides you with a `package.yaml` file (used to generate the `.cabal` file using hpack) that has a library, executable, and test suite configured, as well as stub source code and various other files.

Note that in cases where you already have a Haskell project (with a `.cabal` or `package.yaml` file), the `stack init` command can be used to add just the `stack.yaml` to the existing project.

...

Good. I duplicated

packages: [] resolver: lts-17.15

on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.

Note that this `stack.yaml` file is for the "global-project" as it does not have any packages configured. The `stack.yaml` file for any (other) project should list at least one package.

...

Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.).

The resolver snapshot in the "global-project" is set when you first run Stack. After that, it is up to you to update it *if/when* you would like to use a different snapshot.

Similarly, the resolver snapshot for a project `stack.yaml` is set when you run `stack new` or `stack init`, and then it is up to you to maintain it as desired.

...

But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says

Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section. Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section. You can omit this message by removing it from stack.yaml

Stack looks for packages in the directories configured in the 'packages' and 'extra-deps' fields defined in your stack.yaml The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/, but no .cabal or package.yaml file could be found there.

Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only

packages: [] resolver: lts-17.15

These errors indicate that `~/.stack/global-project/stack.yaml` is *not* being used. It is likely that you are running `stack` commands in a directory that contains a `stack.yaml` file which references these other directories, and that file is being used. Try (re)moving that `stack.yaml` file and trying again. Do the errors persist?

Once you (re)move the project `stack.yaml` configuration, the `stack ghci` will use the `~/.stack/global-project/stack.yaml` configuration. With the above content, the LTS 17.15 resolver will be used, with no packages configured. As explained in my previous email, this does *not* expose libraries to GHCi. If you want to expose libraries in the global project, you need to follow the instructions I gave previously for configuring the global project.

...

Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.

Indeed. Installation is tricky, particularly across multiple operating systems. Most book authors avoid writing about it, as writing about it in sufficient detail would likely fill a book itself. Most beginner books even stick with the `base` package so that readers do not even have to worry about packages.

Global installation of packages leads to a *lot* of trouble when you get to more complex development. When I first learned Haskell, I would occasionally completely remove my package database when I got into a situation that was difficult to resolve. The situation improved a lot when Cabal introduced sandbox features, allowing dependencies to be managed separately per project. Stack is project-based for the same reason: allowing each project to use separate sets of packages makes things a lot easier. The "global-project" is called "global" because it is used when outside of any other Haskell project (determined by the existence of a `stack.yaml` file in the current working directory), but note that it is actually a project. Following the instructions that I wrote in my previous email, you can configure Stack to work in the way that you want *without* running into the aforementioned trouble even when you start to develop other projects.

Good luck!

Travis

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

No, when you make changes to xmonad you have to reload/recompile it (by default bound to mod-q) for the changes to take effect On Tue., Jun. 8, 2021, 2:43 p.m. Galaxy Being, wrote:

But to my XMonad example. The Emacs world has the Emacs system running live, but the REPL capable of tweaking the live, running Emacs world in any way imaginable. Lisp and Scheme are this way too. (PicoLisp only this way.) Something similar must be happening with XMonad. After all, if I make configuration changes to xmonad.hs, somehow they must go into effect on a live, running XMonad, right? I don't log out of XMonad to a system shell, then compile the new executable with my config tweaks, then restart this new XMonad. No, I must be in some sort of Emacs-like situation -- or like a shell with C forking -- or some sort of event management device of XMonad where the "meta" XMonad is always running, but treating my config changes as hot-swappable plugins. Or like Unix/Linux with bootstrapping of a sort. Or am I missing something? I think this is very basic information, but I sure can't find it anywhere. As I have come to understand the REPL from the Lisp world, it's a running virtual machine that allows live tweaking and programming. An executable, OTOH, is an independent agent living as a process on the host OS. In Emacs, with some languages you can even have separate org mode babel REPL sessions. But back to XMonad, I'm guessing it's a Haskell executable that then acts like a virtual machine that allows hot-swapping plug-and-play....

On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites wrote:

...

On Jun 8, 2021, at 9:20 AM, Galaxy Being wrote:

If I'm understanding correctly, I can follow the stack way of setting up a project in a directory, then if I start a ghci REPL in that directory, I'm in that project's sandbox, true? But if I start a ghci REPL in some directory that has no stack project already set up, then that REPL is relying on the global "project," so to speak.

Yes. The point of Stack is to allow different projects to use different versions of GHC and different versions of libraries and have those projects never interfere with each other. To do this it’s logically necessary for Stack to always run based on a configuration file that tells it which set of versions you want to use for this run.

It's somewhat confusing since the project way of doing Haskell is to compile with ghc, and run at a shell (same as C) and not have a running ghci. Two different cultures.

In both cases you are compiling some Haskell code and running it. It’s just that in the ghci case it’s doing both of those for you in one step. Really ghci is just meant for experimentation.

I think this is similar for most languages I’ve encountered that have a REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not directly using the REPL, even if the REPL happens to be built into the same tool you use to run your program. The REPL is mostly a tool for quick experimentation.

Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a loop around compiling and running some code. From that perspective, the compile and run steps are the fundamental steps and the REPL is just a bit of automation around those. It’s not the fundamental thing.

It's difficult for me as a Haskell beginner to understand why beginner tutorials all have me working with the ghci REPL

It’s because that’s the way to run small experiments quickly. They are trying to teach you the language as concisely as possible, and not the overall development environment. (Also, as a practical matter, the instructions for setting up a development environment change and printed books don’t, so including detailed setup instructions would be a waste because they’d become out of date.)

-- but then that's apparently not how real-world Haskell works. Or is it?

Correct; you don’t use the REPL to run large programs. You use it to try things out.

So Emacs is a running ball of C and Elisp code with an Elisp REPL that gives you control over the running system.

Right. The Emacs case is different than others in that in this case your elisp programs are (typically) extending the functionality of this particular text editor, basically acting as plugin, rather than functioning as separate programs that have nothing to do with a text editor. I wouldn’t use Emacs as a model for conceptualizing other languages; it’s quite a special case.

Jeff

On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell < travis.cardwell@extrema.is> wrote:

...

Sorry to hear that it is still not working for you yet.

On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:

...

I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs.

Stack provides functionality to initialize a project with a "template" so that you do not have to start from scratch. For example, if you want to start a new project called "HaskellTest" in your `~/Dropbox/org` directory, run the following commands:

$ cd ~/Dropbox/org $ stack new HaskellTest

The default template provides you with a `stack.yaml` file that includes documentation and examples. The template also provides you with a `package.yaml` file (used to generate the `.cabal` file using hpack) that has a library, executable, and test suite configured, as well as stub source code and various other files.

Note that in cases where you already have a Haskell project (with a `.cabal` or `package.yaml` file), the `stack init` command can be used to add just the `stack.yaml` to the existing project.

...

Good. I duplicated

packages: [] resolver: lts-17.15

on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.

Note that this `stack.yaml` file is for the "global-project" as it does not have any packages configured. The `stack.yaml` file for any (other) project should list at least one package.

...

Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.).

The resolver snapshot in the "global-project" is set when you first run Stack. After that, it is up to you to update it *if/when* you would like to use a different snapshot.

Similarly, the resolver snapshot for a project `stack.yaml` is set when you run `stack new` or `stack init`, and then it is up to you to maintain it as desired.

...

But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says

Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section. Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section. You can omit this message by removing it from stack.yaml

Stack looks for packages in the directories configured in the 'packages' and 'extra-deps' fields defined in your stack.yaml The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/, but no .cabal or package.yaml file could be found there.

Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only

packages: [] resolver: lts-17.15

These errors indicate that `~/.stack/global-project/stack.yaml` is *not* being used. It is likely that you are running `stack` commands in a directory that contains a `stack.yaml` file which references these other directories, and that file is being used. Try (re)moving that `stack.yaml` file and trying again. Do the errors persist?

Once you (re)move the project `stack.yaml` configuration, the `stack ghci` will use the `~/.stack/global-project/stack.yaml` configuration. With the above content, the LTS 17.15 resolver will be used, with no packages configured. As explained in my previous email, this does *not* expose libraries to GHCi. If you want to expose libraries in the global project, you need to follow the instructions I gave previously for configuring the global project.

...

Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.

Indeed. Installation is tricky, particularly across multiple operating systems. Most book authors avoid writing about it, as writing about it in sufficient detail would likely fill a book itself. Most beginner books even stick with the `base` package so that readers do not even have to worry about packages.

Global installation of packages leads to a *lot* of trouble when you get to more complex development. When I first learned Haskell, I would occasionally completely remove my package database when I got into a situation that was difficult to resolve. The situation improved a lot when Cabal introduced sandbox features, allowing dependencies to be managed separately per project. Stack is project-based for the same reason: allowing each project to use separate sets of packages makes things a lot easier. The "global-project" is called "global" because it is used when outside of any other Haskell project (determined by the existence of a `stack.yaml` file in the current working directory), but note that it is actually a project. Following the instructions that I wrote in my previous email, you can configure Stack to work in the way that you want *without* running into the aforementioned trouble even when you start to develop other projects.

Good luck!

Travis

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

XMonad recompiles your config and then exec()s it, passing it some current state. It's not the same as elisp. On Tue, Jun 8, 2021 at 2:41 PM Galaxy Being wrote:

But to my XMonad example. The Emacs world has the Emacs system running live, but the REPL capable of tweaking the live, running Emacs world in any way imaginable. Lisp and Scheme are this way too. (PicoLisp only this way.) Something similar must be happening with XMonad. After all, if I make configuration changes to xmonad.hs, somehow they must go into effect on a live, running XMonad, right? I don't log out of XMonad to a system shell, then compile the new executable with my config tweaks, then restart this new XMonad. No, I must be in some sort of Emacs-like situation -- or like a shell with C forking -- or some sort of event management device of XMonad where the "meta" XMonad is always running, but treating my config changes as hot-swappable plugins. Or like Unix/Linux with bootstrapping of a sort. Or am I missing something? I think this is very basic information, but I sure can't find it anywhere. As I have come to understand the REPL from the Lisp world, it's a running virtual machine that allows live tweaking and programming. An executable, OTOH, is an independent agent living as a process on the host OS. In Emacs, with some languages you can even have separate org mode babel REPL sessions. But back to XMonad, I'm guessing it's a Haskell executable that then acts like a virtual machine that allows hot-swapping plug-and-play....

On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites wrote:

...

On Jun 8, 2021, at 9:20 AM, Galaxy Being wrote:

If I'm understanding correctly, I can follow the stack way of setting up a project in a directory, then if I start a ghci REPL in that directory, I'm in that project's sandbox, true? But if I start a ghci REPL in some directory that has no stack project already set up, then that REPL is relying on the global "project," so to speak.

Yes. The point of Stack is to allow different projects to use different versions of GHC and different versions of libraries and have those projects never interfere with each other. To do this it’s logically necessary for Stack to always run based on a configuration file that tells it which set of versions you want to use for this run.

It's somewhat confusing since the project way of doing Haskell is to compile with ghc, and run at a shell (same as C) and not have a running ghci. Two different cultures.

In both cases you are compiling some Haskell code and running it. It’s just that in the ghci case it’s doing both of those for you in one step. Really ghci is just meant for experimentation.

I think this is similar for most languages I’ve encountered that have a REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not directly using the REPL, even if the REPL happens to be built into the same tool you use to run your program. The REPL is mostly a tool for quick experimentation.

Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a loop around compiling and running some code. From that perspective, the compile and run steps are the fundamental steps and the REPL is just a bit of automation around those. It’s not the fundamental thing.

It's difficult for me as a Haskell beginner to understand why beginner tutorials all have me working with the ghci REPL

It’s because that’s the way to run small experiments quickly. They are trying to teach you the language as concisely as possible, and not the overall development environment. (Also, as a practical matter, the instructions for setting up a development environment change and printed books don’t, so including detailed setup instructions would be a waste because they’d become out of date.)

-- but then that's apparently not how real-world Haskell works. Or is it?

Correct; you don’t use the REPL to run large programs. You use it to try things out.

So Emacs is a running ball of C and Elisp code with an Elisp REPL that gives you control over the running system.

Right. The Emacs case is different than others in that in this case your elisp programs are (typically) extending the functionality of this particular text editor, basically acting as plugin, rather than functioning as separate programs that have nothing to do with a text editor. I wouldn’t use Emacs as a model for conceptualizing other languages; it’s quite a special case.

Jeff

On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell < travis.cardwell@extrema.is> wrote:

...

Sorry to hear that it is still not working for you yet.

On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:

...

I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs.

Stack provides functionality to initialize a project with a "template" so that you do not have to start from scratch. For example, if you want to start a new project called "HaskellTest" in your `~/Dropbox/org` directory, run the following commands:

$ cd ~/Dropbox/org $ stack new HaskellTest

The default template provides you with a `stack.yaml` file that includes documentation and examples. The template also provides you with a `package.yaml` file (used to generate the `.cabal` file using hpack) that has a library, executable, and test suite configured, as well as stub source code and various other files.

Note that in cases where you already have a Haskell project (with a `.cabal` or `package.yaml` file), the `stack init` command can be used to add just the `stack.yaml` to the existing project.

...

Good. I duplicated

packages: [] resolver: lts-17.15

on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.

Note that this `stack.yaml` file is for the "global-project" as it does not have any packages configured. The `stack.yaml` file for any (other) project should list at least one package.

...

Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.).

The resolver snapshot in the "global-project" is set when you first run Stack. After that, it is up to you to update it *if/when* you would like to use a different snapshot.

Similarly, the resolver snapshot for a project `stack.yaml` is set when you run `stack new` or `stack init`, and then it is up to you to maintain it as desired.

...

But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says

Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section. Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section. You can omit this message by removing it from stack.yaml

Stack looks for packages in the directories configured in the 'packages' and 'extra-deps' fields defined in your stack.yaml The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/, but no .cabal or package.yaml file could be found there.

Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only

packages: [] resolver: lts-17.15

These errors indicate that `~/.stack/global-project/stack.yaml` is *not* being used. It is likely that you are running `stack` commands in a directory that contains a `stack.yaml` file which references these other directories, and that file is being used. Try (re)moving that `stack.yaml` file and trying again. Do the errors persist?

Once you (re)move the project `stack.yaml` configuration, the `stack ghci` will use the `~/.stack/global-project/stack.yaml` configuration. With the above content, the LTS 17.15 resolver will be used, with no packages configured. As explained in my previous email, this does *not* expose libraries to GHCi. If you want to expose libraries in the global project, you need to follow the instructions I gave previously for configuring the global project.

...

Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.

Indeed. Installation is tricky, particularly across multiple operating systems. Most book authors avoid writing about it, as writing about it in sufficient detail would likely fill a book itself. Most beginner books even stick with the `base` package so that readers do not even have to worry about packages.

Global installation of packages leads to a *lot* of trouble when you get to more complex development. When I first learned Haskell, I would occasionally completely remove my package database when I got into a situation that was difficult to resolve. The situation improved a lot when Cabal introduced sandbox features, allowing dependencies to be managed separately per project. Stack is project-based for the same reason: allowing each project to use separate sets of packages makes things a lot easier. The "global-project" is called "global" because it is used when outside of any other Haskell project (determined by the existence of a `stack.yaml` file in the current working directory), but note that it is actually a project. Following the instructions that I wrote in my previous email, you can configure Stack to work in the way that you want *without* running into the aforementioned trouble even when you start to develop other projects.

Good luck!

Travis

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf@gmail.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com