name: yoko version: 2.0 synopsis: Generic Programming with Disbanded Data Types description: Based off of the paper \"A Pattern for Almost Homomorphic Functions\" at , presented at the Workshop on Generic Programming 2012. Also, my dissertation . @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 maintainer: Nicolas Frisby 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, semigroups build-depends: kinds >= 0.0.1.5, type-functions >= 0.2.0.3, records >= 0.1.1.6 build-depends: type-spine >= 0.2.0.20120924, 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.Invariant, Data.Yoko.TypeBasics, Data.Yoko.W, Data.Yoko.Prelude, Data.Yoko.MinCtors, Data.Yoko.MinCtors.Prims0, Data.Yoko.MinCtors.Prims1, Data.Yoko.MinCtors.Minima, Data.Yoko.MinCtors.MMap other-modules: Data.Yoko.View, Data.Yoko.MaybeKind, Data.Yoko.Representation, Data.Yoko.TypeSums, Data.Yoko.TH.Internal