functor

问题 Is there any performance advantage to be had when using template parameters with static member functions instead of functor-style predicates?? For instance, a functor-style sort interface is typically something like this: template <typename _Type, typename _Pred> void sort ( RandomAccessIterator first, RandomAccessIterator last , _Pred less_than ) { // actual sorting code here, calling less_than()... } You could do something more like this, and require that _Pred contained a static member

问题 I try to create a general wrapper function which takes any function as argument and also their parameters. Just something like the std::thread constructor. My current code is: #include <iostream> using namespace std; template<typename FUNCTION, typename... ARGS> void wrapper(FUNCTION&& func, ARGS&&... args) { cout << "WRAPPER: BEFORE" << endl; auto res = func(args...); cout << "WRAPPER: AFTER" << endl; //return res; } int dummy(int a, int b) { cout << a << '+' << b << '=' << (a + b) << endl;

问题 This answer from a Category Theory perspective includes the following statement: ...the truth is that there's no real distinction between co and contravariant functor, because every functor is just a covariant functor. ... More in details a contravariant functor F from a category C to a category D is nothing more than a (covariant) functor of type F : C op →D, from the opposite category of C to the category D. On the other hand, Haskell's Functor and Contravariant merely require fmap and

问题 This answer from a Category Theory perspective includes the following statement: ...the truth is that there's no real distinction between co and contravariant functor, because every functor is just a covariant functor. ... More in details a contravariant functor F from a category C to a category D is nothing more than a (covariant) functor of type F : C op →D, from the opposite category of C to the category D. On the other hand, Haskell's Functor and Contravariant merely require fmap and

问题 Monads get fmap from Functor typeclass. Why comonads don't need a cofmap method defined in a Cofunctor class? 回答1: Functor is defined as: class Functor f where fmap :: (a -> b) -> (f a -> f b) Cofunctor could be defined as follows: class Cofunctor f where cofmap :: (b -> a) -> (f b -> f a) So, both are technically the same, and that's why Cofunctor does not exist. "The dual concept of 'functor in general' is still 'functor in general'". Since Functor and Cofunctor are the same, both monads

问题 From my background in imperative programming, I'm accustomed to doing for (i = 0; i < 1000000; i++) { for (j = i + 1; j < 1000000; j++) { doSomething(array[i], array[j]) } } to examine all unique pairs in a million element array. doSomething is some operation that yields trivial results on diagonal and symmetric or antisymmetric results off diagonal--- that's why I only want to work on the upper triangle. (There's a minor variant of this where the i == j case is interesting; that's easy to

问题 While reading the description of Functors on this blog: https://hseeberger.wordpress.com/2010/11/25/introduction-to-category-theory-in-scala/ there is a generic definition of Functor and a more specific one: trait GenericFunctor[->>[_, _], ->>>[_, _], F[_]] { def fmap[A, B](f: A ->> B): F[A] ->>> F[B] } trait Functor[F[_]] extends GenericFunctor[Function, Function, F] { final def fmap[A, B](as: F[A])(f: A => B): F[B] = fmap(f)(as) } Clearly this means Functors can be used with other higher

问题 This is a general question, not tied to any one piece of code. Say you have a type T a that can be given an instance of Monad . Since every monad is an Applicative by assigning pure = return and (<*>) = ap , and then every applicative is a Functor via fmap f x = pure f <*> x , is it better to define your instance of Monad first, and then trivially give T instances of Applicative and Functor ? It feels a bit backward to me. If I were doing math instead of programming, I would think that I

问题 I have two vectors. One that actually holds the data (let's say floats) and one that holds the indices. I want to pass at nth_element the indices vector, but I want the comparison to be done by the vector that actually holds the data. I was thinking about a functor, but this provides only the () operator I guess. I achieved that by making the data vector a global one, but of course that's not desired. std::vector<float> v; // data vector (global) bool myfunction (int i,int j) { return (v[i]<v

问题 I looked at past discussion but could not see why any of the answers are actually correct. Applicative <*> :: f (a -> b) -> f a -> f b Monad (>>=) :: m a -> (a -> m b) -> m b So if I get it right, the claim is that >>= cannot be written by only assuming the existence of <*> Well, let's assume I have <*> . And I want to create >>= . So I have f a . I have f (a -> b) . Now when you look at it, f (a -> b) can be written as (a -> b) (if something is a function of x, y , z - then it's also a