#1894: Add a total order on type constructors
----------------------------------------+-----------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: low | Milestone: 7.4.1
Component: Compiler (Type checker) | Version: 6.8.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
----------------------------------------+-----------------------------------
Changes (by nfrisby):
* failure: => None/Unknown
Comment:
Summary: I think type-level digits/numerals and a type-level reflection of
the globally unique-name as a type-level numeral would subsume the
proposed functionality.
(This ticket seems quite stale — has there been any more decisions
regarding this?)
If the ordering can be arbitrary, I think type-level serializations fit
the bill. I chose to "serialize" the types as their global names, so the
order of compilation shouldn't matter — everything is based on GUIDs. (I
don't think this address Reinke's program logic concerns.)
For the details, see my Hackage packages type-cereal, type-ord, and type-
ord-spine-cereal which rely on type-spine and type-digits.
* type-digits declares a fixed set of type-level digits (* -> *,
terminated with ()) and means to build numerals from them
* type-ord declares LabelCMP (as Compare) with instances for each pair of
those digits and ((), ())
* type-cereal declares a type family Serialize and a (TH) function for
representing bytestrings as type-level numerals (to hijack the cereal
package's serialization)
* type-spine declares a type-level "spine-view"
* type-ord-spine-cereal declares "generic" LabelCMP instances using the
spine-view to reduce all (spine-view-enabled) types to applications of
serializable names and then uses the type-digits' LabelCMP instances and a
"lexicographic" instance for type-level applications
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1894#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
