Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 02:04
    pthom commented #432
  • Jan 18 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 22:27
    ricejasonf commented #434
  • Jan 05 06:22
    ricejasonf commented #330
  • Jan 03 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Jason Rice
@ricejasonf
kind of like detail::hash_table... maybe I should be using metafunctions
Louis Dionne
@ldionne
Regarding optional, I opened boostorg/hana#254 so I don’t forget it.
Jason Rice
@ricejasonf
cool thanks
Jason Rice
@ricejasonf
Would it be a huge change to have hana::decltype_ strip cv-qualifiers or is there something that does that?
Louis Dionne
@ldionne
If you need to strip cv-qualifiers, you can use hana::traits::remove_cv. Why would you like hana::decltype_ to remove them?
By the way, the reason why hana::decltype_ strips references is because it couldn’t be implemented consistently when keeping references. So it was decided that stripping references completely, while arbitrary and limiting, was the simplest choice.
Jason Rice
@ricejasonf
I know I am misusing optional here, but...
hana::decltype_(hana::nothing) != hana::decltype_(hana::optional<>{})
ricejasonf/nbdl@aa64103
Louis Dionne
@ldionne
One’s const and the other one is non-const?
nothing is const because it’s a constexpr optional<>?
Whereas the other one falls through the T&& of hana::decltype_ since it’s a temporary, and it’s then transformed into optional<> after removing rvalue reference.
Jason Rice
@ricejasonf
I think so. I get bit by the const - not const thing a lot. With hana::hash and mpdef::Map too I had to use std::add_const.
Louis Dionne
@ldionne
Do you remember the exact problem with hash?
Jason Rice
@ricejasonf
I think I had specializations for const but you simplified it with remove_cv.
Louis Dionne
@ldionne
Regarding this whole optional thing; while I’ll probably specify its template parameters, it feels like you’re doing something wrong. I’ll try to take a deeper look at your code.
Jason Rice
@ricejasonf
You mean like with the tuple with optionals in it?
Louis Dionne
@ldionne
Yes. I feel like it might be easier to define the tuple once you have the values themselves.
Regarding hash: I just checked and you had const specializations for char and unsigned char only.
Jason Rice
@ricejasonf
I don't remember why exactly
lol
Louis Dionne
@ldionne
There were probably problems with char not being comparable to other integral types, but that was fixed separately.
What I do now for hash is simply discard the cv-qualifiers of the value in the IntegralConstant, for the cv-qualifier does not change whether two IntegralConstants are equal.
Jason Rice
@ricejasonf
ah right
Louis Dionne
@ldionne
I’m looking at your mpdef::Map right now and I see the add_const, but I don’t understand why it would ever be needed.
Jason Rice
@ricejasonf
If the map was made with a key of hana::int_c<1> that would be of type const hana::integral_constant<int> and it wouldn't match hana::integral_constant<int>
Louis Dionne
@ldionne
Oh shit, right.
But that’s an issue you run into when you use values for their type instead of “properly” storing them into hana::type or a similar container.
Jason Rice
@ricejasonf
Yeah, it's probably not something Hana needs to solve, but I run into the problem often. gtg eat ttyl
Jason Rice
@ricejasonf
#include<boost/hana.hpp>
#include<boost/hana/experimental/types.hpp>

namespace hana = boost::hana;
namespace hanax = boost::hana::experimental;

int main() {
  {
    constexpr auto xs = hanax::types<
      hana::int_<1>,
      hana::int_<2>,
      hana::int_<3>
    >{};

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(xs, hanax::make_types(
            hana::int_c<1>,
            hana::int_c<2>,
            hana::int_c<3>
        ))
    );

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(xs, hanax::make_types(
            hana::type_c<hana::int_<1>>,
            hana::type_c<hana::int_<2>>,
            hana::type_c<hana::int_<3>>
        ))
    );

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(
            hanax::make_types(xs, xs, xs),
            hanax::make_types(
                hanax::make_types(
                    hana::type_c<hana::int_<1>>,
                    hana::type_c<hana::int_<2>>,
                    hana::type_c<hana::int_<3>>
                ),
                hanax::make_types(
                    hana::int_c<1>,
                    hana::int_c<2>,
                    hana::int_c<3>
                ),
                hanax::make_types(
                    hana::int_c<1>,
                    hana::int_c<2>,
                    hana::int_c<3>
                )
            )
        )
    );
  }
}
:grin:
sorry.. maybe i should have gisted that
If I accidentally call hana::make_types it says the only candidate function takes a single argument which is really, really weird considering there is no hana::make_types
flatten doesn't work yet because it unpacks as type_impl<types<T...>>
Jason Rice
@ricejasonf
ricejasonf/hana@8cc5f32
Louis Dionne
@ldionne
Actually, if you think of it, I don’t think it makes sense for hana::experimental::types to be a Monad, since it’s not possible for it to contain another hana::experimental::types.
For some Monad M, flatten needs to havea signature M(M(T)) -> M(T), which does not make sense for experimental::types since M(M(T)) does not exist.
Jason Rice
@ricejasonf
lol.. here I am hacking it in there. What if we thought of hana::type as a singleton hana::types?
Louis Dionne
@ldionne
Well then I think M(T) wouldn’t have sense anymore, it would always be M(M(T)) (where M is experimental::types_tag and T is hana::type_tag).
I’m not sure, let me think.
Jason Rice
@ricejasonf
template <typename T>
using type = hana::types<T>;
I'm not saying do that, but the idea is that they are the same.
so M would have to consider type_tag and types_tag as interchangeable.
Louis Dionne
@ldionne
Yeah, I understand your idea. I’m trying to see what it changes w.r.t. the ability to make it a Monad.
Jason Rice
@ricejasonf
I think unpack would have to not wrap a member with type if it is a hana::types.
Louis Dionne
@ldionne
I think there’s no level of sophistication that would make it legal for hana::types to be considered a Monad. I’ll let it sink in, though, because there might.
Jason Rice
@ricejasonf
yeah... static_assert failed "hana::equal( hana::monadic_compose(lift<M>, f)(x), f(x) )" :hurtrealbad:
Jason Rice
@ricejasonf
To be a Monad, does it have to be able to work with ANY kind of value? I definitely see that with Sequences as they are meant to be isomorphic.
I think, for my purposes, I will continue to use my empty list, but give it the same unpack specialization for Metafunctions because that is really useful. (or a special function or something)
Jason Rice
@ricejasonf
ricejasonf/hana@e55ef11