parsonsmatt

Someone asked whether or not acid-state was production ready. I shared my experiences:

parsonsmatt [11:32 AM] @nikolap it's used by cardano-wallet and Hackage. Based on my experience with acid-state, I'd say it is not a good choice for production data storage. For local desktop apps, SQLite is a much better choice, and for real production apps, Postgresql is king.

parsonsmatt [11:44 AM] acid-state did not have a test suite, at all, until I implemented the very first tests (for TemplateHaskell code generation) earlier this year. It has picked up some tests since then, but I'm still not confident in it's correctness.

It claims to be resilient to unplugging the power cord, but I doubt that, as it's not resilient to Ctrl-C: acid-state/acid-state#79

parsonsmatt

Version 1.8.0, Git revision 18c83fffb10931da3357d8d5e17138c2fefa88b3 x86_64 hpack-0.28.2
2018-06-21 16:40:51.857781: [debug] Checking for project config at: /home/matt/Projects/cardano-sl/stack.yaml
@(src/Stack/Config.hs:853:9)
2018-06-21 16:40:51.857972: [debug] Loading project config file stack.yaml
@(src/Stack/Config.hs:879:13)
2018-06-21 16:40:51.861845: [debug] Decoding build plan from: /home/matt/.stack/build-plan/lts-11.13.yaml
@(src/Stack/Snapshot.hs:164:5)
2018-06-21 16:40:51.861930: [debug] Trying to decode /home/matt/.stack/build-plan-cache/lts-11.13.cache
@(src/Stack/Snapshot.hs:156:32)
2018-06-21 16:40:51.868020: [debug] Success decoding /home/matt/.stack/build-plan-cache/lts-11.13.cache

parsonsmatt

{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE GADTs #-}

{-# OPTIONS_GHC -Wall #-}

module Main where

parsonsmatt

{-# LANGUAGE ConstraintKinds       #-}
{-# LANGUAGE DeriveGeneric         #-}
{-# LANGUAGE FlexibleContexts      #-}
{-# LANGUAGE FlexibleInstances     #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE PartialTypeSignatures #-}
{-# LANGUAGE TemplateHaskell       #-}
{-# LANGUAGE TypeApplications      #-}
{-# LANGUAGE TypeFamilies          #-}

parsonsmatt

{-# LANGUAGE ExistentialQuantification #-}

data Adder = forall a. Adder
    { increment :: a -> a
    , render :: a -> String
    , value :: a
    }

main :: IO ()
main = do

parsonsmatt

```
λ> :set -XPolyKinds -XKindSignatures
λ> undefined :: forall (a :: ka) (b :: kb) (c :: k1 -> k2 -> *). c a b -> c b a

<interactive>:2:61: error:
    Illegal symbol '.' in type
    Perhaps you intended to use RankNTypes or a similar language
    extension to enable explicit-forall syntax: forall <tvs>. <type>
λ> :set -XRankNTypes
λ> undefined :: forall (a :: ka) (b :: kb) (c :: k1 -> k2 -> *). c a b -> c b a

parsonsmatt

Compile Time Literals

I've been kicking an idea around for revamping overloaded literals in Haskell. Please give a thought:

Right now we do runtime fromInteger, fromString, fromList, etc. calls. The types of these functions are Integer -> a, String -> a, etc. These functions are usually partial for more interesting types, and the failure typically occurs at runtime. I propose that we convert the literal at compile-time instead (potentially using quasiquotes), along with new classes that provide function compileLiteral :: literal -> Either String value.

The definition would look like this:

parsonsmatt

-- gross hack so i can lighten the syntax load
class NameOrEntityRef x where
    disambiguate :: x -> Either Name EntityRef

instance NameOrEntityRef Name where
    disambiguate = Left

instance NameOrEntityRef EntityRef where
    disambiguate = Right

parsonsmatt

-- Why use `mtl` constraints?
-- well, suppose you've got some tests using `MonadState`, but then that was a 
-- mistake, because of the way that Alternative's IO works:
-- you had state rollback! Oh no!
--
-- Fortunately, it is relatively easy to write a state instance that Just Works
-- with IO references, which preserves state across threads and exceptions.
-- And, with GeneralizedNewtypeDeriving, you get all the necessary instance 
-- boilerplate for free.
--

parsonsmatt

fpco decided to do their own thing instead of contributing to that effort.

Your timeline is way off. The initial announcement for what would become Stackage was posted in 2012, a full three years before the post you linked was authored (and a year before Cabal got sandboxes!). The proposal blog post doesn't even mention diverging from cabal at all, and the official way to use stackage was through cabal sandboxes. The first public beta of stack was announced in June 2015, and according to the blog post, FPCo had been working on stack internally for about a year before that. If these timelines are to be believed, then stack was six months into internal produ