Boost logo

Boost :

Subject: Re: [boost] Boost.Hana - Type Classes, data types and categories (tags).
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-09-21 13:11:59


Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:

>
> Le 17/09/14 23:30, Vicente J. Botet Escriba a écrit :
> > Le 17/09/14 22:49, Louis Dionne a écrit :
> >> Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
> >
> >>> 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> {};

I think I don't understand what you are trying to achieve here. What exactly
are CatA and T? What effect do you want to achieve in doing such a type class
instantiation (instantiation in Hana/Haskell terms).

> A deeper analysis of your code let me think that you have already
> something similar to what I was requesting.
>
> [...]
>
> The previous specialization let the data type class define directly how
> is it could be seen as an instance of a given type class NAME.
> I see however that this has been used only fro the Record type class.
>
> boost/hana/record/macros.hpp: struct hana_Record :
> ::boost::hana::Record::mcd { \
>
> So here you have the use_case you were requesting.

Given a data type D, it is possible to instantiate any unary type class TC
from inside D's definition as follows:

    struct D {
        struct hana_TC {
            // type class definition
        };
    };

This is true for all unary type classes. However, since the instantiation of
the Record type class is very straightforward, a macro is provided to make it
even easier. Note that the ability to instantiate a type class from inside a
data type's definition is not documented right now.

Regards,
Louis


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk