On Thu, Apr 30, 2015 at 5:10 PM, Matt Rice <[email protected]> wrote: > On Thu, Apr 30, 2015 at 12:53 PM, Matt Oliveri <[email protected]> wrote: >> On Thu, Apr 30, 2015 at 6:31 AM, Matt Rice <[email protected]> wrote: >>> the set ordered by primary_colors = {R?,G?,B?} and ask if inventory is >>> equal to the set primary_colors, and primary_colors is equal to >>> inventory, >> >> I don't think it should be allowed to compare a set of paint cans to a >> set of colors. It doesn't matter that those paint cans have colors, >> you'd need to do a map first, to get the set of the paint cans' >> colors. > > Sorry didn't make this clear, the set {R?,G?,B?} is all of the > elements of the set inventory inserted with the ordering that > considers paint cans equal if their colors are equal. > > It *is* useful to take a set and count how many elements it contains > by some different ordering. The ? in the element was intended to > describe the uncertainty of _which_ paint can was represented in the > set due to a lossy ordering.
Ah, I see. I saw the name "primary_colors" and assumed it was a set of colors. >>> and you define eq as a comparison between 2 sets, and not 2 sets and a >>> peacekeeping force, you arrive at a couple of different possible >>> answers... >>> >>> yes (same elements by my eq), no (different elements by my eq), no >>> (x.eq != y.eq), or nonsense the eq's aren't the same this is not a >>> valid question, >> >> I'd prefer the last one, if it's possible for the sets to have >> different element equality tests. > > That's the answer that typeclasses give, that the types aren't the same > and so the answer is a type error. Umm, well I thought with typeclasses with instance coherence, you can't have sets of the same type whose elements are "unique" according to different equality tests. (Assuming you are using the Eq instance for the equality test.) So I wouldn't call that a type error when the tests are different, but that you can't arrange for the tests to be different. Back in the fast union example, the whole problem with not having instance coherence is that the type system actually does _not_ have a way to check that the arguments to union use the same ordering. It was relying on the (anti-modular) global property that all sets with the same element type use the same ordering. >> With dependent >> types, sets could be tagged, at the type level, with which element >> equality test they use. Neither the elements nor the element type have >> an associated equality. With implicit instance arguments, it seems >> ambiguous how set equality is supposed to work. > > most things can take an explicit ordering if you must, > equality is really where this breaks down because the definition of > equality as a comparison between 2 distinct things, Huh? That doesn't sound right. If we could only test for equality between distinct things, why are we doing the test? We'll definitely get false. I can see that it's probably a lot less useful to have multiple notions of equality in the same type than multiple notions of order. But that's nothing technical, it's just a convention that a type usually comes with the right notion of equality for elements (even if you can't test it). _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
