Contributing to ftl! about ftl HOT 7 CLOSED

Hey!
I definitely wouldn't mind contributions. At the moment I'm on holidays, so can't really help out much in getting to know the code or coming up with some suitable task. Either you can hack away some on your own in a fork, or you'll have to wait until after Christmas for me to return.

If you go for the former, here are a couple of the things I mean to do that you could take a look at if you like (in ascending order of difficulty):

• Improve test coverage: look at existing tests and find code paths they don't cover, e.g. perhaps there's an rvalue version of some function that is never tested but the regular one is
• Implement swap for either
• Generalise the currying base classes (_dtl::curried_binf, _dtl::curried_ternf) so there is just one for n-ary function objects. Then make that a public part of the library.

from ftl.

Hi, I'm in kinda the same position as @mortal2god. On your last note, I've compiled your library with this change (https://gist.github.com/splinterofchaos/7992250), which is what I imagine you mean, but I'm not sure how to write a test for if it does what you want.

I didn't see an actual _dtl::curried_binf, if that's what you meant.

from ftl.

Well, that wasn't quite what I meant, though I certainly appreciate the effort. Have a look at prelude.h:483 and on to see the structs I referred to. Basically I want to offer users of FTL a way of effortlessly currying their own function objects, like what is done with fmap, foldl, etc.

Also, either as a separate thing or as part of the above, allowing ftl::function to be called in all of these ways:

function<int(int,int,int)> f = ...;
f(1)(1)(1)
f(1)(1,1)
f(1,1)(1)
f(1,1,1)

Only some of these are currently valid.

I'm also fine if you just go wild experimenting with some random pet type class or structure and see if it can somehow fit in. Like lenses, continuations, traversables, or some other neat thing. Even if it turns out too clumsy or even useless in C++, you will hopefully have had fun arriving there!

from ftl.

Hi @beark and @splinterofchaos. @beark I will start experimenting with what you said but I will wait until you return back from your holidays to come up with a development plan. I will spend some time getting to know the code and when you get back we can talk again. Testing coverage seems like a good way of getting a code overview!

Thanks enjoy your holidays and talk to you soon!

PS: Let me know if you want my personal email or something!

from ftl.

Also, either as a separate thing or as part of the above, allowing ftl::function to be called in all of these ways:

Well, modifying _dtl::curried, I was able to make those tests with ftl::function work. https://gist.github.com/splinterofchaos/8008127

As for _dtl::curried_binf and _dtl::curried_ternf, the advantage to them seems to be that they don't require a strict function signature, so they should work polymorphically. I could use a fairly similar technique and make a curried_n<N,F> type and write a partial application type where calling it with n arguments produces a curried<N-n,PartialF> when n<N. In fact, apparently I tried to do that a while back (https://gist.github.com/splinterofchaos/4606174), the biggest difference being I didn't think to have it return a curried<N-n,PartialF>.

If that's what you want, then I'll get coding and send you a pull request. My biggest confusion on this is I don't see where it's used or how to test it. Perhaps you mean to add an ftl::curry overload that accepts an integral template parameter representing arity?

from ftl.

So, your first part looks good. Feel free to do a pull request if/when you're happy with it yourself.

As for the rest of it... Yeah, you're right about the polymorphism etc. I guess I wasn't really very clear, sorry about that. It's annoying to type this on a phone.

My idea was basically that the unified object you inherit from would accept a type signature, except it would support special types that are actually type variables. I'm not sure how sound it would work out, it's just a thing I've been meaning to experiment with. Basically, usage would look something like:

struct add : fn_object<add, Tvar<'n'>(Tvar<'n'>, Tvar<'n'>)> { ... };

And it would generate curried call operators (well, one in the above case) while keeping the compile-time polymorphism. However, it might be that this cannot be nicely accomplished, or perhaps ends up too complex. Though if it does work out nicely it could be used for a lot of neat things, allowing many higher-order functions to work out parameter types and such in more cases.

If this sounds too hard or useless, or turns out useless or too hard to use, then no worries. It's just something I've meant to experiment with and see where it goes.

Your suggestion of curried<N,F> seems like a useful compromise or alternative though, so you could go for that too. Initially, I guess it would be used by fmap, foldMap, mbind, etc and tested where they are. Not a huge improvement, but arguably slightly better than the current state--if I understood you correctly.

Possibly the greatest contribution at this point would be to write something that uses FTL and note what works, what doesn't, what's missing, what's confusing, etc. But it's up to you.

from ftl.

I've now added a contribution page to the wiki that should hopefully serve as a starting point for people wishing to contribute. Closing the issue.

from ftl.