singletons 2.5.1

This is the README file for the singletons library. This file contains all the
documentation for the definitions and functions in the library.

The singletons library was written by Richard Eisenberg, rae@cs.brynmawr.edu, and
with significant contributions by Jan Stolarek, jan.stolarek@p.lodz.pl. There
are two papers that describe the library. Original one, Dependently typed
programming with singletons, is available
here and will
be referenced in this documentation as the “singletons paper”. A follow-up
paper, Promoting Functions to Type Families in Haskell, is available
here
and will be referenced in this documentation as the
“promotion paper”.

Purpose of the singletons library

The library contains a definition of singleton types, which allow programmers
to use dependently typed techniques to enforce rich constraints among the types
in their programs. See the singletons paper for a more thorough introduction.

The package also allows promotion of term-level functions to type-level
equivalents. Accordingly, it exports a Prelude of promoted and singletonized
functions, mirroring functions and datatypes found in Prelude, Data.Bool,
Data.Maybe, Data.Either, Data.Tuple and Data.List. See the promotion
paper for a more thorough introduction.

This blog series,
authored by Justin Le, offers a tutorial for this library that assumes no
knowledge of dependent types.

Compatibility

The singletons library requires GHC 8.6.1 or greater. Any code that uses the
singleton generation primitives needs to enable a long list of GHC
extensions. This list includes, but is not necessarily limited to, the
following:

DataKinds

DefaultSignatures

EmptyCase

ExistentialQuantification

FlexibleContexts

FlexibleInstances

GADTs

InstanceSigs

KindSignatures

NoStarIsType

PolyKinds

RankNTypes

ScopedTypeVariables

StandaloneDeriving

TemplateHaskell

TypeFamilies

TypeOperators

UndecidableInstances

In particular, NoStarIsType is needed to use the * type family from the
PNum class because with StarIsType enabled, GHC thinks * is a synonym
for Type.

You may also want

-Wno-redundant-constraints

as the code that singletons generates uses redundant constraints, and there
seems to be no way, without a large library redesign, to avoid this.

Modules for singleton types

Data.Singletons exports all the basic singletons definitions. Import this
module if you are not using Template Haskell and wish only to define your
own singletons.

Data.Singletons.TH exports all the definitions needed to use the Template
Haskell code to generate new singletons.

Data.Singletons.Prelude re-exports Data.Singletons along with singleton
definitions for various Prelude types. This module provides a singletonized
equivalent of the real Prelude. Note that not all functions from original
Prelude could be turned into singletons.

Modules for function promotion

Data.Promotion.TH exports all the definitions needed to use the Template
Haskell code to generate promoted definitions.

Data.Promotion.Prelude and Data.Promotion.Prelude.* modules re-export all
promoted definitions from respective Data.Singletons.Prelude
modules. Data.Promotion.Prelude.List adds a significant amount of functions
that couldn’t be singletonized but can be promoted. Some functions still don’t
promote - these are documented in the source code of the module. There is also
Data.Promotion.Prelude.Bounded module that provides promoted PBounded
typeclass.

Functions to generate singletons

The top-level functions used to generate singletons are documented in the
Data.Singletons.TH module. The most common case is just calling singletons,
which I’ll describe here:

singletons :: Q [Dec] -> Q [Dec]

Generates singletons from the definitions given. Because singleton generation
requires promotion, this also promotes all of the definitions given to the
type level.

Definitions used to support singletons

Please refer to the singletons paper for a more in-depth explanation of these
definitions. Many of the definitions were developed in tandem with Iavor Diatchki.

data family Sing (a :: k)

The data family of singleton types. A new instance of this data family is
generated for every new singleton type.

class SingI (a :: k) where
sing :: Sing a

A class used to pass singleton values implicitly. The sing method produces
an explicit singleton value.

data SomeSing k where
SomeSing :: Sing (a :: k) -> SomeSing k

The SomeSing type wraps up an existentially-quantified singleton. Note that
the type parameter a does not appear in the SomeSing type. Thus, this type
can be used when you have a singleton, but you don’t know at compile time what
it will be. SomeSing Thing is isomorphic to Thing.

This class is used to convert a singleton value back to a value in the
original, unrefined ADT. The fromSing method converts, say, a
singleton Nat back to an ordinary Nat. The toSing method produces
an existentially-quantified singleton, wrapped up in a SomeSing.
The Demote associated
kind-indexed type family maps the kind Nat back to the type Nat.

