These are chat archives for boostorg/hana

6th
Jan 2016
Jason Rice
@ricejasonf
Jan 06 2016 02:25
It is probably just an oddity of bad form, but if you try to print a hana::map_tag{}, it will try to print it as a map because of the idempotent tag_of thing. (I just wrapped it in a type_c though).
Louis Dionne
@ldionne
Jan 06 2016 03:15
Yeah, the map_tag thing is mostly an oddity, although one I had not thought about.
demux is very, very powerful. It was originally introduced as a way of working around the lack of constexpr lambdas. Unfortunately, it is a bit difficult to grok complicated expressions like the above. Soon, we should have constexpr lambdas in the language, and it should be more straightforward to write the above.
Jason Rice
@ricejasonf
Jan 06 2016 04:28
idk I kind of like it :P
Louis Dionne
@ldionne
Jan 06 2016 04:30
While fun to write, I challenge you to re-read this a month from now and to tell me what it does in less than 15 seconds. You can’t :smile:
Jason Rice
@ricejasonf
Jan 06 2016 04:32
  template<typename... Tag>
  constexpr auto withSettings(Tag&&... tag) const
  {
    auto initial_state = mpdef::withSettings(std::forward<Tag>(tag)...);
    auto collectFinal =
        hana::reverse_partial(hana::transform,
          hana::reverse_partial(hana::unpack, //pair
            hana::demux(hana::make_pair)
            (
              hana::arg<1>,
              hana::flip(mpdef::collectSettings)
            )));
    return hana::curry<2>(hana::demux(collectFinal)
      (
       //(tree, summarize, pred)
        hana::demux(hana::partial(hana::flip(*this), initial_state))
        (hana::arg<2>, hana::always(mpdef::collectSettings), hana::arg<1>)
      )
    );
  }
I had to break that one up
Louis Dionne
@ldionne
Jan 06 2016 15:25
@ricejasonf Do you know how I could share my changes to your patch with you? GitHub doesn’t have collaborative pull requests, and I’d like a way to discuss over my changes to your patch.
I could fork your fork of Hana and then submit a PR to your benchmarks/map branch. But that seems clunky, and it would break the automatic redirect from ldionne/hana to boostorg/hana, which is useful because I moved the repository to boostorg.
Jason Rice
@ricejasonf
Jan 06 2016 15:45
You could put it into its own branch.
Louis Dionne
@ldionne
Jan 06 2016 15:46
Right, I think that’s what I’ll do.
Jason Rice
@ricejasonf
Jan 06 2016 21:19
@ldionne What do you think of this? I was playing around with matchers on a sort of 'abstract meta info tree' using nested hana containers. https://github.com/ricejasonf/nbdl/blob/8f255d5d3ec334fcae2d814a298f19047bd9d206/test/mpdef/find_in_tree.cpp
The standard 'directive' is a pair(tag, map). That test takes about 3 seconds to compile. (with the old map)
Louis Dionne
@ldionne
Jan 06 2016 21:22
Hmm, I’d have to take a closer look. I’m neck deep until next Sunday, after which I’ll have more time to look at this.
Jason Rice
@ricejasonf
Jan 06 2016 21:23
np
Louis Dionne
@ldionne
Jan 06 2016 21:23
Sorry, but I’m taking the plane tomorrow morning and I have a bunch of fires to put out.
But 3 seconds is certainly better than I would have expected. With a different map implementation or design, we should be able to reduce this. We’ll talk about this when I’m back, as it’s 100% related to your pull request. BTW, in the meantime, you might want to take a look at this.
I’m thinking more and more that the right way to go is in fact to use a hash-based map. The hash would be a type, not an integer, however. And then we would linear-search in each bucket, which could be a tuple.
This way, we would get O(1) lookup for hana::type, hana::string and basically any other singleton type, by design.
Louis Dionne
@ldionne
Jan 06 2016 21:28
Just keep this idea around in your head, and we’ll discuss it further if you want.
Jason Rice
@ricejasonf
Jan 06 2016 22:14
Yes, I look forward to it.