yoko-0.1: yoko.cabal

name: yoko
version: 0.1
synopsis: generic programming with disbanded constructors 

description: @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
  /constructor 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 @intant-generics@ with
  support for constructor-centric generic programming. The @Examples/LL.hs@
  file distributed with the @yoko@ source demonstrates defining a
  lambda-lifting conversion between the two types @Inner@, which has lambdas,
  and @Prog@, which has top-level function declarations instead.
  .
  @
    data Inner = Lam Type Inner | Var Int | App Inner Inner
  .
    data Term = Var Int | App Term Term | DVar Int
    data Prog = Prog ([Type], Type, Term) Term
  @
  .
  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 @Inner@'s @App@
  to @Term@'s @App@. As written, the generic lambda-lifter would continue to
  work for any new @Inner@ constructors (e.g. syntax for tuples or mutable
  references) as long as constructors with the same names and analogous fields
  were added to @Term@ and the semantics of those constructors doesn't involve
  binding. This default behavior of the lambda-lifter is specified in about ten
  lines of user code.
  .
  Existing generic libraries don't use constructor names to the degree that
  @yoko@ does, and so cannot accomodate generic /conversions/ nearly 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, Examples/*.hs



library
  build-depends: base >= 4 && < 5
  build-depends: type-equality < 0.2, tagged >= 0.2 && < 0.3

  build-depends: type-booleans < 0.2, type-spine < 0.2, tagged-th < 0.2,
    type-digits < 0.2, type-cereal < 0.2, type-ord < 0.2, type-ord-spine-cereal
    < 0.2

  exposed-modules: Type.Yoko,
                   Type.Yoko.Type,
                   Type.Yoko.Universe,
                   Type.Yoko.Natural,
                   Type.Yoko.Sum,
                   Type.Yoko.BTree,
                   Type.Yoko.TSTSS,
                   Type.Yoko.Fun,
                   Type.Yoko.FunA,
                   Type.Yoko.MFun,
                   Type.Yoko.TFunA,

                   Data.Yoko,
                   Data.Yoko.Core,
                   Data.Yoko.CoreTypes,
                   Data.Yoko.Generic,
                   Data.Yoko.ReflectBase,
                   Data.Yoko.Reflect,
                   Data.Yoko.InDT,
                   Data.Yoko.Reduce,
                   Data.Yoko.Algebra

--                   Examples.TermBase,
--                   Examples.TermGeneric,
--                   Examples.InnerBase,
--                   Examples.InnerGeneric,
--                   Examples.TermInner