Sometimes you have an explicit singleton (a Sing) where you need an implicit
one (a dictionary for SingI). The SingInstance type simply wraps a SingI
dictionary, and the singInstance function produces this dictionary from an
explicit singleton. The singInstance function runs in constant time, using
a little magic.

Equality classes

There are two different notions of equality applicable to singletons: Boolean
equality and propositional equality.

Boolean equality is implemented in the type family (:==) (which is actually
a synonym for the type family (==) from Data.Type.Equality) and the class
SEq. See the Data.Singletons.Prelude.Eq module for more information.

Propositional equality is implemented through the constraint (~), the type
(:~:), and the class SDecide. See modules Data.Type.Equality and
Data.Singletons.Decide for more information.

Which one do you need? That depends on your application. Boolean equality has
the advantage that your program can take action when two types do not equal,
while propositional equality has the advantage that GHC can use the equality
of types during type inference.

Instances of both SEq and SDecide are generated when singletons is called
on a datatype that has deriving Eq. You can also generate these instances
directly through functions exported from Data.Singletons.TH.

Show classes

Promoted and singled versions of the Show class (PShow and SShow,
respectively) are provided in the Data.Singletons.Prelude.Show module. In
addition, there is a ShowSing constraint synonym provided in the
Data.Singletons.ShowSing module:

