Re: [boost] Boost.Hana - Type Classes, data types and categories (tags).

Subject: Re: [boost] Boost.Hana - Type Classes, data types and categories (tags).
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-09-17 17:30:21

Le 17/09/14 22:49, Louis Dionne a écrit :
> Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
>
>> Hi Louis,
>>
>> There is a lot of very good work on your library.
> Thank you!
>
>
>> I have some comments in relation on how I have implemented Type Classes
>> in my prototype.
> You wrote a type class emulation in C++? Could you please share the link;
> I'd like to have a look!
The ideas are similar. The form changes.

https://github.com/ptal/expected
https://github.com/ptal/expected/tree/master/include/boost/functional
>
>
>> About datatype<T>. The library proposes type classes and data types. The
>> name datatype_t<> is confusing as the datatype<T> meta-functions must
>> not return one of the defined data types. I see it much more as a
>> category, which is used to map the data type to a category used as
>> parameter of the instantiation
>>
>>    TC::Instance<datatype_t<T>>.
> IIUC, you're pointing out that `datatype_t<decltype(object)>` is usually not
> the same as `decltype(object)`, which is inconsistent with the way the term
> "Data type" is used in Hakell. If so, you are right about the inconsistency.
> Regardless of this particular issue, I'll have to rename some stuff in Hana
> as others have pointed out. I haven't done it yet since I haven't found names
> that are incredibly better than "data type" so far, but I'm adding "category"
> to the list. Another candidate is "tag", which would have the additional
> benefit of being familiar to Fusion and MPL people.

Why not.
>
>> In addition, I wonder if the category associated shouldn't depend on the
>> type class we want to map.
>>
>> TC::Instance<category_t<T, TC>>
> I'm not sure why that would be useful. Do you have a use case in mind?

After more thoughts the user can always specialize TC::Instance<T> 
inheriting from TC::Instance<CatA>.

struct TC::Instance<T> : TC::Instance<CatA> {};
>
>
>> About naming: Haskell doesn't have namespaces and all the functions are
>> at the same scope. Your library makes use of a lot of non-member
>> functions, and so name clashing must be avoided. What about moving all
>> the non-member functions of the Type Class to a specific namespace? E.g.
>>
>>     struct Monad { ... };
>>
>> namespace monad {
>>       using namespace applicatives;
>>       ... bind()
>>     };
>>
>> The use would need to use the type class namespace explicitly
>>
>>     auto x = monad::bind(m, f)
>>
>> or introduce the namespace of the type class
>>
>>     using namespace monad;
>>     auto x = bind(m, f);
> I had not thought about the issue because right now, name clashing is avoided
> simply by not having two functions with the same name. This has worked well so
> far. Since this is the simplest way to do things, I'd rather keep it that way.
> Of course, if I need to introduce a function whose name would clash, then I
> will strongly consider your suggestion; thank you for that.
>
>
You are welcome,
Vicente