Newtype wrappers

Johan Tibell johan.tibell at
Mon Jan 14 23:29:57 CET 2013

On Mon, Jan 14, 2013 at 1:45 PM, Roman Cheplyaka <roma at> wrote:
> * Johan Tibell <johan.tibell at> [2013-01-14 13:32:54-0800]
>> On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
>> <simonpj at> wrote:
>> > Have you considered the effect on types like Data.Set that use the
>> > uniqueness of typeclass instances to maintain invariants? e.g. even when we
>> > have "newtype X = X Y" coercing "Set X" to "Set Y" can produce a tree with
>> > the wrong shape for the Ord instance of Y.
>> >
>> >
>> >
>> > Good point. I should add this.  The wrapper should only work if the relevant
>> > data constructors are in scope; rather like GHC’s existing auto-unwrapping
>> > on foreign calls
>> > (
>> I don't follow. Are you saying that adding an import, even if nothing
>> from that import is used, can effect if the program compiles?
>> Does that mean if we ever add Data.Map.Internal that exposes the data
>> constructors to users who "know what they're doing" (i.e. are willing
>> to take it upon themselves to maintain the invariants) then code that
>> used to compile will stop to do so?
> Now I don't follow you. Why will it stop compiling?
> If you define wrappers/unwrappers involving Data.Map, then they will
> compile if Data.Map.Internal is imported and will not compile if it isn't.

Let me rephrase: how will Simon's proposed "data constructors are in
scope" mechanism work? For example, will

    let xs :: Map = ...
    in map MyNewtype xs

behave differently if the constructors of Map are in scope or not?

More information about the Glasgow-haskell-users mailing list