These are chat archives for boostorg/hana

29th
Jan 2016
Louis Dionne
@ldionne
Jan 29 2016 14:55
@ricejasonf Would it be possible to split the addition of the Hashable concept into a different commit?
Jason Rice
@ricejasonf
Jan 29 2016 14:59
Yes. I'm assuming you mean along with 'hash' and the tests right?
Louis Dionne
@ldionne
Jan 29 2016 14:59
Yes
No need for a separate PR, btw, just a separate commit in the same PR.
Jason Rice
@ricejasonf
Jan 29 2016 16:15
I don't suppose there is a way to hash associative containers other than just returning their tag is there?
Louis Dionne
@ldionne
Jan 29 2016 16:16
You mean defining hana::hash on hana::map_tag?
Jason Rice
@ricejasonf
Jan 29 2016 16:16
yes or set
Louis Dionne
@ldionne
Jan 29 2016 16:16
Right.. The same question could be asked for hana::Sequences and virtually any kind of object.
That’s a good question: I think I would make them non-hashable for now.
Just like you can’t call std::hash on an arbitrary object.
Jason Rice
@ricejasonf
Jan 29 2016 16:17
currently the default implementation just returns the identity, but maybe it should be the tag_of
Louis Dionne
@ldionne
Jan 29 2016 16:17
And I don’t think it would be a limitation concretely, since it should seldom be the case that you want your keys to be hana::Sequences or something more fancy.
Actually, I’m thinking we might want not to provide a default implementation.
Jason Rice
@ricejasonf
Jan 29 2016 16:19
or maybe make the default type<void> so they fall in the same bucket?
I definitely have a use case for sets as keys
Louis Dionne
@ldionne
Jan 29 2016 16:20
Oh...
What is it?
But do we agree that whatever we settle on for hana::sets, hashing them properly will be very expensive (at least O(n), since we’ll have to somehow look at all the elements).
Jason Rice
@ricejasonf
Jan 29 2016 16:22
I don't think hashing a set of types is possible since they are unordered.
    createPath(
        key<2> = x,
        key<1> = y,
        key<4> = z
    );
The named parameter idiom where the keys define what type will be constructed
Jason Rice
@ricejasonf
Jan 29 2016 16:27
(ignoring that those are ints)
type<void> is a bad idea nm :P
Louis Dionne
@ldionne
Jan 29 2016 16:28
Why is it a bad idea?
I see it as a possible solution.
Jason Rice
@ricejasonf
Jan 29 2016 16:28
because two things that are not comparable with each other would fall in the same bucket and explode.
Louis Dionne
@ldionne
Jan 29 2016 16:28
Well that already happens right now with the linear search in a tuple.
That wouldn’t be a regression, at least :p
Jason Rice
@ricejasonf
Jan 29 2016 16:34
should I have it do that?
Louis Dionne
@ldionne
Jan 29 2016 16:34
Not yet, it’s a tough question
Jason Rice
@ricejasonf
Jan 29 2016 16:34
I'll push those split commits for the mean time
Louis Dionne
@ldionne
Jan 29 2016 16:35
Please do. The most conservative option is clearly to make it undefined except for tags that enable it explicitly. This way, we can change its behaviour later as we wish.
Jason Rice
@ricejasonf
Jan 29 2016 16:35
that would make the Hashable concept make more sense :P
Louis Dionne
@ldionne
Jan 29 2016 16:35
I think so.
Jason Rice
@ricejasonf
Jan 29 2016 16:35
do that? or just push
Louis Dionne
@ldionne
Jan 29 2016 16:36
Start by splitting the commits
Jason Rice
@ricejasonf
Jan 29 2016 16:36
i did that
oh right
Louis Dionne
@ldionne
Jan 29 2016 16:36
Push it then
I’ll comment directly on the commit introducing hashes
Jason Rice
@ricejasonf
Jan 29 2016 16:37
k. pushed
Louis Dionne
@ldionne
Jan 29 2016 16:37
thanks
Jason Rice
@ricejasonf
Jan 29 2016 19:31
I'm kind of stuck on something:
    // build_hash_table - metafunction
    template <typename ...>
    struct build_hash_table_initial;

    template <std::size_t ...i, typename ...Key>
    struct build_hash_table_initial<std::index_sequence<i...>, Key...> {
        using type = detail::hash_table<
            detail::bucket<decltype(hana::hash(std::declval<Key>())), i>...>;
        static_assert(type::bucket_count == sizeof...(i),
            "Hash based containers may not have duplicate keys.");
    };

    template <typename GetKey, typename Storage>
    struct build_hash_table {
        using FirstRun = decltype(hana::take_while(std::declval<Storage>(),
            detail::FastKey{} ^hana::on^ std::declval<GetKey>()));
        using Initial = typename decltype(
            hana::unpack(std::declval<FirstRun>(),
                hana::partial(hana::metafunction<detail::build_hash_table_initial>,
                    std::make_index_sequence<decltype(hana::size(std::declval<FirstRun>()))::value>{})
            )
        )::type;
        //using Initial = detail::hash_table<>;

        using type = decltype(hana::fold_left(
            hana::make_range(hana::size_c<Initial::bucket_count>, hana::size(std::declval<Storage>()))
            , Initial{}
            , detail::hash_table_insert<GetKey, Storage>{}
        ));
        //using Z = typename show<Initial>::foo;
    };
In both cases Initial is shown as detail::hash_table<> and bucket_count is zero, but it fails to insert anything when Initial is dependent on the result of build_hash_table_initial
by fails I mean that the at_keylookup explodes because the key is not set
Jason Rice
@ricejasonf
Jan 29 2016 19:56
disregard... bucket_count was always zero because of the specialization for empty maps
        using Z = typename show<decltype(
            hana::if_(hana::greater(hana::size_c<Initial::bucket_count>, hana::size_c<0>),
                Initial{}, dontshow{})
        )>::foo;
heh heh
Louis Dionne
@ldionne
Jan 29 2016 20:04
Actually, couldn’t we partition the types into those with FastKeys (actually, I think these are types whose hash function is perfect — not sure) and those that do not have FastKeys?
So basically use partition instead of take_while?
Jason Rice
@ricejasonf
Jan 29 2016 20:09
sounds even better. I'm still mucking with this problem. It gave me an idea for a metafoonction show_if<Blah> though. :P
Louis Dionne
@ldionne
Jan 29 2016 20:10
lol
Jason Rice
@ricejasonf
Jan 29 2016 20:12
hash(x) == x
err
hash(x) == type(x) or something like that
no I like the first one better
Louis Dionne
@ldionne
Jan 29 2016 20:19
What is that? The condition for being a FastKey?
Jason Rice
@ricejasonf
Jan 29 2016 20:19
I think it would be
Louis Dionne
@ldionne
Jan 29 2016 20:21
I would hardcode it as being string_tag, type_tag, etc...
Jason Rice
@ricejasonf
Jan 29 2016 20:21
right
Jason Rice
@ricejasonf
Jan 29 2016 22:10
This message was deleted