On Mon, Jan 14, 2013 at 1:45 PM, Roman Cheplyaka <r...@ro-che.info> wrote:
> * Johan Tibell <johan.tib...@gmail.com> [2013-01-14 13:32:54-0800]
>> On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
>> <simo...@microsoft.com> 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
>> > (http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi.html#ffi-newtype-io)
>>
>> 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?
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
