Sorry if I'm a bit lost.
I've recently started learning about different programming language paradigms and I found that all texts presuppose that all functions written in a programming language are curriable.
I haven't seen any proof of this and after looking for a while I found information about cartesian closed categories. My knowledge of mathematics is quite limited so I don't know if this is applied to, well, everything that can be done with a turing machine. My guess is that something like this is proven (or maybe it's obvious and my knowledge is too limited). Thank you in advance.
I tried to find some answers in Google but I'm out of luck.
It's difficult to answer this question without a context. Currying means that a function that takes a pair of argumenst is equivalent to a function of one argument that returns a function of the second argument. So, obviously, in programming languages in which functions are not first-class citizens, currying makes no sense, since you can't return a function. In functional languages, on the other hand, currying is built in from the get go. In lambda calculus where everything is a function, the pair itself is defined as a function returning a function.
There is an isomorphism between curried and uncurried functions. For example in Haskell via
curry :: ((a, b) -> c) -> a -> b -> c
curry f x y = f (x, y)
uncurry :: (a -> b -> c) -> ((a, b) -> c)
uncurry f p = f (fst p) (snd p)
such that
curry . uncurry = uncurry . curry = id
All properties of a function carry over via this isomorphism. In particular, if function f is (non)computable so is curry f and vice versa.
Note, whether a particular programming language is able to express the idea of currying is a different question. For example in pure lambda calculus there are only curried functions and no syntax for uncurried ones. Languages without support for higher order functions (e.g. the C language) make it hard (if not impossible) to write curried functions.
I understand that in previous versions of Arrow-Kt was an instance of the Applicative typeclass. In the current version 1.0.x, most typeclasses are no longer present/visible (to make the library more accessible, I presume?).
There are some excellent explanations why an error accumulating Validation data type can't be a Monad, for instance Haskell 1 and Haskell 2 and also Scalaz, Cats or arrow-kt. Hoogle also states that
Furthermore, the Monad and Applicative operations should relate as follows:
pure = return
m1 <*> m2 = m1 >>= (x1 -> m2 >>= (x2 -> return (x1 x2)))
My problem is that I can't see an instance of the Applicative Functor instance in the current implementation of Validated in arrow-kt. More precisely, I don't see an ap function anywhere:
(<*>) :: Applicative f => f (a -> b) -> f a -> f b
my intuition tells me that the zip function behaves somewhat similar to a map/ap composition
Haskell/Purescript:
Person <$> validateName first <*> validateName last <*> validateAge age
Kotlin with arrow-kt:
validateName(first).zip(validateName(last), validateAge(age), ::Person)
is zip an ap in disguise? Anything else I might be missing in my reasoning?
Like #LordRaydenMK has already mentioned in a comment zip is ap in disguise to be more in line with the Kotlin Standard Library.
Another strong reason for not having ap in Kotlin is because currying is not 1st class supported by Kotlin as it is in Haskell, and we cannot define multiple parameter lists like in Scala. So far that reason ap is actually quite cumbersome to use, and not user-friendly at all.
So for the sake of user-friendliness, being more idiomatic in Kotlin and decreasing the learning curve Arrow decided to remove ap and offer zip instead.
I would like to make a function that given a function type (e.g. String -> Nat -> Bool), would return a list of types corresponding to that function type (e.g. [String, Nat, Bool]). Presumably the signature of such a function would be Type -> List Type, but I am struggling to determine how it would be implemented.
I don't believe it could be done in general, because you cannot patter-match on functions. Neither can you check for the type of a function. That is not what dependent types are about. Just like in Haskell or OCaml the only thing you can actually do with a function is apply it to some argument. However, I devised some trick which might do:
myFun : {a, b : Type} -> (a -> b) -> List Type
myFun {a} {b} _ = [a, b]
Now the problem is that a -> b is the only signature that would match any arbitrary function. But, of course it does not behave the way you'd like for functions with arity higher than one:
> myFun (+)
[Integer, Integer -> Integer] : List Type
So some sort of recursive call to itself would be necessary to extract more argument types:
myFun : {a, b : Type} -> (a -> b) -> List Type
myFun {a} {b} _ = a :: myFun b
The problem here is that b is an arbitrary type, not necessarily a function type and there is no way I can figure out to dynamically check whether it is a function or not, so I suppose this is as much as you can do with Idris.
However, dynamic checking for types (at least in my opinion) is not a feature to be desired in a statically typed language. After all the whole point of static typing is to specify in advance what kind of arguments a function can handle and prevent calling functions with invalid arguments at compile time. So basically you probably don't really need it at all. If you specified what you grander goal was, someone would likely have shown you the right way of doing it.
I'm studying Haskell these days, and got a idea using function like OOP method.
First, define a operator as below:
(//) :: a -> (a -> b) -> b
x // f = f x
As you can see, this operator reverses the order of function f and argument x then applies it. For example, equals can be defined as:
equals :: Eq a => a -> a -> Bool
equals = \x -> \y -> x == y
comparison = (1 + 2) // equals 3 -- True
Now here is my question. Is it good approach using Haskell function like OOP method? That means inversion of function and (first) argument is good or not.
UPDATE
Here is the case of backtick(`) is not available.
data Person = Person { name :: String }
myself = Person "leafriend"
then
> name myself
"leafriend"
> myself // name
"lefirend"
> myself `name`
ERROR - Syntax error in expression (unexpected end of input)
What you have written is merely a matter of style. (It seems rather cruel to C/Java programmers to use // as an operator, though.) I would discourage using this for a few reasons, mainly because:
It's not idiomatic Haskell, and will confuse any Haskellers trying to read your code
You shouldn't think of Haskell as you would think of an OOP language
If you're trying to make Haskell look more like your favorite OOP language, you're doing it wrong. Haskell is meant to look like math: kind of lisp-y, with prefix function application, but also with infix functions and operators available.
Suppose I am defining a Haskell function f (either pure or an action) and somewhere within f I call function g. For example:
f = ...
g someParms
...
How do I replace function g with a mock version for unit testing?
If I were working in Java, g would be a method on class SomeServiceImpl that implements interface SomeService. Then, I'd use dependency injection to tell f to either use SomeServiceImpl or MockSomeServiceImpl. I'm not sure how to do this in Haskell.
Is the best way to do it to introduce a type class SomeService:
class SomeService a where
g :: a -> typeOfSomeParms -> gReturnType
data SomeServiceImpl = SomeServiceImpl
data MockSomeServiceImpl = MockSomeServiceImpl
instance SomeService SomeServiceImpl where
g _ someParms = ... -- real implementation of g
instance SomeService MockSomeServiceImpl where
g _ someParms = ... -- mock implementation of g
Then, redefine f as follows:
f someService ... = ...
g someService someParms
...
It seems like this would work, but I'm just learning Haskell and wondering if this is the best way to do this? More generally, I like the idea of dependency injection not just for mocking, but also to make code more customizable and reusable. Generally, I like the idea of not being locked into a single implementation for any of the services that a piece of code uses. Would it be considered a good idea to use the above trick extensively in code to get the benefits of dependency injection?
EDIT:
Let's take this one step further. Suppose I have a series of functions a, b, c, d, e, and f in a module that all need to be able to reference functions g, h, i, and j from a different module. And suppose I want to be able to mock functions g, h, i, and j. I could clearly pass the 4 functions in as parameters to a-f, but that's a bit of a pain to add the 4 parameters to all the functions. Plus, if I ever needed to change the implementation of any of a-f to call yet another method, I'd need to change its signature, which could create a nasty refactoring exercise.
Any tricks to making this type of situation work easily? For example, in Java, I could construct an object with all of its external services. The constructor would store the services off in member variables. Then, any of the methods could access those services via the member variables. So, as methods are added to services, none of the method signatures change. And if new services are needed, only the constructor method signature changes.
Why use unit testing when you can have Automated Specification-Based Testing? The QuickCheck library does this for you. It can generate arbitrary (mock) functions and data using the Arbitrary type-class.
"Dependency Injection" is a degenerate form of implicit parameter passing. In Haskell, you can use Reader, or Free to achieve the same thing in a more Haskelly way.
Another alternative:
{-# LANGUAGE FlexibleContexts, RankNTypes #-}
import Control.Monad.RWS
data (Monad m) => ServiceImplementation m = ServiceImplementation
{ serviceHello :: m ()
, serviceGetLine :: m String
, servicePutLine :: String -> m ()
}
serviceHelloBase :: (Monad m) => ServiceImplementation m -> m ()
serviceHelloBase impl = do
name <- serviceGetLine impl
servicePutLine impl $ "Hello, " ++ name
realImpl :: ServiceImplementation IO
realImpl = ServiceImplementation
{ serviceHello = serviceHelloBase realImpl
, serviceGetLine = getLine
, servicePutLine = putStrLn
}
mockImpl :: (Monad m, MonadReader String m, MonadWriter String m) =>
ServiceImplementation m
mockImpl = ServiceImplementation
{ serviceHello = serviceHelloBase mockImpl
, serviceGetLine = ask
, servicePutLine = tell
}
main = serviceHello realImpl
test = case runRWS (serviceHello mockImpl) "Dave" () of
(_, _, "Hello, Dave") -> True; _ -> False
This is actually one of the many ways to create OO-styled code in Haskell.
To follow up on the edit asking about multiple functions, one option is to just put them in a record type and pass the record in. Then you can add new ones just by updating the record type. For example:
data FunctionGroup t = FunctionGroup { g :: Int -> Int, h :: t -> Int }
a grp ... = ... g grp someThing ... h grp someThingElse ...
Another option that might be viable in some cases is to use type classes. For example:
class HasFunctionGroup t where
g :: Int -> t
h :: t -> Int
a :: HasFunctionGroup t => <some type involving t>
a ... = ... g someThing ... h someThingElse
This only works if you can find a type (or multiple types if you use multi-parameter type classes) that the functions have in common, but in cases where it is appropriate it will give you nice idiomatic Haskell.
Couldn't you just pass a function named g to f? As long as g satisfies the interface typeOfSomeParms -> gReturnType, then you should be able to pass in the real function or a mock function.
eg
f g = do
...
g someParams
...
I have not used dependency injection in Java myself, but the texts I have read made it sound a lot like passing higher-order functions, so maybe this will do what you want.
Response to edit: ephemient's answer is better if you need to solve the problem in an enterprisey way, because you define a type containing multiple functions. The prototyping way I propose would just pass a tuple of functions without defining a containing type. But then I hardly ever write type annotations, so refactoring that is not very hard.
A simple solution would be to change your
f x = ...
to
f2 g x = ...
and then
f = f2 g
ftest = f2 gtest
If the functions you depend on are in another module then you could play games with visible module configurations so that either the real module or a mock module is imported.
However I'd like to ask why you feel the need to use mock functions for unit testing anyway. You simply want to demonstrate that the module you are working on does its job. So first prove that your lower level module (the one you want to mock) works, and then build your new module on top of it and demonstrate that works too.
Of course this assumes that you aren't working with monadic values, so it doesn't matter what gets called or with what parameters. In that case you probably need to demonstrate that the right side effects are being invoked at the right time, so monitoring what gets called when is necessary.
Or are you just working to a corporate standard that demands that unit tests only exercise a single module with the whole rest of the system being mocked? That is a very poor way of testing. Far better to build your modules from the bottom up, demonstrating at each level that the modules meet their specs before proceeding to the next level. Quickcheck is your friend here.
You could just have your two function implementations with different names, and g would be a variable that is either defined to be one or the other as you need.
g :: typeOfSomeParms -> gReturnType
g = g_mock -- change this to "g_real" when you need to
g_mock someParms = ... -- mock implementation of g
g_real someParms = ... -- real implementation of g