Changes between Version 11 and Version 12 of NewtypeDeriving


Ignore:
Timestamp:
Apr 15, 2008 9:46:53 PM (6 years ago)
Author:
diatchki
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NewtypeDeriving

    v11 v12  
    5656== Comment == 
    5757This proposal would make newtypes a bit more like type synonyms since they can be made to inherit properties of the underlying type, albeit (usefully) selectively. Having both type synonyms and newtype is a bit confusing, and the more alike they are, the more confusing it is. I guess looking for a single replacement is not an option for Haskell', but at least we should consider if automatic derivation for newtypes does not supersede  TypeSynonymInstances as it would make it significantly less tiresome to introduce a newtype for purposes of abbreviation. 
     58 
     59== Deriving Instances for Multi-Parameter Classes == 
     60The current implementation (GHC 6.8.2) of {{{newtype}}} deriving supports multi-parameter classes but only as long as the newly defined type is the last parameter to the class.  It would be nice to lift this restriction.  Here is an example: 
     61{{{ 
     62class C a b where ... 
     63instance C Int Char where ... 
     64newtype T1 = T1 Char deriving (C Int)   -- OK 
     65newtype T2 = T2 Int deriving (C _ Char) -- not OK 
     66}}} 
     67It would be nice if both of these worked.  The expectation is that the compiler will generate instances like the following: 
     68{{{ 
     69instance C Int T1 where ... reuse C Int Char ... 
     70instance C T2 Char where ... reuse C Int Char ... 
     71}}} 
     72 
     73The main new bit is the {{{_}}} in the deriving clause.  It marks the position of the (possibly applied) newly defined type in the dervied instance.  If an underscore is not present, then it is assumed to be at the end of the parameter list for the predicate.  This makes this extension backward compatible. 
     74