(( FP]%%projects —
– python – first-class functions, lambda, closure, reduce(), zip(), apply(), map()
– perl – first class functions, closures, sort(), map()
– FMD ))
I feel FP is another buzzword people like to attach liberally (loosely) to various languages and software “Modules” like classes, functions, APIs.
The strict definition of FP is non-trivial, but let’s look at some salient features — the handful of pillars beneath a sprawling complex. If you have a module (a piece of software) that shows any one of these features, you are often free to say it’s kinda FP.
* [t] side-effect-free, always-repeatable functions — for a given set of input values to a function, you get the same output from every invocation
* [t] stateless functions — I guess C functions without static or global variables are simple examples.
* stateless objects? — stateless objects implies immutable. Mutable always refers to some stateful objects. However, I feel strictly stateless object is impractical and useless.
(Q: good example of immutable but stateful? Try google)
* [t] everything immutable — if all objects in your module is immutable, then probably it’s FP
[t = important to multithreading]
Actually, definition of FP is less important than the FP best practices encouraged and embedded in the popular FP languages. If any defining feature of FP isn’t widely adopted, then it gradually loses relevance. Therefore I’d rather spend more time on the common denominators of FP languages than the strict definition.
http://www.ibm.com/developerworks/linux/library/l-prog/index.html?ca=drs- has a similar view.
From now on I’d use “math” to mean “math-like”.
The only FP language I used is Functional Model Deployment (FMD). I confirmed with other FMD users — all objects are immutable but (to be of any use) definitely stateful. Every c++ non-static method becomes a math-function. Host instance i.e. ” *this ” becomes the first argument, and a new instance is returned, to preserve the immutability of original instance.
The truly defining feature is the eval (fn, values, labels) construct.
– value can be any object, like some street address
– label is just a string, like “address”
– fn is what I call an incomplete object. It looks like an object with (potentially complex) state, but when you view it, it is presented as a function — a math function — with at least one variable unbound. If that variable is named “address”, then the above eval() would provide the required variable binding, and transform that function into a complete object.
Each object is written as some math-expression, so it usually depends on some objects. There could be a very long (thousands of nodes) object graph behind an object. Just think of each object in the graph as a math expression, one feeding into the next.
If any upstream object has an unbound variable, then all downstream objects become incomplete objects i.e. math-functions.