johan.tibell at gmail.com
Mon Jan 14 23:29:57 CET 2013
On Mon, Jan 14, 2013 at 1:45 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
> * Johan Tibell <johan.tibell at gmail.com> [2013-01-14 13:32:54-0800]
>> On Mon, Jan 14, 2013 at 1:19 PM, Simon Peyton-Jones
>> <simonpj at 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?
More information about the Glasgow-haskell-users