Yes, I agree at inclusion in base. I opted for this solution, as it allows me to test it in anger at my daily work at Erudify. If we're going to add more strict modules to base, then I'd do it in a two step process.

1. Include strict versions of core types, i.e., the modules from strict-base-types.
2. Include strict versions of functions, i.e., the additional modules from `strict`, `strict-io`, etc.

We could already solve Number 1. for GHC 7.8. It's just a matter of preparing the patches. I would be willing to prepare them in a month or two, if that's still sufficient for GHC 7.8. Then, I should have had to time to test my `strict-base-types` package in practice.

best regards,
Simon


2013/5/8 Johan Tibell <johan.tibell@gmail.com>
On Wed, May 8, 2013 at 11:01 AM, Bas van Dijk <v.dijk.bas@gmail.com> wrote:
> Good stuff Simon!
>
> It would be great if either strict-base-types, strict or a merger of
> the two will find its way into the Haskell Platform. Even better if it
> also merged with strict-concurrency and strict-io so that we have one
> go-to package for strict types and operations.

For what it's worth, I think we need Data.Maybe.Strict,
Data.Tuple.Strict, and Data.Either.Strict in base. Only then will they
be accessible enough that we can start using them in APIs in core
packages. This will also make it easier to provide type class
instances (e.g. Binary) for them without creating odd package
dependencies (or packages that depends on everything under the sub).

-- Johan