Use a concrete monad in some places?

[mgsloan]

As pointed out by mrkkrp here, many functions with rather generic signatures could instead specify a concrete monad.

I'm thinking this could aid in clarity and probably run a little faster (though I doubt it'd make a substantial difference). While it's cool that you can tell which aspects of the reader environment a function depends on, we don't always use a minimal set of constraints, and there are no warnings for unnecessary constraints. In practice, I don't really find myself consulting the list much, I mostly ignore it.

[drwebb]

I kind of like the idea, though only for big important functions that aren't moving anywhere, e.g. Stack.Build.build. Which is such a bad offender in this respect it has it's own type synonym using constraint kinds. Though I don't know off the top of my head what the concrete signature would look like, some version of StackT?

For smaller functions I like the current setup, it means they can be shared and called in different contexts.

[sjakobi]

This (ongoing) discussion on r/haskell is pretty related.

While it's cool that you can tell which aspects of the reader environment a function depends on, we don't always use a minimal set of constraints, and there are no warnings for unnecessary constraints.

This has changed now with GHC-8's redundant constraint warnings

[snoyberg]

There are two aspects to this that I see:

1. Which concrete monad transformer we're using, and its underlying base monad. Once we're dealing with StackM or StackMiniM, I see no advantage of using the constraints on the monad versus concretely using StackT.
2. Which environment we're using. I think we do still get some benefit from using constraints on the environment.

The general refactorings I've been doing are naturally encroaching on this, so I'll likely open a PR after the Stack.Prelude change is merged in.