type ShowSing k = (forall z. Show (Sing (z :: k))

This facilitates the ability to write Show instances for Sing instances.

What distinguishes all of these Shows? Let’s use the False constructor as
an example. If you used the PShow Bool instance, then the output of calling
Show_ on False is "False", much like the value-level Show Bool instance
(similarly for the SShow Bool instance). However, the Show (Sing (z :: Bool))
instance (i.e., ShowSing Bool) is intended for printing the value of the
singleton constructor SFalse, so calling show SFalse yields "SFalse".

Instance of PShow, SShow, and Show (for the singleton type) are generated
when singletons is called on a datatype that has deriving Show. You can also
generate these instances directly through functions exported from
Data.Singletons.TH.

A promoted and singled Show instance is provided for Symbol, but it is only
a crude approximation of the value-level Show instance for String. On the
value level, showing Strings escapes special characters (such as double
quotes), but implementing this requires pattern-matching on character literals,
something which is currently impossible at the type level. As a consequence, the
type-level Show instance for Symbols does not do any character escaping.

Errors

The singletons library provides two different ways to handle errors:

The Error type family, from Data.Singletons.TypeLits:

type family Error (str :: a) :: k where {}

This is simply an empty, closed type family, which means that it will fail
to reduce regardless of its input. The typical use case is giving it a
Symbol as an argument, so that something akin to
Error "This is an error message" appears in error messages.

The TypeError type family, from Data.Singletons.TypeError. This is a
drop-in replacement for TypeError from GHC.TypeLits which can be used
at both the type level and the value level (via the typeError function).

Unlike Error, TypeError will result in an actual compile-time error
message, which may be more desirable depending on the use case.

Pre-defined singletons

The singletons library defines a number of singleton types and functions
by default:

Bool

Maybe

Either

Ordering

()

tuples up to length 7

lists

These are all available through Data.Singletons.Prelude. Functions that
operate on these singletons are available from modules such as Data.Singletons.Bool
and Data.Singletons.Maybe.

Promoting functions

Function promotion allows to generate type-level equivalents of term-level
definitions. Almost all Haskell source constructs are supported – see last
section of this README for a full list.

Promoted definitions are usually generated by calling promote function:

Every promoted function and data constructor definition comes with a set of
so-called “symbols”. These are required to represent partial application at the
type level. Each function gets N+1 symbols, where N is the arity. Symbols
represent application of between 0 to N arguments. When calling any of the
promoted definitions it is important refer to it using their symbol
name. Moreover, there is new function application at the type level represented
by Apply type family. Symbol representing arity X can have X arguments passed
in using normal function application. All other parameters must be passed by
calling Apply.

Users also have access to Data.Promotion.Prelude and its submodules (Base,
Bool, Either, List, Maybe and Tuple). These provide promoted versions
of function found in GHC’s base library.

Note that GHC resolves variable names in Template Haskell quotes. You cannot
then use an undefined identifier in a quote, making idioms like this not
work:

type family Foo a where ...
$(promote [d| ... foo x ... |])

In this example, foo would be out of scope.

Refer to the promotion paper for more details on function promotion.

Classes and instances

This is best understood by example. Let’s look at a stripped down Ord:

Note that a singletonized class needs to use default signatures, because
type-checking the default body requires that the default associated type
family instance was used in the promoted class. The extra equality constraint
on the default signature asserts this fact to the type checker.

The only interesting bit here is the instance signature. It’s not necessary
in such a simple scenario, but more complicated functions need to refer to
scoped type variables, which the instance signature can bring into scope.
The defaults all just work.

On names

The singletons library has to produce new names for the new constructs it
generates. Here are some examples showing how this is done:

original datatype: Nat

promoted kind: Nat

singleton type: SNat (which is really a synonym for Sing)

original datatype: /\

promoted kind: /\

singleton type: %/\

original constructor: Succ

promoted type: 'Succ (you can use Succ when unambiguous)

singleton constructor: SSucc

symbols: SuccSym0, SuccSym1

original constructor: :+:

promoted type: ':+:

singleton constructor: :%+:

symbols: :+:@#@$, :+:@#@$$, :+:@#@$$$

original value: pred

promoted type: Pred

singleton value: sPred

symbols: PredSym0, PredSym1

original value: +

promoted type: +

singleton value: %+

symbols: +@#@$, +@#@$$, +@#@$$$

original class: Num

promoted class: PNum

singleton class: SNum

original class: ~>

promoted class: #~>

singleton class: %~>

Special names

There are some special cases, listed below (with asterisks* denoting special
treatment):

original datatype: []

promoted kind: []

singleton type*: SList

original constructor: []

promoted type: '[]

singleton constructor*: SNil

symbols*: NilSym0

original constructor: :

promoted type: ':

singleton constructor*: SCons

symbols: :@#@$, :@#@$$, :@#@$$$

original datatype: (,)

promoted kind: (,)

singleton type*: STuple2

original constructor: (,)

promoted type: '(,)

singleton constructor*: STuple2

symbols*: Tuple2Sym0, Tuple2Sym1, Tuple2Sym2

All tuples (including the 0-tuple, unit) are treated similarly.

original value: (.)

promoted type*: (:.)

singleton value: (%.)

symbols: (.@#@$), (.@#@$$), (.@#@$$$)

The promoted type is special because GHC can’t parse a type named (.).

original value: (!)

promoted type*: (:!)

singleton value: (%!)

symbols: (!@#@$), (!@#@$$), (!@#@$$$)

The promoted type is special because GHC can’t parse a type named (!).

original value: ___foo

promoted type*: US___foo (”US” stands for “underscore”)

singleton value*: ___sfoo

symbols*: US___fooSym0

All functions that begin with leading underscores are treated similarly.

Supported Haskell constructs

The following constructs are fully supported:

variables

tuples

constructors

if statements

infix expressions and types

_ patterns

aliased patterns

lists (including list comprehensions)

do-notation

sections

undefined

error

deriving Eq, Ord, Show, Bounded, Enum, Functor, Foldable, and
Traversable, as well as the stock and anyclass deriving strategies

Higher-kinded type variables in class/data declarations must be annotated
explicitly. This is due to GHC’s handling of complete
user-specified kind signatures, or CUSKs.
Briefly, singletons has a hard
time conforming to the precise rules that GHC imposes around CUSKs and so
needs a little help around kind inference here. See
this pull request for more
background.

singletons is slightly more conservative with respect to deriving than GHC is.
The stock classes listed above (Eq, Ord, Show, Bounded, Enum, Functor,
Foldable, and Traversable) are the only ones that singletons will derive
without an explicit deriving strategy. To do anything more exotic, one must
explicitly indicate one’s intentions by using the DerivingStrategies extension.

singletons fully supports the anyclass strategy as well as the stock strategy
(at least, for the classes listed above). singletons does not support the
newtype strategy, as there is not an equivalent of coerce at the type level.

singletons has partial support for arithmetic sequences (which desugar to
methods from the Enum class under the hood). Finite sequences (e.g.,
[0..42]) are fully supported. However, infinite sequences (e.g., [0..]),
which desugar to calls to enumFromTo or enumFromThenTo, are not supported,
as these would require using infinite lists at the type level.

The following constructs are supported for promotion but not singleton generation:

datatypes with constructors which have contexts. For example, the following
datatype does not singletonize:

data T a where
MkT :: Show a => a -> T a

Constructors like these do not interact well with the current design of the
SingKind class. But see
this bug report, which
proposes a redesign for SingKind (in a future version of GHC with certain
bugfixes) which could permit constructors with equality constraints.

overlapping patterns. Note that overlapping patterns are
sometimes not obvious. For example, the filter function does not
singletonize due
to overlapping patterns:

Here, it is more evident that the catch-all pattern _ overlaps with the
one above it.

The following constructs are not supported:

datatypes that store arrows, Nat, or Symbol

literals (limited support)

Why are these out of reach?

As described in the promotion paper, promotion of datatypes that store arrows is
currently impossible. So if you have a declaration such as

data Foo = Bar (Bool -> Maybe Bool)

you will quickly run into errors.

Literals are problematic because we rely on GHC’s built-in support, which
currently is limited. Functions that operate on strings will not work because
type level strings are no longer considered lists of characters. Function
working on integer literals can be promoted by rewriting them to use
Nat. Since Nat does not exist at the term level it will only be possible to
use the promoted definition, but not the original, term-level one.

This is the same line of reasoning that forbids the use of Nat or Symbol
in datatype definitions. But, see this bug
report for a workaround.

Support for *

The built-in Haskell promotion mechanism does not yet have a full story around
the kind * (the kind of types that have values). Ideally, promoting some form
of TypeRep would yield *, but the implementation of TypeRep would have to be
updated for this to really work out. In the meantime, users who wish to
experiment with this feature have two options:

The module Data.Singletons.TypeRepTYPE has all the definitions possible for
making * the promoted version of TypeRep, as TypeRep is currently implemented.
The singleton associated with TypeRep has one constructor:

(Recall that type * = TYPE LiftedRep.) Thus, a TypeRep is stored in the
singleton constructor. However, any datatypes that store TypeReps will not
generally work as expected; the built-in promotion mechanism will not promote
TypeRep to *.

The module Data.Singletons.CustomStar allows the programmer to define a subset
of types with which to work. See the Haddock documentation for the function
singletonStar for more info.

Known bugs

Record updates don’t singletonize

Inference dependent on functional dependencies is unpredictably bad. The
problem is that a use of an associated type family tied to a class with
fundeps doesn’t provoke the fundep to kick in. This is GHC’s problem, in
the end.

Singled code that contains uses type families is likely to fail due to GHC
Trac #12564. Note that singling type family declarations themselves is fine
(and often desired, since that produces defunctionalization symbols for them).

Singling instances of poly-kinded type classes is likely to fail due to
#358.
However, one can often work around the issue by using InstanceSigs. For
instance, the following code will not single:

Adding a type signature for method in the C [] is sufficient
to work around the issue, though:

instance C [] where
method :: [a]
method = []

Changes

Changelog for singletons project

2.5.1

ShowSing is now a type class (with a single instance) instead of a type
synonym. This was changed because defining ShowSing as a type synonym
prevents it from working well with recursive types due to an unfortunate GHC
bug. For more information, see
issue #371.

Add an IsString instance for SomeSing.

2.5

The Data.Promotion.Prelude.* namespace has been removed. Use the
corresponding modules in the Data.Singletons.Prelude.* namespace instead.

Fix a regression in which certain infix type families, such as (++), ($),
(+), and others, did not have the correct fixities.

The default implementation of the (==) type in PEq was changed from
(Data.Type.Equality.==) to a custom type family, DefaultEq. The reason
for this change is that (Data.Type.Equality.==) is unable to conclude that
a == a reduces to True for any a. (As a result, the previous version of
singletons regressed in terms of type inference for the PEq instances
for Nat and Symbol, which used that default.) On the other hand,
DefaultEq a adoes reduce to True for all a.

Add Enum Nat, Show Nat, and Show Symbol instances to
Data.Singletons.TypeLits.

Template Haskell-generated code may require DataKinds and PolyKinds in
scenarios which did not previously require it:

singletons now explicitly quantifies all kind variables used in explicit
foralls.

Since th-desugar now desugars all data types to GADT syntax, Template
Haskell-generated code may require GADTs in situations that didn’t require
it before.

Overhaul the way derived Show instances for singleton types works. Before,
there was an awkward ShowSing class (which was essentially a cargo-culted
version of Show specialized for Sing) that one had to create instances
for separately. Now that GHC has QuantifiedConstraints, we can scrap this
whole class and turn ShowSing into a simple type synonym:

type ShowSing k = forall z. Show (Sing (z :: k))

Now, instead of generating a hand-written ShowSing and Show instance for
each singleton type, we only generate a single (derived!) Show instance.
As a result of this change, you will likely need to enable
QuantifiedConstraints and StandaloneDeriving if you single any derived
Show instances in your code.

The kind of the type parameter to SingI is no longer specified. This only
affects you if you were using the sing method with TypeApplications. For
instance, if you were using sing @Bool @True before, then you will now need
to now use sing @Bool instead.

singletons now generates SingI instances for defunctionalization symbols
through Template Haskell. As a result, you may need to enable
FlexibleInstances in more places.

genDefunSymbols is now more robust with respect to types that use
dependent quantification, such as:

Rename Data.Singletons.TypeRepStar to Data.Singletons.TypeRepTYPE, and
generalize the Sing :: Type -> Type instance to Sing :: TYPE rep -> Type,
allowing it to work over more open kinds. Also rename SomeTypeRepStar to
SomeTypeRepTYPE, and change its definition accordingly.

Promoting or singling a type synonym or type family declaration now produces
defunctionalization symbols for it. (Previously, promoting or singling a type
synonym did nothing whatsoever, and promoting or singling a type family
produced an error.)

singletons now produces fixity declarations for defunctionalization
symbols when appropriate.

Add (%<=?), a singled version of (<=?) from GHC.TypeNats, as well as
defunctionalization symbols for (<=?), to Data.Singletons.TypeLits.

Add Data.Singletons.Prelude.{Semigroup,Monoid}, which define
promoted and singled versions of the Semigroup and Monoid type classes,
as well as various newtype modifiers.

Symbol is now has promoted Semigroup and Monoid instances as well.
As a consequence, Data.Singletons.TypeLits no longer exports (<>) or
(%<>), as they are superseded by the corresponding methods from
PSemigroup and SSemigroup.

Add promoted and singled versions of the Functor, Foldable,
Traversable, Applicative, Alternative, Monad, MonadPlus, and
MonadZip classes. Among other things, this grants the ability to promote
or single do-notation and list comprehensions.

Data.Singletons.Prelude.List now reexports more general
Foldable/Traversable functions wherever possible, just as Data.List
does.

Add Data.Singletons.Prelude.{Const,Identity}, which define
promoted and singled version of the Const and Identity data types,
respectively.

Promote and single the Down newtype in Data.Singletons.Prelude.Ord.

To match the base library, the promoted/singled versions of comparing
and thenCmp are no longer exported from Data.Singletons.Prelude. (They
continue to live in Data.Singletons.Prelude.Ord.)

Permit singling of expression and pattern signatures.

Permit promotion and singling of InstanceSigs.

sError and sUndefined now have HasCallStack constraints, like their
counterparts error and undefined. The promoted and singled counterparts
to errorWithoutStackTrace have also been added in case you do not want
this behavior.

Add Data.Singletons.TypeError, which provides a drop-in replacement for
GHC.TypeLits.TypeError which can be used at both the value- and type-level.

2.4.1

Restore the TyCon1, TyCon2, etc. types. It turns out that the new
TyCon doesn’t work with kind-polymorphic tycons.

2.4

Require GHC 8.4.

Demote Nat is now Natural (from Numeric.Natural) instead of Integer.
In accordance with this change, Data.Singletons.TypeLits now exposes
GHC.TypeNats.natVal (which returns a Natural) instead of
GHC.TypeLits.natVal (which returns an Integer).

The naming conventions for infix identifiers (e.g., (&*)) have been overhauled.

Infix functions (that are not constructors) are no longer prepended with a
colon when promoted to type families. For instance, the promoted version of
(&*) is now called (&*) as well, instead of (:&*) as before.

There is one exception to this rule: the (.) function, which is promoted
as (:.). The reason is that one cannot write (.) at the type level.

Singletons for infix functions are now always prepended with % instead of %:.

Singletons for infix classes are now always prepended with % instead of :%.

Singletons for infix datatypes are now always prepended with a %.

(Before, there was an unspoken requirement that singling an infix datatype
required that name to begin with a colon, and the singleton type would begin
with :%. But now that infix datatype names can be things like (+), this
requirement became obsolete.)

The upshot is that most infix names can now be promoted using the same name, and
singled by simply prepending the name with %.

The suffix for defunctionalized names of symbolic functions (e.g., (+)) has
changed. Before, the promoted type name would be suffixed with some number of
dollar signs (e.g., (+$) and (+$$)) to indicate defunctionalization
symbols. Now, the promoted type name is first suffixed with @#@ and
then followed by dollar signs (e.g., (+@#@$) and (+@#@$$)).
Adopting this conventional eliminates naming conflicts that could arise for
functions that consisted of solely $ symbols.

The treatment of undefined is less magical. Before, all uses of undefined
would be promoted to GHC.Exts.Any and singled to undefined. Now, there is
a proper Undefined type family and sUndefined singleton function.

As a consequence of not promoting undefined to Any, there is no need to
have a special any_ function to distinguish the function on lists. The
corresponding promoted type, singleton function, and defunctionalization
symbols are now named Any, sAny, and AnySym{0,1,2}.

Derived SDecide instances for empty data types now return Proved bottom,
where bottom is a divergent computation, instead of erroring.

Add Data.Singletons.Prelude.IsString and Data.Promotion.Prelude.IsString
modules. IsString.fromString is now used when promoting or singling
string literals when the -XOverloadedStrings extension is enabled
(similarly to how Num.fromInteger is currently used when promoting or
singling numeric literals).

Add Data.Singletons.Prelude.Void.

Add promoted and singled versions of div, mod, divMod, quot, rem,
and quotRem to Data.Singletons.TypeLits that utilize the efficient Div
and Mod type families from GHC.TypeNats. Also add sLog2 and
defunctionalization symbols for Log2 from GHC.TypeNats.

Add (<>) and (%<>), the promoted and singled versions of AppendSymbol
from GHC.TypeLits.

Add (%^), the singleton version of GHC.TypeLits.^.

Add unlines and unwords to Data.Singletons.Prelude.List.

Add promoted and singled versions of Show, including deriving support.

Add a ShowSing class, which facilitates the ability to write Show instances
for Sing instances.

Aside from cleaning up some implementation details, this change assures
that toSing can only be called on TypeReps whose kind is of kind *.
The previous implementation did not enforce this, which could lead to
segfaults if used carelessly.

Instead of erroring, the toSing implementation in the SingKind (k1 ~> k2)
instance now works as one would expect (provided the user adheres to some
common-sense SingKind laws, which are now documented).

Add a demote function, which is a convenient shorthand for fromSing sing.

2.3

Demote was no longer a convenient way of calling DemoteRep and has been
removed. DemoteRep has been renamed Demote.

DemoteRep is now injective.

Demoting a Symbol now gives Text. This is motivated by making DemoteRep
injective. (If Symbol demoted to String, then there would be a conflict
between demoting [Char] and Symbol.)

Generating singletons also now generates fixity declarations for the singletonized
definitions, thanks to @int-index.

Though more an implementation detail: singletons no longer uses kind-level proxies anywhere,
thanks again to @int-index.

Support for promoting higher-kinded type variables, thanks for @int-index.

Data.Singletons.TypeLits now exports defunctionalization symbols for KnownNat
and KnownSymbol.

Better type inference support around constraints, as tracked in Issue #176.

Type synonym definitions are now ignored, as they should be.

Show instances for SNat and SSymbol, thanks to @cumber.

The singFun and unSingFun functions no longer use proxies, preferring
TypeApplications.

2.2

With TypeInType, we no longer kind KProxy. @int-index has very helpfully
removed the use of KProxy from singletons.

Drop support for GHC 7.x.

Remove bugInGHC. That function was intended to work around GHC’s difficulty
in detecting exhaustiveness of GADT pattern matches. GHC 8 comes with a much
better exhaustiveness checker, and so this function is no longer necessary.

2.1

Require th-desugar >= 1.6

Work with GHC 8. GHC 8 gives the opportunity to simplify some pieces of
singletons, but these opportunities are not yet fully realized. For example,
injective type families means that we no longer need Sing to be a data
family; it could be a type family. This might drastically simplify the way
functions are singletonized. But not yet!

singletons now outputs a few more type/kind annotations to help GHC do
type inference. There may be a few more programs accepted than before.
(This is the fix for #136.)

2.0.0.1

2.0

We now have promoted and singletonized versions of Enum, as well as Bounded.

Deriving Enum is also now supported.

Ditto for Num, which includes an instance for Nat, naturally.

Promoting a literal number now uses overloaded literals at the type level,
using a type-level FromInteger in the type-level Num class.

Better support for dealing with constraints. Some previously-unsingletonizable
functions that have constrained parameters now work.

No more orphan Quasi instances!

Support for functions of arity 8 (instead of the old limit, 7).

Full support for fixity declarations.

A raft of bugfixes.

Drop support for GHC 7.8. You must have GHC 7.10.2.

1.1.2.1

Fix bug #116, thus allowing locally-declared symbols to be used in GHC 7.10.

1.1.2

No more GHC 7.8.2 support – you must have GHC 7.8.3.

1.1.1

Update testsuite to work with th-desugar-1.5.2. No functional changes.

1.1

This is a maintenance release to support building (but not testing, due to
GHC bug #10058) with 7.10. This release also targets th-desugar-1.5. Some
types changed (using th-desugar’s new DsMonad instead of Quasi), but
clients generally won’t need to make any changes, unless they, too, generalize
over Quasi.

1.0

This is a complete rewrite of the package.

A much wider array of surface syntax is now accepted for promotion
and singletonization, including let, case, partially-applied functions,
and anonymous functions, where, sections, among others.

Classes and instances can be promoted (but not singletonized).

Derivation of promoted instances for Ord and Bounded.

This release can be seen as a “technology preview”. More features are coming
soon.

This version drops GHC 7.6 support.

0.10.0

Template Haskell names are now more hygienic. In other words, singletons
won’t try to gobble up something happened to be named Sing in your project.
(Note that the Template Haskell names are not completely hygienic; names
generated during singleton generation can still cause conflicts.)

If a function to be promoted or singletonized is missing a type signature,
that is now an error, not a warning.

Added a new external module Data.Singletons.TypeLits, which contain the
singletons for GHC.TypeLits. Some convenience functions are also provided.

The extension EmptyCase is no longer needed. This caused pain when trying
to support both GHC 7.6.3 and 7.8.

0.9.3

Fix export list of Data.Singletons.TH, again again.

Add SEq instances for Nat and Symbol.

0.9.2

Fix export list of Data.Singletons.TH, again.

0.9.1

Fix export list of Data.Singletons.TH.

0.9.0

Make compatible with GHC HEAD, but HEAD reports core lint errors sometimes.

Change module structure significantly. If you want to derive your own
singletons, you should import Data.Singletons.TH. The module
Data.Singletons now exports functions only for the use of singletons.

New modules Data.Singletons.Bool, ...Maybe, ...Either, and ...List
are just like their equivalents from Data., except for List, which is
quite lacking in features.

For singleton equality, use Data.Singletons.Eq.

For propositional singleton equality, use Data.Singletons.Decide.

New module Data.Singletons.Prelude is meant to mirror the Haskell Prelude,
but with singleton definitions.

Streamline representation of singletons, resulting in exponential speedup
at execution. (This has not been rigorously measured, but the data structures
are now exponentially smaller.)

Add internal support for TypeLits, because the TypeLits module no longer
exports singleton definitions.

Add support for existential singletons, through the toSing method of
SingKind.

Remove the SingE class, bundling its functionality into SingKind.
Thus, the SingRep synonym has also been removed.

Name change: KindIs becomes KProxy.

Add support for singletonizing calls to error.

Add support for singletonizing empty data definitions.

0.8.6

Make compatible with GHC HEAD, but HEAD reports core lint errors sometimes.

0.8.5

Bug fix to make singletons compatible with GHC 7.6.1.

Added git info to cabal file.

0.8.4

Update to work with latest version of GHC (7.7.20130114).

Now use branched type family instances to allow for promotion of functions
with overlapping patterns.

Permit promotion of functions with constraints by omitting constraints.

0.8.3

Update to work with latest version of GHC (7.7.20121031).

Removed use of Any to simulate kind classes; now using KindOf and OfKind
from GHC.TypeLits.

Made compatible with GHC.TypeLits.

0.8.2

Added this changelog

Update to work with latest version of GHC (7.6.1). (There was a change to
Template Haskell).

Moved library into Data.Singletons.

0.8.1

Update to work with latest version of GHC. (There was a change to
Template Haskell).