beark/ftl

C++ template library for fans of functional programming

ftl's Issues

Should I first learn haskell adequately before using this library?

Hi, I'm putting this question here because I couldn't find a way to message you on GitHub.

First, I just want to say this library feels amazing!

Then, I'm wondering if I should get a good understanding of haskell first before jumping in this library?
I tried to write a calculator parser using FTL. The code looked amazing but it took me forever to figure out how to do certain things using FTL. I realized that I don't actually understand the concepts such as applicative functor or monad. I've only heard of these terms from reading articles talking about haskell.

I would love to use this amazing library as much as possible, but it seems my lack of understanding of haskell is hindering my progress. Would learning haskell first be necessary to use this library effectively? Or, perhaps there're some good websites out there which introduce the fundamental concepts of functional languages?

Thanks,

The fequal function

It was added for the unit tests. Are you sure that function doesn't return true for any pair of inputs >= 1.0f? Some quick experiments showed me that it does.

http://coliru.stacked-crooked.com/a/4b8e59043bdaf273

Asking since I've seen it being used with floats >= 1.0f, for example:

fequal((unary % binary)(2,2), 8)

within functional_tests.cpp, line 59. If the above is true, that line passes due to coincidence.

Any reason why the float comparison isn't something like a check for abs(x - y) < epsilon?

Contributing to ftl!

Hi @beark, not really an issue but I wasn't sure how to contact you otherwise. I am very interested in contributing to your project! I am experienced in C++ but lately I fell in love in Haskell so I thought that this would be a good way of learning Haskell and improving my C++, nice to see that you are using C++11!

If that is something that interests you please get back to me and I will be more than happy to help!

Thanks!

Clang 3.3's implementation of std::mem_fn is not const-friendly.

I like constexpr because I figure if a function object can be constexpr, then it definitely has no overhead because the compiler can optimize it away. Unfortunately, I the fallowing code doesn't compile with my version of clang:

#include <functional>
struct X{ int x; } x{0};
int main() {
    auto _x = std::mem_fn(&X::x);
    return [=](X x){ return _x(x); }(x);
}

$ clang++ test.cpp -std=c++11 -stdlib=libc++
test.cpp:9:26: error: no matching function for call to object of type 'const std::__1::__mem_fn<int X::*>'
        return [=](X x){ return _x(x); }(x);
                                ^~
/usr/include/c++/v1/functional:882:11: note: candidate function not viable: 'this' argument has type 'const std::__1::__mem_fn<int X::*>', but method is not
      marked const
          operator() (_ArgTypes&&... __args)
          ^
test.cpp:9:9: error: cannot initialize return object of type 'int' with an rvalue of type 'void'
        return [=](X x){ return _x(x); }(x);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
$ clang -v
Ubuntu clang version 3.3-5ubuntu4 (branches/release_33) (based on LLVM 3.3)
Target: x86_64-pc-linux-gnu
Thread model: posix

It does compile and produce the expected result when I don't use the -stdlib=libc++ flag.

I noticed this while trying to implement composition on member function pointers and overloading function objects (http://cpp-next.com/archive/2012/09/unifying-generic-functions-and-function-objects/), but also noticed that most of the library does not use constexpr, so I figure that either I should remove constexpr statements and use to_functor to avoid the problem, or implement my own wrapper for member pointers, depending on which option suites the goals of the library better.

Any releases planned?

Hello!

Are you planning on marking any commits as releases on GitHub?

Alois Type erasure

Hi, maybe this rant is premature, but I was skimming through the library and found it uses type erasure for functions. I was wondering why this is necessary, and why not the full type can be preserved to avoid tHe indirection and allow complete inlining. I am using functional techniques for code that runs at about 1mio operations/s, so the use of type erasure does not seem an option for me and may make it impossible for me to use ftl.

monoid defined in_terms_of_plus: typo

Hi,

there is a typo in

    template<typename M>
    struct deriving_monoid<in_terms_of_plus<M>> {
        static constexpr M id() noexcept(noexcept(M(0))) {
            return M();
        }

It should be either noexcept(M(0)) and return M(0) or noexcept(M()) and return M().

What do you intended?

monoid defined in_terms_of_plus: are 0 and operator+ the good abstraction?

I wonder if 0 and operator+() is the appropriated abstraction. What about an Additive concept that defines zero<M>() -> M and 'add(M, M) -> M'?

Clang 3.4 and gcc 4.9

I do not know of what compatibility goals this library has except that travis ci is set up for clang 3.3 and gcc 4.8. I also do not know that this is the most opportune time to upgrade, but I thought I'd make this "issue" to discuss some of the pros, cons, and steps to adopting the C++1y features in these two releases.

One example of a c++1y feature I required: I went through ftl/include/memory.h and added a specialization for std::unique_ptr for everything std::shared_ptr had a specialization. I discovered that the definition of deriving_map<in_terms_of_bind<M>> didn't work because unique_ptrs are move-only. gcc 4.8 can do this, but it requires 3.4 of clang.

See: splinterofchaos/ftl@5934a44

To summarize the language features allowed by both gcc 4.9 and clang 3.4 that I think might benefit ftl:

Feature	Usage
Generalized lambda init-capture	(See above)
Polymorphic lambdas	Not sure if this is useful to ftl because they cannot properly forward, but they can certainly apply value semantics properly.
auto/decltype(auto) for declarations and functions.	Simplify some of the code, removing long, messy typedefs to determine a return type.
Use of [[depricated]].	Just in case.

And the library additions:

Feature	Usage
std::integer_sequence	Simplify some of the tuple.h code. Standard solution to ftl::seq, but with a few more bells and whistles.
std::experimental::optional	Basically, std::maybe. (Not sure if gcc 4.9 has this.)
operator() overload for std::integral_constant.	std::is_same<T,U>() vs. std::is_same<T,U>::value.
SFINAE std::result_of	(Self explanatory.)

gcc has yet to implement variable templates, relaxed constexprs, or TypeTraitsRedux, to name a few.

Only upgrading to clang 3.4 would enable auto for function return types, which gcc 4.8 implements, although gcc 4.8 may not work for every situation clang does because it's based on an out-of-date proposal.

clang 3.4 would allow experiments with variable templates, but break gcc compatibility.

I did have to modify some of the code that I submitted in order to get clang 3.4 to compile my master: splinterofchaos/ftl@749805a

Since the new releases of clang and gcc might not be readily available to everyone, it might be best to maintain backwards compatibility. In that case, both compilers define the macro __cplusplus as 201103 when in c++11 mode, and a higher number for c++1y (though clang and gcc use 201305 and 201300, respectively, for c++1y mode). Furthermore, since clang uses a slightly higher number, and has slightly more features, this macro can be used to distinguish between what gcc and clang can handle.

can not compile with visual studio 2017

hi, thank you for the library, but I can not compile the library with visual studio 2017,
would you pls help me? thank you !

Truly generalised Functor, Applicative, and Monad

Presently, functions generalised to the above mentioned concepts must be implemented twice to be truly general. This is because some data types match the signature

template<template<typename> class F, typename A, typename B>
void example(F<A> a, F<B> b);

while others instead match

template<
    template<typename,typename...> class F,
    typename A,
    typename B,
    typename...Ts>
void example(F<A,Ts...> a, F<B,Ts...> b);

Something should be worked out to solve this, having to write duplicates of every function is not acceptable.

Portable?

I noticed you aren't supporting VC++. Could you elaborate as to the difficulties?