Changes between Version 3 and Version 4 of NewtypeWrappers
 Timestamp:
 Jan 15, 2013 11:20:46 AM (3 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

NewtypeWrappers
v3 v4 41 41 * For `x3`, we'd have to map over `T`, thus `mapT MkAge x3`. But what if `mapT` didn't exist? We'd have to make it. And not all data types have maps. `S` is a harder one: you could only map over Svalues if `m` was a functor. There's a lot of discussion abou this on #2110. 42 42 43 == The proposal==43 == The opportunity == 44 44 45 45 Clearly what we want is a way to "lift" newtype constructors (and dually deconstructors) … … 64 64 }}} 65 65 66 So all we need is concrete syntax to allow you to ask for these lifed coercions in Haskell. I couldn't think of a good way to do this, but now I have a proposal: 66 So all we need is concrete syntax to allow you to ask for these lifed coercions in Haskell. 67 68 == Proposal 1 == 69 70 The first possiblity involves a new toplevel declaration: 67 71 {{{ 68 72 newtype wrap w1 :: [Int] > [Age]) … … 97 101 newtype wrap foo :: (Int > Int) > Fun Age 98 102 }}} 103 104 == Proposal 2 == 105 106 The second possibility is superficially simpler: just provided a new builtin constant with type 107 {{{ 108 newtypeCast :: NTC a b => a > b 109 }}} 110 Here `NTC` is a builtin type class that witnesses the (free) conversion between `a` and `b`. Although it would not quite be implemented like this, we would have a builtin instance for each data type (but see Type Soundness below): 111 {{{ 112 instance NTC a b => NTC [a] [b] 113 }}} 114 and two builtin instances for each newtype: 115 {{{ 116 instance NTC Int b => NTC Age b 117 instance NTC a Int => NTC a Age 118 }}} 119 So to solve a `NTC` constraint you unwwap all those newtypes (being careful about abstraction; see next section). 120 121 This plan requires a bit more paddling under the water on GHC's part, especially during type inference, but it looks a lot more straightforward than I first thought. Thanks to Roman Cheplyka for advocating this solution. 99 122 100 123 == Abstraction == … … 139 162 data Map a b = MkMap (InternalMap a b) 140 163 }}} 141 it's no goodbeing able to see the data constructor `MkMap`; you need to164 It's no good just being able to see the data constructor `MkMap`; you need to 142 165 see the constructors of `InternalMap` too. 143 166 … … 165 188 }}} 166 189 The problem is, as usual, the type function hiding inside T's definition. 167 The solution is described in [http://research.microsoft.com/enus/um/people/simonpj/papers/extf/ 168 Generative type abstraction and typelevel computation]. It is still not implemented, alas, 190 The solution is described in [http://research.microsoft.com/enus/um/people/simonpj/papers/extf/ Generative type abstraction and typelevel computation]. It is still not implemented, alas, 169 191 but adding the newtype wrappers introduces no problems that we do not already have. 170 192