yoko-0.9: yoko.cabal
name: yoko
version: 0.9
synopsis: Generic Programming with Disbanded Data Types
description:
Based off of the paper \"A Pattern for Almost Homomorphic Functions\"
at <http://www.ittc.ku.edu/~nfrisby/frisby-wgp-2012.pdf>, presented at the
Workshop on Generic Programming 2012. Also, my
dissertation <http://www.ittc.ku.edu/~nfrisby/frisby-dissertation.pdf>
.
@yoko@ views a nominal datatype as a /band/ of constructors, each
a nominal type in its own right. Such datatypes can be disbanded via the
@disband@ function into an anonymous sum of nominal constructors, and vice
versa via the @band@ function. This library uses extensive type-level
programming to enrich its @instant-generics@ foundation with capabilities
derived from the constructor-centric perspective.
.
For example, consider the following /nominal datatype/.
.
@
data Beatles = John ... | Paul ... | George ... | Ringo ...
@
.
This type can of course be understood as a sum of the individual
/fields types/.
.
@
data John = John ...
data Paul = Paul ...
data George = George ...
data Ringo = Ringo ...
@
.
@yoko@'s conceptual foundations start there. In particular, this allows a
constructor, say @John@, to be used independently of its original range type
and sibling constructors.
.
As a generic programming library, @yoko@ extends @instant-generics@ with
support for constructor-centric generic programming. The
@Examples\/LambdaLift\/LambdaLift.hs@ file distributed with the @yoko@ source
demonstrates defining a lambda-lifting conversion between the two types
@ULC@, which has lambdas, and @Prog@, which has top-level function
declarations instead.
.
@
data ULC = Lam Type ULC | Var Int | Let [Decl] ULC | App ULC ULC
.
data Decl = Decl Type ULC
.
.
.
data Prog = Prog [FunDec] TLF
type FunDec = ([Type], [Type], Type, TLF)
.
data TLF = Top Int [Occ] | Occ Occ | App TLF TLF
data Occ = Par Int | Env Int
@
.
These types are defined in separate modules, since they have constructors
with the same name. Indeed, the fact that they having matching constructors
named @App@ is crucial for @yoko@'s automatic conversion from @ULC@'s @App@
to @TLF@'s @App@. As written, the generic lambda-lifter would continue to
work for any new @ULC@ constructors (e.g. syntax for tuples or mutable
references) as long as constructors with the same names and analogous fields
were added to @TLF@ and the semantics of those constructors doesn't involve
binding. This default /generic/ behavior of the lambda-lifter is specified in
about ten lines of user code.
.
The non-generic code is much more complicated. This is intentional: I wanted
to show that sometimes shoehorning an algorithm into the requisite type (/ie/
@a -> m a'@) can be difficult and require subtleties like backwards state.
.
Existing generic libraries don't use constructor names to the degree that
@yoko@ does, and so cannot accomodate generic /conversions/ as well.
category: Generics, Reflection
license: BSD3
license-file: LICENSE
author: Nicolas Frisby <nicolas.frisby@gmail.com>
maintainer: Nicolas Frisby <nicolas.frisby@gmail.com>
stability: experimental
build-type: Simple
cabal-version: >= 1.6
extra-source-files: README, CHANGES, Examples/*.hs, Examples/LambdaLift/*.hs
source-repository head
type: git
location: git://github.com/nfrisby/yoko.git
library
build-depends: base >= 4 && < 5, template-haskell, containers, mtl
build-depends: th-sccs, invariant
build-depends: type-equality, bifunctors
build-depends: kinds >= 0.0.1.5, type-functions >= 0.2.0.3, records >= 0.1.1.6
build-depends:
type-spine >= 0.2, type-digits >= 0.2, type-cereal >= 0.2, type-ord >= 0.2, type-ord-spine-cereal >= 0.2
exposed-modules:
Data.Yoko,
Data.Yoko.SmartPreciseCase,
Data.YokoRaw, Data.Yoko.HCompos, Data.Yoko.TH,
Data.Yoko.TypeBasics, Data.Yoko.Each
other-modules:
Data.Yoko.View,
Data.Yoko.MaybeKind,
Data.Yoko.Representation,
Data.Yoko.TypeSums,
Data.Yoko.TH.Internal