If your instances are allowed to depend on values that are in scope in your
nested context then the choice of those values is effectively part of the
name of the data type. Otherwise I can package one of those 'local' data
type definitions up, pass it out into another context that brings it back
un
Given the open world assumption, how do you know a priori if a type is declared
at greater scope?
(Note: one answer here is that you can refuse to link in such a contradictory
instance, so instead of an ‘open world’ you move to a ‘coherent world’ where
you have to discharge a global coherence c
On 4/29/18, Edward Kmett wrote:
> This isn't sound.
>
> You lose the global uniqueness of instance resolution, which is a key part
> of how libraries like Data.Set and Data.Map move the constraints from being
> carried around in the Set to the actual use sites. With "local" instances it
> is very
This isn't sound.
You lose the global uniqueness of instance resolution, which is a key part of
how libraries like Data.Set and Data.Map move the constraints from being
carried around in the Set to the actual use sites. With "local" instances it is
very easy to construct such a map in one loca
Idea: Allow local type and instance declarations, i.e. in `let` or `where`
clause.
Primary motivation: defining `ordNubBy` and such, i.e. functions which take an
effective class dictionary
In Haskell now, we can readily write `ordNubOn :: Ord b => (a -> b) -> [a] -> [a]` in terms of
`Set` [0]
