On 16-09-13 12:07, Theodore Lief Gannon wrote: > Stack *does* allow direct interaction with GHC: > > stack exec -- ghc version > I find `stack ghc -- --version` to be a bit easier. Anything after the `--` is passed as an argument to ghc.
From the help documentation: stack ghc -- X.hs -o x > Granted this lacks a bit in brevity, but if you want to issue multiple > commands from "inside" stack's private environment, you can also just do > this: > > stack exec sh > > On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg <r...@cs.brynmawr.edu> > wrote: > > > I’ve watched the recent back-and-forth about stack with quite a bit of > > interest (as many of us have). The discussion inspired me to take another > > look at stack. Here are the results of that foray. > > > > First, a disclosure: While I have appreciated the emergence of a new build > > tool for Haskell, I have never much liked stack. One of my chief goals in > > taking another look is to understand better why I do not like it. > > > > My task: Set up a Haskell environment on a new machine (a Mac). This > > machine has no Haskell infrastructure on it. > > > > My approach: > > > > 1. `brew install haskell-stack`. Success. > > > > At this point, I do not have a Haskell project I wish to build. Instead, I > > really just want the ability to run Haskell expressions in GHCi. So I skip > > `stack new` and go straight to > > > > 2. `stack setup`. This succeeds, but prints out some interesting messages > > along the way, including > > > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > > Right Nothing > > > > At the end, I am helpfully told > > > > > To use this GHC and packages outside of a project, consider using: > > > stack ghc, stack ghci, stack runghc, or stack exec > > > > > > > So I then > > > > 3. `stack ghci`. My computer’s first reaction is to say > > > > > Run from outside a project, using implicit global project config > > > Using resolver: lts-6.17 from implicit global project's config file: > > /home/rae/.stack/global-project/stack.yaml > > > Error parsing targets: The specified targets matched no packages. > > > Perhaps you need to run 'stack init'? > > > Warning: build failed, but optimistically launching GHCi anyway > > > > > > > which doesn’t make me feel all that comfortable, but then I am indeed > > delivered to the GHCi prompt, which works as expected. > > > > Done with GHCi, I quit. I then want to double-check which version of GHC I > > got, so I > > > > 4. `stack ghc --version`. This command reports > > > > > Invalid option `--version’ > > > > Grumble. It seems I can’t interact with GHC directly. > > > > ———— > > > > At this point, I am reminded why I dislike stack: > > > > **It’s optimized for a different workflow than I use.** > > > > And I think this fact (repeated by others’ experiences) is why a segment > > of our community has not celebrated stack as much as other segments have. > > We all have different workflows. > > > > From what I understand about it, stack is great for a project-based > > workflow. In this workflow, you are working on a Haskell project. You are > > happy to specify settings in .cabal and stack.yaml files. And you really > > want your build to work in the future and on other machines. > > > > In my experience, stack is not great with a compiler-based workflow. In > > this workflow, you aren’t quite as organized perhaps and do not have all > > your settings written. You also want the ability just to compile a file > > without changing any configurations. You want to be able to start GHCi with > > a nice set of libraries with which to experiment. > > > > I definitely like a compiler-based workflow. I’m sure that many of you > > prefer a project-based workflow. > > > > The great news here is that we have a choice: use stack for a > > project-based workflow, and don’t use it when you want a compiler-based > > workflow. No one needs to convince others about personal preferences. > > > > But there is one nagging issue: what do we suggest to newcomers? The > > downloads page right now is not serving us well. (I was legitimately > > scratching my head at first trying to figure out how to provision a new > > computer.) Sadly, I don’t see a good option presenting itself. Both > > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > > serious shortcomings. > > > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > > Platform Minimal) does appear to lack a “here’s what you do first” > > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > > discover — you have to choose the oft-maligned Haskell Platform link before > > you are told that there is a minimal variant. > > > > B. stack sets up GHC in a way that either 1) requires a project-based > > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > > warnings every time GHC is invoked outside of a project. Furthermore, stack > > prohibits direct interaction with GHC (as in `ghc --version`). > > > > There’s more good news here! Both of these problems are really easy to fix. > > > > To fix (A), someone just has to write the tutorial. > > > > To fix (B), stack just needs a new option so that `stack setup` installs a > > system GHC. Perhaps it would even be sufficient for `stack setup` to > > clearly tell the user where ghc is installed and what to add to their PATH. > > > > I also think, if readers agree with my conclusions about workflows, we > > should consider writing up criteria that potential users should consider > > when choosing what workflow to start with. We’ll need to have a tighter > > recommendation for those with no experience programming, but most > > developers should be able to recognize what workflow they prefer and choose > > accordingly. > > > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > > we’ll really be in a quandary about which installation procedure to put > > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > > one happens first gets to be featured first on the page? :) > > > > So: Does my characterization of workflows resonate? Have I perhaps > > identified part of the burning black heart of the reason behind the vitriol > > of late? Should we fix (A) and (B)? > > > > I’m looking forward to hearing your thoughts. > > > > Richard > > > > > > -=-=-=-=-=-=-=-=-=-=- > > Richard A. Eisenberg > > Asst. Prof. of Computer Science > > Bryn Mawr College > > Bryn Mawr, PA, USA > > cs.brynmawr.edu/~rae > > > > _______________________________________________ > > 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.
signature.asc
Description: PGP signature
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
