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 I dunno
but after checking out the website, I think I'm going to look into it.

I think the reason it's not widely used is because it's a functional, not an imperative, language. I know that when I took the paradigms course, functional languages took a while for me to grok, and I did a lot better than some people in my class. I think there's a lot of people out there for whom Imperative Programming == Programming. This language doesn't fit into that paradigm, so if you're a dude looking for a tool, and you don't understand functional programming, then this tool is simply going to be discarded out of hand.
--\n-------------------------------------------------------------------\n* Jack Troughton                            jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca]                   [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada               [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
New Quick CS101 pointer? Diff between fucntional and imperative?
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Re: Quick CS101 pointer? Diff between fucntional and imperat
Imperative: variables, functions, loops, ... you're telling the computer exactly what to do (the imperative sense) in a series of operations.

Functional: just functions. No variables, no side effects, you don't store anything. The program is one humungous equation, and you always create new values from old ones instead of over-writing. True functional programs can be proven to be correct.

Those are the pure types; many languages are a combination of the two. For example, Python has the map function, continuations, closures, etc., which are typically considered features of functional languages.

Personally I hate the term "functional" because so many people confuse it with meanings that have nothing to do with the programming type itself. Using functions doesn't mean you are doing functional programming, and functional programming isn't stuff that is just plain old operational. :-)
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Okay, remember hearing that before, and I understand ...
... why it's hard to grok. How do you write a program without variables? Is there an example you can point to of how to do something useful? The definition I remember is that each function will always return the same value given the same inputs. What you've described seems to go several steps beyond that.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Re: Okay, remember hearing that before, and I understand ...
Strict functional programming has no side-effects. What this means is that you can't change anything. You can, however, return something calculated from your inputs. Simplistically, a true functional program has an entry point, and all of the functions within just return a modified version of what's passed in, and the output is the result of calling all of the functions.

There are no global variables and no side-effects, and that's why a function will always return the same value given the same inputs. Nothing matters but the parameters that are passed in.

Because of this you have to go through some hoops to perform some imperative constructs: looping is done through recursion, for example.

// Crappy pseudocode example\nfunction forLoopPositiveIncrementsOnly(int from, int to, int inc, function dowhat)\n{\n  if (from > to) return;\n  dowhat(from);\n  loop(from + inc, to, dowhat);\n}


Note that there IS a stack, but you can't modify the values on the stack, just use them.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New So you can't have a (pseudo) random number generator?
New Those don't have side-effects
And given the same seed, a pseudo-random number generator will always return the same sequence of "random" numbers.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New I was too tearse.
Some random number generators are more random than others. :-) I'm aware of the limitations of typical pseudo random number generators. I was too tearse in putting that in the Subject. (One of many true random number generators is [link|http://www.fourmilab.ch/hotbits/|HotBits].)

I wasn't questioning the "side-effects" aspect (I don't think), I was wondering whether it would be possible to hypotheically code a random number generator in a pure functional language given that, apparently, f(x0,t) = y0 for all x0 for a fuctional language, where a random number generator would give f(x0,t) = y(x0,t,gamma) (where gamma is some truly radom parameter). (If I didn't mess the notation up.) Presumably the code would talk to a radioactivity sensor or something similar that was truly random.

I would think that it must be possible, but wonder how it would be simply explained and whether it violates the premise of functional programming.

Thanks.

Cheers,
Scott.
New For pure functional programming, no
Because the program won't be provable for a given set of inputs.

Unless you count the external random number as one of the inputs, I suppose.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
Expand Edited by admin March 11, 2006, 02:02:24 PM EST
New You can if you thread the state through the functions...
...and hence the introduction of monads.
New Is this worth going through?
[link|http://www.haskell.org/tutorial/|http://www.haskell.org/tutorial/]
New Shorter read....
...would be this [link|http://www.haskell.org/haskellwiki/Introduction|Haskell Intro], which is just the highlights.
New Already did that
So I was wondering it the other was worth the detail.
I downloaded [link|ftp://ftp.geoinfo.tuwien.ac.at/navratil/HaskellTutorial.pdf|ftp://ftp.geoinfo.tu...skellTutorial.pdf] and started going through it. Seems interesting.
New I didn't find the gentle intro useful when I read it...
...4 years ago. It assumes you have a lot of knowledge, especially with functional languages.
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)

Why does this guitar smell like CHEESE?!?
443 ms