#1965: Allow unconstrained existential contexts in newtypes
-------------------------------+--------------------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.1
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
-------------------------------+--------------------------------------------
Changes (by mokus):
* cc: mokus@… (added)
Comment:
I also have run into cases where I'd like to make a "trivial" GADT into a
newtype. In particular, when programming in a "dependent"-like style
using GADTs to encode the tags of dependent sums, it's often nice to have
a wrapper that does nothing but alter the type index - a very general
example would be "data Map f t a where Map :: t a -> Map f t (f a)" -
which allows transforming the last type parameter by an arbitrary type-
level function. Most of the time this usage could be avoided by including
'f' in the dependent sum type itself, but that complicates other things
and even then I've found you occasionally want to modify the types of
tags.
Another situation where I've wanted something like this to forget a
phantom type - and I've seen the same pattern in other people's code I've
read on hackage.
There is a different possible resolution to this request, which would
probably be more work but not break portability - guarantee that any
"data" declaration satisfying certain criteria will be compiled to a
newtype-like representation. Here's my stab at that set of criteria:
1. Only one constructor
2. Only one field with nonzero width in that constructor (counting
constraints as fields)
3. That field is marked strict
It seems like those requirements should be sufficient to justify special-
case handling to compile them to something effectively the same as a
newtype. Or if some mechanism already causes this to effectively by the
case, then I'd be happy with that being documented and test-cases added to
ensure it continues to be a stated goal to cover situations like these.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1965#comment:7>
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
