On Tue, Apr 28, 2015 at 11:26 PM, Keean Schupke <ke...@fry-it.com> wrote:
>
> On 29 Apr 2015 02:06, "William ML Leslie" <william.leslie....@gmail.com>
> wrote:
>>You would not have two instances for (Foo Bar) that you expect to get
>> resolved implicitly in the same scope. You'd provide one of them
>> explicitly.
>
> This is the important point. I actually prefer to allow instance definitions
> that are not put into implicit scope automatically. Then a separate
> directive brings an instance into implicit scope, otherwise it must be
> passed explicitly.
>
> The problem is you want the implicit resolution in static scope, so the
> overload can be resolved at compile time. But at least this way you control
> implicit resolution locally.
>
> For example:
>
> Module A defines named instance "a" for Foo Bar, and Module B defines "b"
> for Too Bar, then:
>
> module A {
> instance Show (Foo Bar) as a where ...
> }
>
> module B {
> instance Show (Foo Bar) as b where ...
> }
>
> module C {
> import module A
> import module B
>
> use b for Show (Foo Bar)
> f x = show x
> }
My understanding from the video is that with this kind of solution,
you still wouldn't be able to union sets efficiently, because the sets
may come from people using different Ord instances for the element
type. Unless the union code and both sets all come from within the
lexical scope of the same "use" directive; but that restriction seems
onerous.
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
