Currently, FT is implemented closely in the MeteorCounter app. It should be somehow reworked and turned into a framework to enable its usage without reinventing the stuff.
There are modules FTL and FTLI but these modules are not quite about Final Tagless.
-- Flaws of FT
-- - BL depends on Runtime
-- - BL and implementation works in the same Runtime
-- - Implementation details leak into BL through type classes
-- (see logger type classes with additional type variables)
-- - Advanced language features (type classes + Type Families)
-- - Single runtime for all language interpreters
-- - Implicit type class instances (not values)
-- -
newtype AppM a = AppM { runAppM :: ReaderT R.CoreRuntime IO a }
deriving (Functor, Applicative, Monad, L.ControlFlowL, L.LoggerL, L.RandomL, L.ProcessL)
class
( L.StateL (L.Transaction m)
, L.Atomic m
, L.LoggerL m
, L.RandomL m
, L.ControlFlowL m
, L.ProcessL m
) => Lang m
instance Lang AppM
instance L.Atomic AppM where
type Transaction AppM = STM
transaction = AppM . atomically
Currently, FT is implemented closely in the
MeteorCounter
app. It should be somehow reworked and turned into a framework to enable its usage without reinventing the stuff.There are modules
FTL
andFTLI
but these modules are not quite about Final Tagless.In app/MeteorCounter/FTL.hs: