Changes between Version 8 and Version 9 of NewtypeWrappers


Ignore:
Timestamp:
Jul 3, 2013 7:58:12 AM (20 months ago)
Author:
nomeata
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NewtypeWrappers

    v8 v9  
    206206{{{ 
    207207deriving nt :: NT N T 
    208 deriving list :: NT a b -> NT [a] [b] 
     208deriving listNT :: NT a b -> NT [a] [b] 
    209209}}} 
    210210 
    211211The compiler either rejects the declaration or creates an implementation automatically. It should only create an implementation if a non-zero-cost-implementation could be written by the user instead. (I expect that this means that the constructors of the return type are in scope.) 
     212 
     213The “could you write it by hand” criteria implies that the expected arguments for the nt value depends on how they type parameters are used in the data constructors, e.g: 
     214 
     215{{{ 
     216data Foo a = Foo (Bar a) 
     217deriving fooNT' :: NT a b -> NT (Foo a) (Foo b) -- not ok, especially if `Bar` is abstract 
     218deriving fooNT :: NT (Bar a) (Bar b) -> NT (Foo a) (Foo b) -- ok 
     219}}} 
     220 
     221Question: `fooNT'` can be constructed from `fooNT` and a possible `barNT :: NT a b -> NT (Bar a) (Bar b)`. Should the compiler do this automatically, if `barNT` is in scope, or is that too much magic? 
    212222 
    213223This solves the abstraction problem for `Data.Map`: The library author only exports `NT a b -> NT (Map k a) (Map k b)`, but not NT a b -> NT (Map a v) (Map b v)`.