On Thu, Apr 30, 2015 at 12:53 PM, Matt Oliveri <atma...@gmail.com> wrote:
> On Thu, Apr 30, 2015 at 6:31 AM, Matt Rice <ratm...@gmail.com> wrote:
>> On Wed, Apr 29, 2015 at 2:12 PM, Matt Oliveri <atma...@gmail.com> wrote:
>>> On Wed, Apr 29, 2015 at 1:47 AM, Keean Schupke <ke...@fry-it.com> wrote:
>>>> On 29 Apr 2015 05:12, "Matt Oliveri" <atma...@gmail.com> wrote:
>>>>> 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.
>>>>
>>>> If the two orderings define uniqueness differently, say people ordered by
>>>> age in one set, and people ordered by name in another, then to union them
>>>> is
>>>> a nonsense.
>>>
>>> Well, not really. Mathematically speaking, sets don't have an order;
>>> that's an implementation issue. But whether it's nonsense or just a
>>> bad idea is besides the point.
>>
>> They do not have order necessarily, but they do require elements to
>> have Eq to provide element distinction,
>
> Yeah.
>
>> If you consider comparing 2
>> sets for equality...
>>
>> say paint cans inventory = {R1, R2, Rn, G1, G2, Gn, B1, B2, Bn},
>> with the colors of different red, green, blue paints.
>>
>> 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.
yeah, you should probably use map, but thats not exactly a useful
example for this problem ;)
>> 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.
>> so in order to maintain sanity in this case you must drop the notion that
>> a collection can inherit the equality of its elements, or ensure that
>> you can only compare collections with the same notion of equality.
>
> I don't know what you mean by a collection inheriting the equality of
> its elements. With coherent typeclass instances, the element type has
> an associated equality, which set equality will use, but the equality
> is not associated with individual elements or sets.
confirming that this is what I meant, inherit was a bad choice of term.
> 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, the only thing I
can imagine is going the route ocaml went with its disjoint math
operators e.g. +. vs + for addition on real vs integers, but
generalizing it to Foo.= vs Bar.= that is for the LHS and RHS operands
the equal operator is Foo.= and whether this would play nicely along
with typeclasses as the default equality operator
random thought, i haven't considered too much, i'm sure theres
probably some obvious issue with it
>> the
>> latter dodges any weird cases where the equalities are different but
>> the sets really are the same
>
> Yeah. It's a matter of abstraction. The sets may be represented the
> same, so that the choice of equality doesn't matter, but equality of
> sets isn't equality of set representations.
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
