Improving the "Get Haskell Experience"

[Kosyrev Serge]

Greg Weber <greg at gregweber.info> writes:
> The main reason I am using stack is for its support for building a project
> containing multiple packages. There aren't any other tools that make this a
> first-class concept that is easy to use and not buggy.
> In addition, stack has a first-class concept of curated package sets. All of these
> are required to have smooth installs in real world projects, and they aren't
> likely to appear in cabal-install in a short time frame.

The problem that I'm personally facing all too often, is exploratory
development, where the modus operandi is to try using versions/branches
that are not yet released on Hackage.

Things like this happen especially during GHC version transitions, where
ghc-new buildability of libraries/tools is often in flux, and so you
/have/ to chase the tail (or is it HEAD?).

As an example, the version of ghc-mod that works with 7.10 is still
unreleased on Cabal -- months passed, the prospects still indefinite.

But it also happens out of plain curiosity and willingness to try out
how new things could affect the way of problem expression.

For an example of that, let's take the 'nokinds' branch of GHC, where
Richard Eisenberg does research on formulating GHC with dependent types.

Another situation where these things matter especially is collaborative
development -- trying to help with bugs, for example.

All these things ring of the same, actually..

..where Hackage puts a mild barrier to sharing small contributions with
the world, Stack puts a wall.

Which is a good thing.

But also a bad one.

..and unless I'm wrong, and we're indeed moving to a world where people would
increasingly use Stack, this dichotomy is /bound/ to become more pressing.

Curiously, there's a technology to solve to both sides of the story -- Nix,
which was mentioned before, but I think its salient point applies especially
well to this dichotomy:

 1. use the existing curated releases, but also can
 2. override packages with a Github fork URL, commit id and the physical
    checkout hash -- and have everything pick it up in a transparent, fixpoint way.

Admittedly it's not been made as trivial to use -- there's more moving
parts to factor, and up until now there just wasn't any party seriously
interested in doing the user-facing parts.

..And so, I can't help but wonder.. what if the Stack authors would have
applied their expertise to provide the same user experience they
achieved..

..but with Nix as an underlying technology?

-- 
respectfully,
Косырев Серёга