<div dir="ltr">XMonad recompiles your config and then exec()s it, passing it some current state. It's not the same as elisp.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 8, 2021 at 2:41 PM Galaxy Being <<a href="mailto:borgauf@gmail.com">borgauf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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....</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites <<a href="mailto:jclites@mac.com" target="_blank">jclites@mac.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>On Jun 8, 2021, at 9:20 AM, Galaxy Being <<a href="mailto:borgauf@gmail.com" target="_blank">borgauf@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">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.</div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="ltr">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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div><div dir="ltr">It's difficult for me as a Haskell beginner to understand why beginner tutorials all have me working with the ghci REPL</div></div></blockquote><div><br></div><div>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.)</div><br><blockquote type="cite"><div><div dir="ltr"> -- but then that's apparently not how real-world Haskell works. Or is it?</div></div></blockquote><div><br></div><div>Correct; you don’t use the REPL to run large programs. You use it to try things out.</div><br><blockquote type="cite"><div><div dir="ltr">So Emacs is a running ball of C and Elisp code with an Elisp REPL that gives you control over the running system.</div></div></blockquote><div><br></div><div><span style="background-color:rgba(255,255,255,0)">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.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">Jeff</span></div><br><blockquote type="cite"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <<a href="mailto:travis.cardwell@extrema.is" target="_blank">travis.cardwell@extrema.is</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry to hear that it is still not working for you yet.<br>
<br>
On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:<br>
> I installed stack on my Windows computer using chocolatey, which went<br>
> smoothly. But I had nothing anywhere I could find. On a hunch, at the<br>
> prompt I tried to run stack ghci, then it started downloading and<br>
> installing stuff. Good. I then was able to track down an example of a<br>
> stack.yaml in the ...stack/global-project directory. My whole<br>
> motivation was to see an actual global stack.yaml in the wild, and not<br>
> have to guess-and-test from the stack docs.<br>
<br>
Stack provides functionality to initialize a project with a "template"<br>
so that you do not have to start from scratch. For example, if you want<br>
to start a new project called "HaskellTest" in your `~/Dropbox/org`<br>
directory, run the following commands:<br>
<br>
$ cd ~/Dropbox/org<br>
$ stack new HaskellTest<br>
<br>
The default template provides you with a `stack.yaml` file that includes<br>
documentation and examples. The template also provides you with a<br>
`package.yaml` file (used to generate the `.cabal` file using hpack)<br>
that has a library, executable, and test suite configured, as well as<br>
stub source code and various other files.<br>
<br>
Note that in cases where you already have a Haskell project (with a<br>
`.cabal` or `package.yaml` file), the `stack init` command can be used<br>
to add just the `stack.yaml` to the existing project.<br>
<br>
> Good. I duplicated<br>
><br>
> packages: []<br>
> resolver: lts-17.15<br>
><br>
> on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.<br>
<br>
Note that this `stack.yaml` file is for the "global-project" as it does<br>
not have any packages configured. The `stack.yaml` file for any (other)<br>
project should list at least one package.<br>
<br>
> Tried running stack ghci from the Ubuntu prompt, and, similarly, it<br>
> started installing lots of stuff. (The resolver version I replaced was<br>
> lts-17.08. Why that old I don't know.).<br>
<br>
The resolver snapshot in the "global-project" is set when you first run<br>
Stack. After that, it is up to you to update it *if/when* you would<br>
like to use a different snapshot.<br>
<br>
Similarly, the resolver snapshot for a project `stack.yaml` is set when<br>
you run `stack new` or `stack init`, and then it is up to you to<br>
maintain it as desired.<br>
<br>
> But then I got a cryptic error as it seemed to clash or not like<br>
> something it saw in some obscure github directory I had cloned ages<br>
> ago with Haskell example code. I deleted everything in the github<br>
> directory that looked stack/cabal-ish and tried stack ghci again. Now<br>
> it says<br>
><br>
> 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.<br>
> 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.<br>
> You can omit this message by removing it from stack.yaml<br>
><br>
> Stack looks for packages in the directories configured in<br>
> the 'packages' and 'extra-deps' fields defined in your stack.yaml<br>
> The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,<br>
> but no .cabal or package.yaml file could be found there.<br>
><br>
> Yes, that was the directory I purged. My<br>
> .stack/global-project/stack.yaml contains only<br>
><br>
> packages: []<br>
> resolver: lts-17.15<br>
<br>
These errors indicate that `~/.stack/global-project/stack.yaml` is *not*<br>
being used. It is likely that you are running `stack` commands in a<br>
directory that contains a `stack.yaml` file which references these other<br>
directories, and that file is being used. Try (re)moving that<br>
`stack.yaml` file and trying again. Do the errors persist?<br>
<br>
Once you (re)move the project `stack.yaml` configuration, the<br>
`stack ghci` will use the `~/.stack/global-project/stack.yaml`<br>
configuration. With the above content, the LTS 17.15 resolver will be<br>
used, with no packages configured. As explained in my previous email,<br>
this does *not* expose libraries to GHCi. If you want to expose<br>
libraries in the global project, you need to follow the instructions I<br>
gave previously for configuring the global project.<br>
<br>
> Not sure how to proceed. Seeing how that vast majority of Haskell<br>
> intro books don't use projects, just install, start ghci, load code at<br>
> the REPL prompt, I'd really like to nail this "global", non-project<br>
> stack down.<br>
<br>
Indeed. Installation is tricky, particularly across multiple operating<br>
systems. Most book authors avoid writing about it, as writing about it<br>
in sufficient detail would likely fill a book itself. Most beginner<br>
books even stick with the `base` package so that readers do not even<br>
have to worry about packages.<br>
<br>
Global installation of packages leads to a *lot* of trouble when you get<br>
to more complex development. When I first learned Haskell, I would<br>
occasionally completely remove my package database when I got into a<br>
situation that was difficult to resolve. The situation improved a lot<br>
when Cabal introduced sandbox features, allowing dependencies to be<br>
managed separately per project. Stack is project-based for the same<br>
reason: allowing each project to use separate sets of packages makes<br>
things a lot easier. The "global-project" is called "global" because<br>
it is used when outside of any other Haskell project (determined by the<br>
existence of a `stack.yaml` file in the current working directory), but<br>
note that it is actually a project. Following the instructions that I<br>
wrote in my previous email, you can configure Stack to work in the way<br>
that you want *without* running into the aforementioned trouble even<br>
when you start to develop other projects.<br>
<br>
Good luck!<br>
<br>
Travis<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>⨽<br></div>Lawrence Bottorff<div>Grand Marais, MN, USA</div><div><a href="mailto:borgauf@gmail.com" target="_blank">borgauf@gmail.com</a></div></div></div>
</blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Haskell-Cafe mailing list</span><br><span>To (un)subscribe, modify options or view archives go to:</span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a></span><br><span>Only members subscribed via the mailman list are allowed to post.</span></div></blockquote></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>⨽<br></div>Lawrence Bottorff<div>Grand Marais, MN, USA</div><div><a href="mailto:borgauf@gmail.com" target="_blank">borgauf@gmail.com</a></div></div></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>