These are chat archives for boostorg/hana

23rd
Dec 2015
Jason Rice
@ricejasonf
Dec 23 2015 07:51
It's still exploding on tests so perhaps it is a bit early, but those changes shave off a little more than half a second for at_key and find_if where n=200.
I don't know if that is good or what are we expecting? :P
Louis Dionne
@ldionne
Dec 23 2015 07:54
Which changes, sorry?
Jason Rice
@ricejasonf
Dec 23 2015 07:54
#223
Louis Dionne
@ldionne
Dec 23 2015 07:55
These are just benchmarks, how could they improve the performance?
Jason Rice
@ricejasonf
Dec 23 2015 07:56
eh?
benchmarks make stuff go faster right? lol
Louis Dionne
@ldionne
Dec 23 2015 07:58
I think I’m misunderstanding your statement. You affirm that fdc9499 provides a 0.5 second speed up over the classical at_key and find_if implementations, correct?
Jason Rice
@ricejasonf
Dec 23 2015 07:58
I'm trying to implement what you were suggesting in #223
Louis Dionne
@ldionne
Dec 23 2015 07:58
AH
I get it now. Apologies, I’m very tired now.
Create a PR whenever you’re ready. I’m very excited about this.
Or you could just add to #226
I think that’s preferable, because these changes are strongly coupled.
Jason Rice
@ricejasonf
Dec 23 2015 08:00
I wasn't sure if you wanted the benchmarks before the optimizations to measure the old implementation against the new.
Louis Dionne
@ldionne
Dec 23 2015 08:00
By the way, the benchmarks are now tied to a single version of the documentation.
Jason Rice
@ricejasonf
Dec 23 2015 08:00
cool
a single version?
Louis Dionne
@ldionne
Dec 23 2015 08:02
I mean the documentation is not always taking the latest version of the benchmarks. So if one checks out Hana v0.7.0, one gets the benchmarks for that version of the library (in the documentation).
Jason Rice
@ricejasonf
Dec 23 2015 08:02
aha
Louis Dionne
@ldionne
Dec 23 2015 08:02
Instead of always getting the latest benchmakrs
Technically, that will be true starting with Hana 0.7.0 and onwards.
Ok, I’m out now. Thanks a lot for working on this, btw.
Jason Rice
@ricejasonf
Dec 23 2015 08:03
np.. I'll merge the optmization with the benchmark pull request unless you say otherwise (after I get it to pass all of the tests)
Louis Dionne
@ldionne
Dec 23 2015 08:04
Leave them be 2 separate commits, but put them in the same pull request
So just push your new commits on top of the current commit that introduces the benchmarks.
Jason Rice
@ricejasonf
Dec 23 2015 08:05
ok
Louis Dionne
@ldionne
Dec 23 2015 08:05
I just renamed the PR so it makes sense to add more than benchmarks to it.
Jason Rice
@ricejasonf
Dec 23 2015 19:09
Is there a function to compose something like this: fn(f)(g)(x...) == f(g(x)...) ?
err
Something like my_compose(make_tuple)(first)(args...) that makes a tuple of firsts without having to make a lambda
Louis Dionne
@ldionne
Dec 23 2015 19:14
Yes. I think it’s hana::on.
I just checked, and it’s hana::on
Jason Rice
@ricejasonf
Dec 23 2015 19:17
Oh. I've used on before. I didn't realize it handled multiple args like that :D
Louis Dionne
@ldionne
Dec 23 2015 19:18
Yes, it’s a small generalization over Haskell’s on combinator.
Jason Rice
@ricejasonf
Dec 23 2015 19:19
I wrote a fizz buzz test in haskell once. :laughing:
Louis Dionne
@ldionne
Dec 23 2015 19:20
Ah
Jason Rice
@ricejasonf
Dec 23 2015 19:20
I only started learning functional programming by playing with Hana
Louis Dionne
@ldionne
Dec 23 2015 19:21
I think that will be the case for a couple of C++ programmers. But FP is gradually taking more place in mainstream languages because it has some advantages, so I think that’ll become more common.
Did Hana’s functional style puzzle you at the beginning?
I tend to think that Hana is very, very soft on the functional things. The base interface is not very deep functional stuff.
Jason Rice
@ricejasonf
Dec 23 2015 19:31

I don't think I was puzzled. The documentation made it a lot easier to follow than Haskell tutorials because of the familiar syntax in the examples.

