tag:blogger.com,1999:blog-3669809752172683097.post5230878134920715750..comments2024-02-08T04:04:28.385-08:00Comments on Cyclopedia Square: Haskell Considered WackyBryanhttp://www.blogger.com/profile/11394436715172971234noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3669809752172683097.post-34125995351117713562007-07-19T01:02:00.000-07:002007-07-19T01:02:00.000-07:00The main problem with IO in purely functional prog...The main problem with IO in purely functional programming languages is, that they guarantee that any expression in a function will only evaluated if it is really needed and <B>at most once</B>. That's part of the lazy evaluation rules.<BR/><BR/>So if you have a function that has <I>((2 + x)*21)</I> several times in it, that expression is evaluated only once and all occurences use that result. (Technically the program is parsed into an abstract syntax graph, not a syntax tree.) So you cannot make real assumptions on the evaluation order of expressions unless they depend on each other's return value.<BR/><BR/>Now let's say you have an IO-function <I>getLine</I> that reads a line from standard input, and a function whose contents is only <I>getLine</I> followed by an additional <I>getLine</I>. According the lazy evaluation rules the second <I>getLine</I> evaluates to the same value as the first. That's the problem with IO in purely functional languages. IO depends heavily on the sequenced evaluation order and side effects -- all things that are strictly against the main thoughts of functional programming.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-19073591271703485542007-07-18T21:18:00.000-07:002007-07-18T21:18:00.000-07:00"We can't express input and output in our perfectl...<I>"We can't express input and output in our perfectly functional language unless there is some math behind it. Let us delve deeper into Mathematics to find our answer!"</I><BR/><BR/>Well, sort of.<BR/><BR/>What's going on with I/O (and the modeling of any sort of mutable state in general) in Haskell is the type system. There's a type for effects, and the way those types behave guarantees that the side-effects happen in a safe, predictable way.<BR/><BR/>The Haskell designers believe in having a type system that's proven not to fall apart in odd cases, and it just turns out to have taken some artifacts from category theory to make that sort of proof.Anonymousnoreply@blogger.com