Local types and instances

[Edward Kmett]

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
under the `where` clause that defined the local data type with a different
value. So, yes, unless you're willing to figure out how to somehow decide
the equality of arbitrary values and functions. If you try to say you can't
write that sort of scenario by using some sort of magical generative trick
that says each invocation of the function that got you down to that data
type gives you an entirely 'fresh' type, I suspect you'll run into subtle
problems with unification / type checking. I'd love to be wrong, but my
expectation is that all of these paths fail.

In any event, Gershom is right, this is the wrong forum for this discussion.

-Edward


On Sun, Apr 29, 2018 at 7:37 PM, Matthew Farkas-Dyck <strake888 at gmail.com>
wrote:

> On 4/29/18, Edward Kmett <ekmett at gmail.com> 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 easy to construct such a map in one local context and use it in
> > another with a different instance.
>
> Ah, i forgot to say explicitly: local instances of types declared at
> greater scope are not allowed. Is it unsound nonetheless?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20180429/4f21f54c/attachment-0001.html>