These are chat archives for boostorg/hana

22nd
Nov 2017
Andreas Pokorny
@APokorny
Nov 22 2017 08:55
yeah I found that too, but they construct the graph at runtime.. I dont need it there..
Andreas Pokorny
@APokorny
Nov 22 2017 09:09
hm can I make an arbitrary variadic template fulfill the iteratable concept of hana..
and just do all operations on template<typename ...Fs> struct foo{};
hmm maybe that makes no sense.. since I cannot call any predicates..
or rather would have to do that with declval..
Jason Rice
@ricejasonf
Nov 22 2017 20:25
What are you trying to do exactly? Maybe a code snippet would explain it better.
Andreas Pokorny
@APokorny
Nov 22 2017 20:51
right now I try to figure out whether i should try to back my DSL structures with hana tuple and type_c
Andreas Pokorny
@APokorny
Nov 22 2017 21:00
I havent played with writing DSLs for some time .. last time was with C++03.. now with gcc/clangs compile time string literals you can easily collect far more information at compile time
but to harness that I have to be able to analyze the graph
The dsl constructs a graph of computational nodes
to evaluate the graph I want to traverse it in the right order and also parallelize the evaluation if there are multiple graphs..
Andreas Pokorny
@APokorny
Nov 22 2017 21:15

slightly simplified:

template<char...Name>
struct node_name {};

template<char...Name>
struct input {};

template<char...Name>
struct output {};

template<typename Name, typename Type>
struct node {};

template<typename OutNode, typename Output, typename InNode, typename Input>
struct connection {};

template<typename ...Elements>
struct model {};

...

Andreas Pokorny
@APokorny
Nov 22 2017 21:22
each parameter of model is either connection or node.. the order is define by the expression tree
Jason Rice
@ricejasonf
Nov 22 2017 21:30
Are all those types really empty? I do something similar, but I've begun refactoring it to use Boost.Mp11.
By similar I mean I take a bunch of tag-like meta information and use it to generate types for different purposes.
Andreas Pokorny
@APokorny
Nov 22 2017 21:33
at the moment yes.. I might want to store init parameters in node.. but I am not sure yet whether those would be needed..
so it seems that I could hook into the tag dispatching of hana and use the algorithms then
but I have to implement a lot of them myself for that.. hmm maybe I should just use hana tuple instead
Jason Rice
@ricejasonf
Nov 22 2017 21:36
It's not that hard. I even implemented hana::Sequence, but it has the precondition that the types be stateless and default constructible (ie empty)
Andreas Pokorny
@APokorny
Nov 22 2017 21:48
what was your motivation to implement a hana concept?
Jason Rice
@ricejasonf
Nov 22 2017 21:51
I was already using Hana and needed a way to transform types. In general, implementing its concepts is very useful for generic programming.
... and you get a lot of algorithms for free.
Andreas Pokorny
@APokorny
Nov 22 2017 22:00
i mean .. why not stick with tuple?
Jason Rice
@ricejasonf
Nov 22 2017 22:01
Pure type programming is a bit faster at compile-time
It gets better and better as the compilers get faster, but hana::tuple has to manage the run-time state of objects which adds to the build time.
That's why I've been refactoring my "empty" stuff to use mp11 because the algorithms don't worry about run-time state either.
Andreas Pokorny
@APokorny
Nov 22 2017 22:08
oh nice benchmark then I will continue on that path
Jason Rice
@ricejasonf
Nov 22 2017 22:12
Jason Rice
@ricejasonf
Nov 22 2017 22:21
@ldionne Has anyone explored the idea of a weak function alias in C++?
Jason Rice
@ricejasonf
Nov 22 2017 22:26
err "callable" alias
invocation alias :P
Alastair Rankine
@randomphrase
Nov 22 2017 22:30
@ricejasonf what do you mean by that?
Jason Rice
@ricejasonf
Nov 22 2017 22:32
So.. in TMP they use type aliases to get cheap transformations without creating an intermediate type...
If the same could be done with a function invocation that could eliminate a lot of unnecessary stuff like forwarding, noexcept correctness propagation, a function call.