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
Louis Dionne
@ldionne

if you want, I can add tests with lvalues to create explosions

Yes, that would be nice.

Right now, I am inclined to think that we should allow predicates to return anything that can be converted to bool, as currently specified.
It’s more flexible, and also more consistent with the fact that an int is a Logical.
So it makes sense to say if(3, xxx, yyy).
Jason Rice
@ricejasonf
Which is more favorable, using std::declval<Pred>() or having a Pred const& pred member? hana::partition uses the former and hana::filter the latter. I figure I could make them consistent while I'm at it, unless you object.
Those are the only two with that problem with the predicate returning a const& btw
Actually idk, it looks pretty deliberate. I'll refrain from changing it.
Louis Dionne
@ldionne

Which is more favorable, using std::declval<Pred>() or having a Pred const& pred member? hana::partition uses the former and hana::filter the latter. I figure I could make them consistent while I'm at it, unless you object.

I have no preference. Off the top of my head, I can't think of a reason to use a Pred const& member over std::declval, except for the need to include <utlity> to use std::declval. But <utility> is already included everywhere anyway, so this isn't a strong reason.

Those are the only two with that problem with the predicate returning a const& btw

Cool!

Actually idk, it looks pretty deliberate. I'll refrain from changing it.

What looks deliberate? The usage of Pred const& over std::declval()? It probably just happened that way, because both algorithms were implemented at different times.

Jason Rice
@ricejasonf
It looked "deliberate" because filter.hpp actually had both (lift_or_empty uses declval), so I figured maybe there was a reason I didn't see. I just left it alone.
Louis Dionne
@ldionne
That’s fine.
Jason Rice
@ricejasonf
@ldionne Do you recommend any specific approach to named parameters?
Louis Dionne
@ldionne
Use a hana::map from arguments to values.
Represent the names of the arguments however you prefer, compile-time strings or types or whatever else.
Then, define an operator to create pairs (syntactic sugar).
template <char ...s>
struct NamedParameter {
    template <typename Value>
    auto operator=(Value const& v) {
        return hana::make_pair(*this, v);
    }
};

template <char ...s>
auto operator""_param() {
    return NamedParameter<s...>{};
}

int main() {
    some_function("a"_param = 3, "b"_param = 4, ...);
}
Something along those lines. Then, some_function may create a hana::map to search through its arguments.
Louis Dionne
@ldionne
It’s arguably annoying to have to create hana::map by hand inside some_function, so you might want to have a wrapper that does it automatically. Something like
auto wrapper = [](auto function) { 
    return [](auto ...args) { 
        return function(hana::make_map(args...)); 
    }; 
};
You can define function = [](auto args) { use(args[“a”_param]); }. You’ll need to make NamedParameter Comparable.
Jason Rice
@ricejasonf
:heart_eyes: nice! ty
that's an interesting way to initialize a map
Louis Dionne
@ldionne
Yes, quite. I used something similar for a library I was writing for a client recently.
Works well, but it is annoying to have to copy the arguments into the map.
The restriction of not having references in containers is a f*cking pain, but I don’t see an easy way around it. Just like std::vector won’t allow for references.
Jason Rice
@ricejasonf
ah.. so it is not zero cost
Louis Dionne
@ldionne
Well, you can move-in the arguments and it should be pretty-much zero cost. But it’s not zero cost strictly-speaking.
But if you pass arrays as named parameters, they’ll have to be moved (which may be inefficient).
Or you can store the arguments with std::reference_wrappers, but then you’ll have to use args[“a”_param].get() inside the function.
Jason Rice
@ricejasonf
Would it be possible to add that auto operator= to type and integral_constant?
This message was deleted
Jason Rice
@ricejasonf
You mentioned some things about improving map before. I would like to discuss it, when you are not too busy.
Louis Dionne
@ldionne

Would it be possible to add that auto operator= to type and integral_constant?

You mean to create pairs? I think that's clearly out of Hana's scope, since Hana is a general purpose library, not a named parameter library. The right approach would be for you to create wrappers over type and integral_constant. Or more generally, I would probably do something like

template <typename Param>
struct param_t {
    // define operator=
};

template <typename Param>
constexpr param_t<Param> param{};

Then, you can use the thing as

f(param<hana::int_<3>> = "three", param<hana::type<int>> = "int", ...);

The syntactic overhead is very reasonable, and it clearly says what it's doing. Just my .02.

You mentioned some things about improving map before. I would like to discuss it, when you are not too busy.

I'd be happy to discuss it. I'll try to put my thoughts on paper and I'll create an issue documenting them. Then, we can talk about it either here or on GitHub. Sounds reasonable?

Jason Rice
@ricejasonf
:thumbsup:
Jason Rice
@ricejasonf
About the param thing, yeah, creating a wrapper is simple enough and I will do that, but I was speaking to constructing maps in general. (nbd of course)
constexpr auto foo = hana::type_c<int>;
constexpr auto bar = hana::type_c<double>;

hana::make_map(
    foo       = "foo",
    bar       = "bar",
    "foo"_s   = "foo",
    "bar"_s   = "bar",
    5_c       = "five",
    42_c      = "forty-two"
);
that's probably not that useful though
Louis Dionne
@ldionne

But then the following fails, because assignment is not what we expect it to be:

hana::tuple<int, int, hana::type<char>> t{1, 2, {}};
hana::tuple<int, int, hana::type<char>> u{3, 4, {}};
t = u;

Actually, it will even compile but fail to do the right thing. Since type, integral_constant & al are stateless this is OK strictly speaking (assignment has no effect anyway), but I really think this is conceptually wrong.

Jason Rice
@ricejasonf
yeah I guess that would be an abuse :sweat_smile:
Louis Dionne
@ldionne
@ricejasonf See #223 regarding hana::map optimizations.
@ricejasonf It’s not an easy one to tackle, but if you’re willing to give it a shot I’ll provide guidance and help as needed.
Btw, this is likely the single most important improvement that can be done to Hana right now. But it’s a chunk of work.
Jason Rice
@ricejasonf
@ldionne Yes, I definitely want to take a crack at this. :D I'll have to do some digging as to how you are automating benchmarks and their results.
Louis Dionne
@ldionne
Just ask if you need guidance.
Jason Rice
@ricejasonf
Do you know how to get cmake to look for ruby in /usr/local/bin ?
Louis Dionne
@ldionne
Hmm, it should probably look in that place on its own.
1 minute
Jason Rice
@ricejasonf
oh sorry.. I had to remove CMakeCache.txt I think
I was thinking there was a RUBY_ROOT option or something
Louis Dionne
@ldionne
I don’t see any RUBY_ROOT option in the documentation of the FindRuby.cmakemodule. If it does not work ,you can try adding /usr/local/bin to CMAKE_FIND_ROOT_PATH.
Jason Rice
@ricejasonf
heh.. I apt-get remove --purge ruby'd and then realized it was probably just stuck in CMakeCache.txt.
Louis Dionne
@ldionne
Does it work now?
Jason Rice
@ricejasonf
yep