#2110: Rules to eliminate casted id's
---------------------------------+------------------------------------------
Reporter: igloo | Owner:
Type: feature request | Status: new
Priority: lowest | Milestone: 7.6.2
Component: Compiler | Version: 6.8.2
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by simonpj):
* cc: sweirich@… (added)
Comment:
Shocking it may be, but the question remains about how to fix it. Here
are the issues I see. (I'm assuming we don't want something that works
only for lists.)
* What (precisely) is a "map-like" function, for some arbitrary data
type? I'm not keen on spotting such things by somehow matching on their
particular form. Remember data types can be mutually recursive, and may
have several type parameters.
* We can reasonably lift casts for data types that ''don't'' have a map
function. For example, if we have
{{{
newtype Age = MkAge Int
data T a b = ..blah..blah...
}}}
Then the coercion `T coAge Bool :: T Int Bool ~ T Age Bool`, where
`coAge` is the coercion arising from the `Age` newtype, even if `T`
doesn't have a map function defined on its first type parameter. System
FC is great.
* But how should that be specified in the source program? Suppose `e ::
T Int Bool`. Then I have wondered about syntax like this:
{{{
newtype[T $MkAge Bool] e
}}}
Here the `newtype` says "here comes a newtype coercion". The bit in
square brackets specifies the coercion, in the form of a type with some
spot(s) replaced by a newtype data constructor, signalled by `$`, in this
case `MkAge`. So the degenerate case `newtype[$MkAge] e` would be
identical to `MkAge e`.
* You have to be careful NOT do to this if there is a type function
hiding inside T; see our paper [http://research.microsoft.com/en-
us/um/people/simonpj/papers/ext-f/ Generative type abstraction and type-
level computation]
I wonder if anyone has beter ideas for syntax?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2110#comment:19>
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
