It's a rather general purpose question and not specific to any one language. I don't quite understand the point behind passing a function as an argument to another function. I understand that if a function, say, foo1() needs to use some result returned by another function foo2(), why can't the values returned/updated by foo2() be passed to foo1() as is? Or in another scenario, why can't the foo2() be called within foo1() with its results being used therein?
Also what happens under the hood when a foo2() is passed as an argument to foo1()? Is foo2() executed prior to foo1()?
Generally speaking, you pass a function foo2 to a function foo1 in cases where multiple evaluations of foo2 will be necessary - and you perhaps don't know in advance what parameters will be used for each call of foo2, so you couldn't possibly perform the calls yourself in advance.
I think that a sort() function/method on lists might be the best concrete example. Consider a list of People - you might reasonably want to sort them alphabetically by name, or numerically by age, or by geographical distance from a given point, or many other possible orders. It would hardly be practical to include every such ordering as built-in options to sort(): the usual approach taken by languages is to allow the caller to provide a function as a parameter, that defines the ordering between items of the list.
There are many reasons:
Dependency injection: if you pass a method that in production will use a database call, and you use it with different parameters, you could substitute it with some mock when unit testing.
Map, filter, reduce: you could apply the same method to a list of parameters, to map it, filter it or reduce it.
Usually to provide callbacks, or to separate interface from implementation. Look up the following:
1. Dependency Injection,
2. Callbacks,
3. Anonymous Functions (aka Lambdas),
4. PIMPL
etc
Take a look at this book where it is used extensively in developing TDD with C:
https://www.amazon.co.uk/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X
Related
As per my understanding, partial functions are functions that are defined for a subset of input values.
So should I use partial functions for DAO's. For example:
getUserById(userId: Long): User
There is always an input userId which does not exists in db. So can I say it is not defined. And lift it when I call this function.
If yes where do I stop. Should I use partial functions for all methods which are not defined, say for null.
PartialFunction is used when function is undefined for some elements of input data (input data may be Seq etc.)
For your case Option is better choice: it says that return data may be absent:
getUserById(userId:Long):Option[User]
I would avoid using partial functions at all, because scala makes it very easy to call a partial function as though it were a total function. Instead it's better to use a function that returns Option as #Sergey suggests; that way the "partial-ness" is always explicit.
Idiomatic scala does not use null so I wouldn't worry about methods which are not defined for null, but certainly it's worth returning Option for methods which are only defined for some of their possible input values. Better still, though, is to only accept suitable types as input. E.g. if you have a function that's only valid for non-empty lists, it should take (scalaz) NonEmptyList as input rather than List.
I've read here about the difference between functions and methods in scala. It says that methods can be slightly faster than functions. But when passing a method m as an argument using m _, m is implicitly converted to a function.
Is the performance difference significant enough to ponder avoiding Functions when it is going to be a bottleneck in my program?
Is there a way to pass a method as an argument without converting it to a Function?
Kind of irrelevant to by 2. But in general, forget about performance, methods are more readable than function declarations. They might be a little faster in some situations from compiler optimizations, but:
You cannot pass a method as an argument without converting it to a function. A method is a special language construct, and not an object itself. You must use eta-expansion to convert it to one if you want to use it as an object.
No.
No. In the extremely rare case where this kind of microperformance was important, you'd want to pass the object that the method is on, and either modify the receiving function to accept that, or make the object implement one of the FunctionN interfaces so that it can be used as a function.
It makes just as much sense avoiding functions as it does avoiding other object allocations. There's nothing particularly special about them.
It's possible to pass and invoke methods directly using reflection, but the performance is going to be much worse than passing functions in the similar situation.
I'm trying to understand how the programming technique known as currying differs from an ordinary callback interface (such as the Observer/Observable interfaces in Java, or the classic Visitor design pattern).
I understand what currying is, I just don't understand why it's uniquely useful to the point that it requires its own terminology and language support.
Could someone explain a programming situation that is better solved by currying than by a callback method? What's the practical significance of the fact that currying uses a separate function for each argument?
[update:] to summarize the answers I got: currying comes part and parcel with the fact that functions are "first class" citizens, ie objects that can be created and passed around like any other object reference. This makes it possible to return a function from a function, in other words currying.
As for the reason why currying is useful, currying provides a syntax to let you concisely decorate function calls so that derived functions can be created with minimal boilerplate code overhead. Whereas in java you might create several overloaded or "wrapper" methods for each partial parameter set which ultimately invoke a master method containing all the parameters, currying provides a lighter syntax that lets you generate these "function wrappers" as needed in your code.
Currying and callbacks are two completely different technologies.
Callbacks are essentially a synonym for "passing a function to a function" (i.e. higher-order function that consumes a function); currying is a form of partial application, i.e. a function which isn't passed all of the parameters it expects returns a new function that only expects the free parameters.
Accordingly, they are not alternatives at all.
Currying is useful because it makes it much easier to concisely create functions that can be used as, for example, callbacks, or in a pointfree programme. It also means that you can, e.g. pass a callback to a function like map, and have a new function that applies your callback to every element of any list you care to pass to it.
Well, it's a point of language support.
In Java, for example, you can define all sorts of callback interfaces: one for parmeterless methods, one for methods with one argument, one for methods with two arguments, and so forth.
But wehn functions are first class citiziens, one does not need this: Single argument functions will do the job, because functions can be returned. Hence, one important interface in all "functional java" projects will be some interface of the form:
interface Fun<A,B> {
public B apply(A a);
}
or the like that covers this pattern.
I have been reading about methods and functions in Scala. Jim's post and Daniel's complement to it do a good job of explaining what the differences between these are. Here is what I took with me:
functions are objects, methods are not;
as a consequence functions can be passed as argument, but methods can not;
methods can be type-parametrised, functions can not;
methods are faster.
I also understand the difference between def, val and var.
Now I have actually two questions:
Why can't we parametrise the apply method of a function to parametrise the function? And
Why can't the method be called by the function object to run faster? Or the caller of the function be made calling the original method directly?
Looking forward to your answers and many thanks in advance!
1 - Parameterizing functions.
It is theoretically possible for a compiler to parameterize the type of a function; one could add that as a feature. It isn't entirely trivial, though, because functions are contravariant in their argument and covariant in their return value:
trait Function1[+T,-R] { ... }
which means that another function that can take more arguments counts as a subclass (since it can process anything that the superclass can process), and if it produces a smaller set of results, that's okay (since it will also obey the superclass construct that way). But how do you encode
def fn[A](a: A) = a
in that framework? The whole point is that the return type is equal to the type passed in, whatever that type has to be. You'd need
Function1[ ThisCanBeAnything, ThisHasToMatch ]
as your function type. "This can be anything" is well-represented by Any if you want a single type, but then you could return anything as the original type is lost. This isn't to say that there is no way to implement it, but it doesn't fit nicely into the existing framework.
2 - Speed of functions.
This is really simple: a function is the apply method on another object. You have to have that object in order to call its method. This will always be slower (or at least no faster) than calling your own method, since you already have yourself.
As a practical matter, JVMs can do a very good job inlining functions these days; there is often no difference in performance as long as you're mostly using your method or function, not creating the function object over and over. If you're deeply nesting very short loops, you may find yourself creating way too many functions; moving them out into vals outside of the nested loops may save time. But don't bother until you've benchmarked and know that there's a bottleneck there; typically the JVM does the right thing.
Think about the type signature of a function. It explicitly says what types it takes. So then type-parameterizing apply() would be inconsistent.
A function is an object, which must be created, initialized, and then garbage-collected. When apply() is called, it has to grab the function object in addition to the parent.
I had a doubt
I know that main difference between a function and procedure is
The function compulsory returns a value where as a procedure may or may not returns value.
But when we use a function of type void it returns nothing.
Can u people please clarify my doubt.
Traditionally, a procedure returning a value has been called a function (see below), however, many modern languages dispense with the term procedure altogether, preferring to use the term function for all named code blocks.
Read more at Suite101: Procedure, subroutine or function?: Programming terminology 101 - a look at the differences in approach and definition of procedures, subroutines and functions. http://www.suite101.com/content/procedure--subroutine-or-function--a8208#ixzz1GqkE7HjE
In C and its derivatives, the term "procedure" is rarely used. C has functions some of which return a value and some of which don't. I think this is an artefact of C's heritage where before the introduction of void in ANSI C, there was no way to not return a value. By default functions returned an int which you could ignore (can still) and might be some random number if no explicit return value was specified.
In the Pascal language family, the difference is explicit, functions return a value and procedures don't. A different keyword is used in each case for the definition. Visual Basic also differentiates with functions and subroutines(?).
Since we are talking about Objective-C, there are some further issues to confuse you. Functions associated with a class or object are known as "methods" (class methods and instance methods respectively).
Also, if we are being pedantic, you don't call Objective-C methods, you invoke them by sending a message to the object. The distinction is actually quite important because the message name (aka "selector") does not necessarily always refer to the same method, it can be changed at run time. This is fundamentally different to languages like Java and C++ where a particular method name for a particular class is really just a symbolic name for the address of the block of code constituting the body of the method.
Depending on the programming language, the distinction may be not so clear. Let's take a conservative language, Pascal:
procedure indeed has no return value. It is used for operations which do not have a return value, or have multiple return values. In the latter case, multiple arguments (the return-arguments or output-arguments) are passed by reference (using the var keyword) and their values are directly modified from inside the procedure. (Note that this latter case may not be considered good practice, depending on the circumstances).
function has a single return value, and usually we do not expect it to change the value of any of its arguments (which arguments may then be passed by value, or via the const keyword). Multiple return values may be returned by bundling them into a record.
C or Java does not distinguish syntactically, so a function of return type void can be thought of as a procedure. Scala distinguished between them by the presence of an equals sign between the method head and method body.
Generally, no matter how an actual language calls its construct, we would ideally expect that
A function takes arguments, doesn't modify any state (like mutating arguments, global variables, or printing info for the user to the console), and returns the result of computation.
A procedure takes arguments, performs operations which can have side-effects (writing to a database, printing to the console, maybe mutating variables), but hopefully doesn't mutate any arguments.
In practice however, depending on the situation, blends of these expectations can be observed. Sticking to these guidelines helps I think.