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

Subject: Re: [boost] Boost.Hana - Type Classes, data types and categories (tags).
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-09-17 16:49:04

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!

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

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

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

Regards,
Louis