I tend to think that Hana is very, very soft on the functional things. The base interface is not very deep functional stuff.

Do you mean like formal category theory stuff?

Louis Dionne
@ldionne
Dec 23 2015 19:32
Yeah, pretty much.
I mean there’s some, but you definitely don’t need it to manipulate tuples.
The basic tuple-manipulation interface is really more like Eric Niebler’s range-v3 for tuples than a reimplementation of Haskell.
And that was the goal.
Jason Rice
@ricejasonf
Dec 23 2015 20:36
@ldionne Does map need to support non-empty keys?
Jason Rice
@ricejasonf
Dec 23 2015 20:51
I'm going to assume "no" for now.
Louis Dionne
@ldionne
Dec 23 2015 21:15
Yes, unless there’s a compelling reason not to support them.
What’s the reason?
Jason Rice
@ricejasonf
Dec 23 2015 21:15
Your holder only stores a Value
I suppose it could also store a Key for non-empty types, unless there is some other magical way to do that.
        template <int index, typename Key, typename Value>
        struct map_elt {
            Value value;

            template<typename Pair>
            explicit constexpr map_elt(Pair&& pair)
                : value(hana::second(static_cast<Pair&&>(pair)))
            { }
        };
Louis Dionne
@ldionne
Dec 23 2015 21:22
template <int index, typename Key, typename Value>
struct map_elt {
    Key key;
    Value value;

    template<typename Pair>
    explicit constexpr map_elt(Pair&& pair)
        : key(hana::first(static_cast<Pair&&>(pair))
        , value(hana::second(static_cast<Pair&&>(pair)))
    { }
};
?
Jason Rice
@ricejasonf
Dec 23 2015 21:22
for non-empty types yes
Louis Dionne
@ldionne
Dec 23 2015 21:23
Oh, you want to optimize the storage of empty types away, correct?
Jason Rice
@ricejasonf
Dec 23 2015 21:24
it is kind of already done in the first snippet
I saw how basic_tuple does it
yes
Louis Dionne
@ldionne
Dec 23 2015 21:26
template <int index, typename Key, typename Value, 
          bool = std::is_empty<Key>::value && !std::is_final<Key>::value,
          bool = std::is_empty<Value>::value && !std::is_final<Value>::value>
struct map_elt;

template <int index, typename Key, typename Value>
struct map_elt<index, Key, Value, true, true>
    : Key, Value
{ };

template <int index, typename Key, typename Value>
struct map_elt<index, Key, Value, true, false>
    : Key
{ Value value; };

template <int index, typename Key, typename Value>
struct map_elt<index, Key, Value, false, true>
    : Value
{ Key key; };

template <int index, typename Key, typename Value>
struct map_elt<index, Key, Value, false, false>
{ Key key; Value value; };
Something like that. Then you also need to define the proper constructors.
And if the key and the value types are the same, you can’t inherit.
But that’s a minor implementation challenge.

And if the key and the value types are the same, you can’t inherit.

I mean, you can’t inherit from both because you can’t have duplicate base classes

Jason Rice
@ricejasonf
Dec 23 2015 21:29
Wow, that's taking it even further. Do you think the last two are needed use cases?
btw I have no experience with fusion or mpl
Louis Dionne
@ldionne
Dec 23 2015 21:31
I don’t know whether these are needed use cases, i.e. whether we need to support non-empty keys.
Jason Rice
@ricejasonf
Dec 23 2015 21:31
It seems like if someone really wanted it they could do: type<key> => (key, value)
Louis Dionne
@ldionne
Dec 23 2015 21:31
Right… But what would be the reason not to support it?
Jason Rice
@ricejasonf
Dec 23 2015 21:32
just performance.. I don't really know if the above would be an issue or not... I should probably try it first I guess
Louis Dionne
@ldionne
Dec 23 2015 22:13
I think it’s something that should be benchmarked first. If it’s too costly to be general, then I would say we have sufficient reasons not to allow empty keys.
Jason Rice
@ricejasonf
Dec 23 2015 23:08
At this point, maybe it makes sense to just make map_elt hold a hana::pair.
or a basic_tuple like pair does
Louis Dionne
@ldionne
Dec 23 2015 23:10
Yes, indeed. I would go for the basic_tuple, since it is more low level (and hence more efficient).
Jason Rice
@ricejasonf
Dec 23 2015 23:14
:D