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.
> 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.
> 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. 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.
> 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
