IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New The three pillars
OOP is usually associated with:
  • encapsulation
  • inheritance
  • polymorphism

FP is usually associated with:
  • parametric genericity
  • referential transparency
  • higher order functions

New You just lost me
Remember, I haven't taken the classes, so it's more often the terminology I don't know. And I have no idea what you meant by
* parametric genericity
* referential transparency
* higher order functions
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Google the terms
Basically he means that you have functions whose parameters can be of many different types, functions do the same thing every time you give them the same parameters, and there are functions that take or receive other functions as arguments.

For example a quicksort written in Haskell will sort anything that < and <= are defined for. By contrast you have to write a different quicksort in C for every data type. That's parametric genericity.

For example a function in Haskell will always do the same thing when you call it. (Not actually true, but you're told when it is not true. Incidentally this is how you can have a pseudo-random number work in Haskell.) A function in C might do something else depending on a global variable that got changed in between.

And for higher order functions, the following piece of Perl demonstrates the idea:

nested_for(\n  sub {print "@_\\n";},\n  [1..2], ['a'..'c'], ['A'..'D']\n);\n\nsub nested_for {\n  ret_iter(@_)->();\n}\n\nsub ret_iter {\n  my $fn = shift;\n  my $range = shift;\n  my $sub = sub {$fn->($_, @_) for @$range};\n  return @_ ? ret_iter($sub, @_) : $sub;\n}

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New Quick explanation
Parametric Polymorphism: Strictly speaking, generics are really only a consideration in statically typed FP languages (e.g. ML and Haskell). This form of polymorphism is the type that C++ templates attempts (but like with everything else C++ it is way too complex). In ML, the polymorphism comes almost free. The bottom line is that you don't usually have to declare the type of a variable - the compiler will figure it out for you. A simple case would be calculating the length of a list:
   fun length []      = 0\n     | length (x::xs) = 1 + length xs\n   val a = length [1,2,3,4]\n   val b = length ["a","b","c","d"]

This should give the answer of 4. Notice no types were explicitly declared here. The compiler figures out that the first invocation is a length of integers and the second a list of strings. The length function can operate over lists of all types, so there is no need to declare the types.

Referential Transparency: This roughly means that for a given set of inputs, the function should always generate the same results. State is the natural enemy of RI, in that it can change the result of a function. So the first rule of thumb is that there should not be a dependency upon external state.
   val a = ref 0\n   fun nontransparent x = x + !a\n   val b = nontransparent 1;\n   a := !a + 1;\n   val c = nontransparent 1

The results are b=1 and c=2, but the function calls were identical. The external state variable a got changed in between. This would be a violation of RI.

The other enemy of RI is sequencing. FP languages come in two flavors - eager and lazy. Eager languages evaluate the function parameters prior to calling the function. Lazy languages don't evaluate parameters until the values are needed (forced).

Higher Order Functions: Functions can be first class values. They can be parameters to functions and returned as values from functions. The three most common are: Map, Filter, and Fold (aka Reduce).
   val x = map (fn i => i+i) [1,2,3,4]\n   (* result: x = [1,4,6,8] *)\n\n   val y = filter (fn a => (a < 3)) [1,2,3,4]\n   (* result: y = [1,2] *)\n\n   val z = foldr (fn (x,y) => x+y) 0 [1,2,3,4]\n   (* result: z = 10 *)\n\n   val z = foldl (fn (x,y) => x+y) 0 [1,2,3,4]\n   (* result: z = 10 *)

Map applies a given function to each element within a list and returns the resulting list. Filter returns a list of items within the input list that have the function evaluate to true. Fold collapses the list by applying a function across the list and returning the value of the function. Fold can be either Left or Right, depending on whether you wont to fold the list starting from the left side and working your way right (or vice versa).

As Scott said, many of these things are also in non-FP languages. But the point of FP is one of emphasis - having features which make working with functions easier. Haskell is the only FP language that's considered to be close to pure. ML and Scheme have state variables (like the above ML code). Haskell is a pursuit to use monads to handle the reality of needing to cope with external events but manage them in a pure FP fashion.
New One other important concept worth mentioning is Currying
FPs generally allow functions to curry. A simple example would be an add function that takes two parameters - the values to be added:
   fun add x y = x + y\n\n   val x = add 10\n\n   val y = x 20

Notice that the calculation of the x value only calls the add function with one parameter (10). The result of this application is that x itself is a function that takes one value. Effectively it is the function:
fun x(y) = 10 + y

This concept of currying is part of the consideration for higher order functions.
     Erlang? - (tuberculosis) - (22)
         Threads, Messages, and Pattern Matching.... - (ChrisR) - (21)
             Right so to me this sounds like the ultimate SOA language - (tuberculosis) - (20)
                 I dunno - (jake123) - (18)
                     Quick CS101 pointer? Diff between fucntional and imperative? -NT - (drewk) - (17)
                         Re: Quick CS101 pointer? Diff between fucntional and imperat - (admin) - (16)
                             Okay, remember hearing that before, and I understand ... - (drewk) - (6)
                                 Re: Okay, remember hearing that before, and I understand ... - (admin) - (5)
                                     So you can't have a (pseudo) random number generator? -NT - (Another Scott) - (4)
                                         Those don't have side-effects - (admin) - (3)
                                             I was too tearse. - (Another Scott) - (2)
                                                 For pure functional programming, no - (admin)
                                                 You can if you thread the state through the functions... - (ChrisR)
                             Is this worth going through? - (broomberg) - (3)
                                 Shorter read.... - (ChrisR) - (2)
                                     Already did that - (broomberg) - (1)
                                         I didn't find the gentle intro useful when I read it... - (ChrisR)
                             The three pillars - (ChrisR) - (4)
                                 You just lost me - (drewk) - (3)
                                     Google the terms - (ben_tilly)
                                     Quick explanation - (ChrisR) - (1)
                                         One other important concept worth mentioning is Currying - (ChrisR)
                 Erlang does look very intriguing, will hopefully influence - (tonytib)

Pull. Snick! Push. Snick! Pull. Snick!
52 ms