On Fri, May 1, 2015 at 11:51 PM, Keean Schupke <ke...@fry-it.com> wrote: > > On 2 May 2015 04:28, "Matt Oliveri" <atma...@gmail.com> wrote: >> But what enforces the coherence? And why doesn't it rule out the >> ability to explicitly pass other instances? My understanding is that >> coherence implies that the program can use only one instance of a >> given typeclass for a given argument vector. So it makes no sense to >> pass an instance explicitly; there's only one choice. If there are >> multiple choices, you don't have coherence. Please, someone correct me >> if I understood it wrong; I am new to typeclasses. > > Multiple choices do not matter at the site of definition. All that matters > is that resolution finds a single match. I agree with the video that Scala's > scoping rules make it hard to understand instance wins when multiple could > match.
Maybe I misunderstood the whole point of this thread, as it relates to the video. With coherent instances, one talks about _the_ instance of a typeclass. Whenever you get an instance argument, you'll get _the_ instance. If you don't have this "the" property, then I don't understand what you think you have. I assumed William's after a system that allows controlled use of multiple instances for the same class, but still has the "the" property in some sense, which hopefully hasn't been weakened too much. But 1) Since I don't understand the benefits of coherence well, I may not be a good judge of how weak is too weak. 2) That assumption may have been wrong, and I don't know what William's doing. As for you (Keean), you don't seem to be after a "the" property. No matter how natural/inevitable your system's implicit instance choices are, if one part of the program is not isolated somehow from the fact that another part of the program can choose a different instance, then it isn't coherence, and it doesn't seem to me like a significant improvement. >> I'm afraid the rest of your email didn't clarify anything for me. We >> both understand the advantage of giving up coherence. But you seem to >> underestimate the disadvantages. I don't see how you expect to recover >> the guarantees of coherence while allowing instances to be passed >> explicitly. > > This all comes back to passing first class functions. You see nothing wrong > with passing a first class function. How about a record containing several > functions, still fine right. Yep. > Each value of the record type can pass > different implementations of the functions as long as they all have the same > type (or the record can have type parameters). So passing a record is like > explicit dictionary passing, and dictionary passing is the method used to > implement type classes. Right. > In my suggestion, the record type declaration creates a matching type-class > (or it can be viewed as both things simultaneously) but record values are > not automatically instances of that class, they are simply record values. Sure. > Only when you promote them to type-classes with the 'use' declaration, do > they function as type class instances. Type class instances must be globally > coherent exactly as in Haskell. Whoa! Is that all you meant?! Why does your "use" correspond to Haskell's "instance"? That really confused me. I thought "use" was a way to import someone else's instance explicitly, and different parts of the program could "use" different instances. So the problem is that when you define a function taking a record value of a typeclass/record type, you don't know if the record you get will be the instance, or some other record. So back in the fast union example, you still don't know if the input sets are in the given order. It's the "the"/"a" distinction. Instances are "the"s, everything else is an "a". When you write your function, you want to know which it is. If Sets are ordered by _an_ order, fast union doesn't work without something else to enforce the order of the input sets. If Sets are ordered by _the_ order, it just works. In your setup, we don't make a distinction between "the" and "a", so we have to pessimistically treat the situation as "a". _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
