Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at