ANN: strict-base-types-0.1
Dear fellow haskellers, the strict-base-types package makes it easy to get rid of the unnecessary laziness (and the resulting space leaks) in your applications; i.e., no more data AppState = AppState { _field :: !(Maybe T.Text) , ... } as the alternative import qualified Data.Maybe.Strict as S data AppState = AppState { _field :: !(S.Maybe T.Text) , ... } is now equally cheap. See http://hackage.haskell.org/package/strict-base-types-0.1 for a full explanation of the functionality provided by this package. happy hacking, Simon
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. Cheers, Bas On 8 May 2013 13:40, Simon Meier <iridcode@gmail.com> wrote:
Dear fellow haskellers,
the strict-base-types package makes it easy to get rid of the unnecessary laziness (and the resulting space leaks) in your applications; i.e., no more
data AppState = AppState { _field :: !(Maybe T.Text) , ... }
as the alternative
import qualified Data.Maybe.Strict as S data AppState = AppState { _field :: !(S.Maybe T.Text) , ... }
is now equally cheap.
See http://hackage.haskell.org/package/strict-base-types-0.1 for a full explanation of the functionality provided by this package.
happy hacking, Simon
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
Johan Tibell wrote:
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).
+1 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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
participants (4)
-
Bas van Dijk -
Erik de Castro Lopo -
Johan Tibell -
Simon Meier