[Haskell] ANN: strict-base-types-0.1

Simon Meier iridcode at gmail.com
Sat May 11 16:36:44 CEST 2013


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 at gmail.com>

> On Wed, May 8, 2013 at 11:01 AM, Bas van Dijk <v.dijk.bas at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell/attachments/20130511/f76b8326/attachment.htm>


More information about the Haskell mailing list