[SetTheoretic] Add SetTheoretic concept

[shreyans800755]

It adds SetTheoretic concept for functions-
union, intersection, difference, symmetric_difference.

Closes #357

[shreyans800755]

@ldionne Can you please review this ?

[ldionne]

Great start, and thanks a lot for the work you're putting into it!

[ldionne]

Defining the concept as "things that have the methods that the concept provides" is kind of circular, and not very useful IMO. Also, you're not defining laws for the concept. I'd go for a brief like this instead:

The SetTheoretic concept represents data structures that support an algebra of sets.

Then, I'd make some comments about what the concept is at a high level, and why it's useful. I'd also give the laws that the concept must follow, e.g. probably the ones on the Wikipedia page.

Other comments:

• One thing that must be thought about is the relationship between this concept and Searchable. Indeed, Searchable provides is_subset; it seems clear that there's an interesting mathematical link between both, and it should be explored, explained and some laws should be surfaced for data structures that are both Searchable and SetTheoretic.
• You should also think about automatically-provided models and document them, if you can find some. What I mean here is that you should try to see whether satisfying some other concept(s) makes it possible to satisfy SetTheoretic automatically. When this is the case, Hana usually provides such a definition and documents it (e.g. Foldable for any Iterable).
• The methods should be documented like normal methods that are tied to a concept, not individually for map and set.

I know this may seem like a lot, but this is what a concept in Hana is; it's not only a syntactical construction, it's also a tool to reason mathematically about programs, which requires a little more work to define than "loose" concepts that don't have clear semantics, if I may put it that way.

If there are things where you really don't know what to do, let me know and I'll try to make some time for researching the topic to try and provide some guidance.

[ricejasonf]

Would it make sense for SetTheoretic to have its own accessors? Something like get<T>(set) == at_key(set, T{}) would be very useful for set and it would be a way of making SetTheoretic provide an implementation for Searchable.

It might even simplify implementation of these functions assuming "keys" are strictly looked up at compile-time. Hmm.. that might also require something like the keys function that map has.

Also perhaps it should be just hana::Set.

[ricejasonf]

The TLDR is that they would only have to implement those accessors and not the union, intersection,... algorithms directly

[DarthRubik]

From what I see it does not necessarily make sense to have SetTheoretic be related to Searchable if the goal is to create a generic thing that supports the algebra of sets.

You can make plenty of things that support the algebra of sets that it does not make sense to be Searchable.

For example: a string of bits:

1010 union 0001 => 1011
1010 intersection 1000 => 1000
1010 difference 1000 => 0010
1010 symmetric_difference 1001 => 0011

Anyways......thats just the way I see it.......
@ldionne @ricejasonf @shreyans800755

[ricejasonf]

@DarthRubik I don't believe we are trying to couple Set with Searchable, but types that satisfy Searchable can be made to implement the needed functions for Set. For your string of bits you would probably implement those functions directly.

[shreyans800755]

Resuming work after ages. Would like complete it this time.

[shreyans800755]

@ldionne
This actually doesn't seem good to me logically. Although infinite set had union function implemented, we can't call it, because apparantly, union requires the class to be SetTheoretic meaning it requires minimal definition - all 3 functions union, intersection & difference. But, mathematically, it seems accurate though.
Any thoughts ?

[shreyans800755]

Also, mathematically, this doesn't seem accurate. Because, ideally intersection must be commutative, but here only set::intersection is commutative, but map::intersection is not.
@ldionne I'm not sure if this was intended, but your input would be appreciated.