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, 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,
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,
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. the
latter dodges any weird cases where the equalities are different but
the sets really are the same
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
