Functional programming explained ... IRC-style(itmmetelko.com)
itmmetelko.com
Functional programming explained ... IRC-style
http://itmmetelko.com/blog/2008/02/23/functional-programming-immutable-objects-explained-irc-style/
5 comments
You think it's weird now, wait until you start building infinite lists or writing recursive functions with no terminating case as part of your everyday routine in Haskell :)
you can do that with python generators, too. These don't seem like the most eccentric Haskell features to me.
Heh, one step at a time... Those sound like they can produce headaches.
FWIW, RobertFischer's blog is http://enfranchisedmind.com/blog/
In a nut shell:
<middayc-> I have to invert my brain from stuff I am used to and
then it all makes sense
<RobertFischer> Pretty much.
Isn't the graph itself state? I mean, data structures of data structures....but data is state by definition, right?
Yes, but it's not being modified in place, so you can selectively re-use it. Immutability is the big thing.
In FP, you typically "change" a data structure by creating a shallow copy of it with a few parts replaced, but the rest just pointing back to the original - nothing's changed directly, and when data is no longer used, it's eventually garbage collected. (Typically, with a generational and/or copying collector, whose costs are proportional to surviving data.)
This works better with trees and lists than it does arrays and hash tables, because changes to those usually require adjusting as a whole. To add to the head of a linked list, you can just create a new cell of [new value, head of old list], which is very cheap. (Adding to the tail can be done with e.g. a deque). At the same time, anything that adds to the list won't interfere with other code that is holding a reference to the same list, or even accessing it concurrently.
Probably the best way to learn about purely functional data structures is from the book of the same name by Chris Okasaki.
In FP, you typically "change" a data structure by creating a shallow copy of it with a few parts replaced, but the rest just pointing back to the original - nothing's changed directly, and when data is no longer used, it's eventually garbage collected. (Typically, with a generational and/or copying collector, whose costs are proportional to surviving data.)
This works better with trees and lists than it does arrays and hash tables, because changes to those usually require adjusting as a whole. To add to the head of a linked list, you can just create a new cell of [new value, head of old list], which is very cheap. (Adding to the tail can be done with e.g. a deque). At the same time, anything that adds to the list won't interfere with other code that is holding a reference to the same list, or even accessing it concurrently.
Probably the best way to learn about purely functional data structures is from the book of the same name by Chris Okasaki.
Thanks for the book recommendation. Those are always much appreciated!
yes, but you don't modify it in this case.
<RobertFischer> A graph is a data structure of data structures.
Could anyone provide an example?
Could anyone provide an example?
I'm just getting into clisp (I read somewhere that it is inevitable that everyone on HN will eventually try lisp when they have been around long enough) at the moment, and would like to try my hand at some Haskell later as well, and one of the hardest things to do is to think of data in FP terms.