- Beginners - Haskell.org

IO / State / Do Syntax
by Christopher Howard 27 Aug '12

27 Aug '12

So, I'm still working with my resource tracker idea -- keeping images stored and organized inside a resource tracker structure that I can pass around to functions that need them. Let's say I want a function like so: code: -------- initResources :: IO ResourceTracker -------- The idea being that initResources loads the image files, stores them in the resource tracker (RT) structure, and returns the RT. I know I can do something like so: code: -------- initResources = do pic1 <- loadImage "someimage.png" -- IO function pic2 <- loadImage "someimage2.png" -- ... and so on ... let rt = emptyResourceTracker in let rt' = storeImage rt "pic1keyword" pic1 in let rt'' = storeImage rt' "pic2keyword" pic2 in -- ... and so on, until finally: ... rt'''''''''''''''''''''''''' -------- Obviously, all the let statements and apostrophes are undesirable. So, presumably what I need is to being using the State monad, yes? (I must confess I have only a vague understanding of the State monad, even after reading several tutorials.) But in my initResources function, how do I mix use of the IO and State do syntax, and still get what I want? I think this has something to do with Monad transformers, but I'm even less clear on how those work. -- frigidcode.com indicium.us

2 1

How to switch off a RadioMenuiItem?
by Pierre Michallet 26 Aug '12

26 Aug '12

Using Glade, I have created a menu which,among other things,has 2 radioMenuItems located in the same submenu. Both are in the off state when the program starts. In the following, I will refer to them as "initiationCB" and "beginnerCB". The expected behavior is that these 2 options are exclusive ie clicking one when in the OFF state will turn it ON and turn the other OFF. In fact, the first time I click on "initiationCB" its associated checkbox is turned ON; a second click on it will not change its state. When "beginnerCB" is then clicked, it is turned ON but "initiationCB" is not turned OFF as expected, and from then on, the two items are ON and there is no way to turn them OFF. One surprising thing is that in the same menu there are 2 CheckMenuItems which, when clicked, change their state without any code written to obtain this behavior. I would have expected the same from RadioMenuItems. In an attempt to switch a RadioMenuItem OFF , I have added the following code: on initiationCB menuItemActivate do checkMenuItemSetActive initiationCB True When "initiationCB" is clicked (and turned ON as a consequence) the program blows up seeming in an infinite recursion. The Gtk2HS tutorial (chapter 7.2) gives an example of selective choices by defining actions in the file called by a UIManager to get the elements of the user interface and RadioActionEntry in the code. The problem is that I could not succeed in associating an action to a menu item in the Glade file (as done in the tutorial), and in case of success, I don't know whether a XmlGetWidget instruction would recognize it. So the question is : is there a way to implement a solution similar to the one described in the tutorial using Glade instead of the UIManager approach? Another odd thing to me is that the signal menuItemToggle is not raised when a radioMenuItem is clicked. Thanks in advance for your help p.michallet(a)free.fr

1 0

MonadError
by Dennis Raddle 25 Aug '12

25 Aug '12

I'm enjoying writing code that uses the Error monad to provide errors, which I can catch and rethrow to add context. Kind of like getting a stack trace with any context I want every time an error happens. In most cases I use monad transformers, so the actual monad type would be something like "ErrorT String (State Int) a" But much of my code that handles errors doesn't need to know the entire context. It uses throwError, but otherwise doesn't care anything else about the type of the monadic computation. I.e., it needs to "know" that it's inside a monadic computation of a typeclass MonadError. So I discovered that I could declare a function like this: x :: MonadError String m => Float -> m Float x y = if y == 0 then throwError "zero" else return y My awareness of class constraints is vague, so as I worked on this problem I knew in a fuzzy way it was going to look something like that, but I had to experiment. Also, because I put "String" in the class constraint, I need to turn on FlexibleContexts. So my question is, how would I do it without making "String" explicit? If I put x:: MonadError e m => Float -> m Float x y = if y == 0 then throwError "zero" else return y I get errors saying "couldn't match expected type e against inferred type [Char]" and something about functional dependencies I fiddled with it a bit but couldn't make it work.

2 1

Difference between Monad composition and transformation
by Song Zhang 25 Aug '12

25 Aug '12

When I use a State Monad transformer to combine with a Writer Monad StateT s (Writer w) a. is it different from composition of State Monad and Writer Monad. It is State s (Writer w a) ? StateT is defined as (s -> m (a, s)), so StateT s (Writer w) a can be regarded as (s -> Writer w a) , which is (s -> ((a,w),s) and on the other hand State s (Writer w a) is (s -> ((a,w),s). I suppose the are similar and if so, what is the point we still get Monad transformers? Thanks

3 2

shared files / environment / portability
by Christopher Howard 25 Aug '12

25 Aug '12

I'm coding a resource tracker for a game that loads images, sounds, etc. from files, and wondering how the program will know where the files are located on the installation system. (With C/C++ programs I usually had the build system hardcode the appropriate share/ directory into the config.h file.) Assuming I package for cabal distribution, what approaches to this problem are available to me? (P.S. Thanks for the answer to the previous question about associative arrays.) -- frigidcode.com indicium.us

3 3

cabal: updating a package
by Obscaenvs 24 Aug '12

24 Aug '12

Hi there! Excuse me, but I am a bit bewildered; should I really have to give cabal --force-reinstalls to upgrade yesod to the new version 1.1.0.2? It says a lot of packages are likely to be broken, as per the paste http://pastebin.com/cYdZkShu. I was under the impression I had RTFM, but maybe I have missed something? /Fredrik

4 4

Good style on "." and "$" pipeline?
by Carlos J. G. Duarte 23 Aug '12

23 Aug '12

10 9

The Holy Trinity of Functional Programming
by Costello, Roger L. 23 Aug '12

23 Aug '12

Hi Folks, In Richard Bird's book (Introduction to Functional Programming using Haskell) he has a fascinating discussion on three key aspects of functional programming. Below is my summary of his discussion. /Roger --------------------------------------------------------- The Holy Trinity of Functional Programming --------------------------------------------------------- These three ideas constitute the holy trinity of functional programming: 1. User-defined recursive data types. 2. Recursively defined functions over recursive data types. 3. Proof by induction: show that some property P(n) holds for each element of a recursive data type. Here is an example of a user-defined recursive data type. It is a declaration for the natural numbers 0, 1, 2, ...: data Nat = Zero | Succ Nat The elements of this data type include: Zero, Succ Zero, Succ (Succ Zero), Succ (Succ (Succ Zero)), ... To understand this, when creating a Nat value we have a choice of either Zero or Succ Nat. Suppose we choose Succ Nat. Well, now we must choose a value for the Nat in Succ Nat. Again, we have a choice of either Zero or Succ Nat. Suppose this time we choose Zero, to obtain Succ Zero. The ordering of the elements in the Nat data type can be specified by defining Nat to be a member of the Ord class: instance Ord Nat where Zero < Zero = False Zero < Succ n = True Succ m < Zero = False Succ m < Succ n = (m < n) Here is how the Nat version of the expression 2 < 3 is evaluated: Succ (Succ Zero) < Succ (Succ (Succ Zero)) -- Nat version of 2 < 3 = Succ Zero < Succ (Succ Zero) -- by the 4th equation defining order = Zero < Succ Zero -- by the 4th equation defining order = True -- by the 2nd equation defining order Here is a recursively defined function over the data type; it adds two Nat elements: (+) :: Nat -> Nat -> Nat m + Zero = m m + Succ n = Succ(m + n) Here is how the Nat version of 0 + 1 is evaluated: Zero + Succ Zero -- Nat version of 0 + 1 = Succ (Zero + Zero) -- by the 2nd equation defining + = Succ Zero -- by the 1st equation defining + Here is another recursively defined function over the data type; it subtracts two Nat elements: (-) :: Nat -> Nat -> Nat m - Zero = m Succ m - Succ n = m - n If the Nat version of 0 - 1 is executed, then the result is undefined: Zero - Succ Zero The "undefined value" is denoted by this symbol: _|_ (also known as "bottom") Important: _|_ is an element of *every* data type. So we must expand the list of elements in Nat: _|_, Zero, Succ Zero, Succ (Succ Zero), Succ (Succ (Succ Zero)), ... There are still more elements of Nat. Suppose we define a function that returns a Nat. Let's call the function undefined: undefined :: Nat undefined = undefined It is an infinitely recursive function: when invoked it never stops until the program is interrupted. This function undefined is denoted by the symbol _|_ Recall how we defined the ordering of values in Nat: instance Ord Nat where Zero < Zero = False Zero < Succ n = True Succ m < Zero = False Succ m < Succ n = (m < n) >From that ordering we can see that Succ _|_ is an element of Nat: Zero < Succ undefined -- Note: same as Zero < Succ _|_ = True -- by the 2nd equation defining order And Succ (Succ _|_ ) is an element of Nat: Succ Zero < Succ (Succ undefined) -- Note: same as Zero < Succ (Succ _|_ ) = Zero < Succ undefined -- by the 4th equation defining order = True -- by the 2nd equation defining order And Succ (Succ (Succ _|_ ) is an element of Nat, and so forth. So the list of elements in Nat expands: ..., Succ (Succ (Succ _|_ )), Succ (Succ _|_ ), Succ _|_, _|_, Zero, Succ Zero, Succ (Succ Zero), Succ (Succ (Succ Zero)), ... One can interpret the extra values in the following way: _|_ corresponds to the natural number about which there is absolutely no information Succ _|_ to the natural number about which the only information is that it is greater than Zero Succ (Succ _|_ ) to the natural number about which the only information is that it is greater than Succ Zero And so on There is one further value of Nat, namely the "infinite" number: Succ (Succ (Succ (Succ ...))) It can be defined by this function: infinity :: Nat infinity = Succ infinity It is different from all the other Nat values because it is the only number for which Succ m < infinity for all finite numbers m: Zero < infinity = True Succ Zero < infinity = True Succ (Succ Zero) < infinity = True Thus, the values of Nat can be divided into three classes: - The finite values, Zero, Succ Zero, Succ (Succ Zero), and so on. - The partial values, _|_, Succ _|_, Succ (Succ _|_ ), and so on. - The infinite value. Important: the values of *every* recursive data type can be divided into three classes: - The finite values of the data type. - The partial values, _|_, and so on. - The infinite values. Although the infinite Nat value is not of much use, the same is not true of the infinite values of other data types. Recap: We have discussed two aspects of the holy trinity of functional programming: recursive data types and recursively defined functions over those data types. The third aspect is induction, which is discussed now. Induction allows us to reason about the properties of recursively defined functions over a recursive data type. In the case of Nat the principle of induction can be stated as follows: in order to show that some property P(n) holds for each finite number n of Nat, it is sufficient to treat two cases: Case (Zero). Show that P(Zero) holds. Case (Succ n). Show that if P(n) holds, then P(Succ n) also holds. As an example, let us prove this property (the identity for addition): Zero + n = n Before proving this, recall that + is defined by these two equations: m + Zero = m m + Succ n = Succ(m + n) Proof: The proof is by induction on n. Case (Zero). Substitute Zero for n in the equation Zero + n = n. So we have to show that Zero + Zero = Zero, which is immediate from the first equation defining +. Case (Succ n). Assume P(n) holds; that is, assume Zero + n = n holds. This equation is referred to as the induction hypothesis. We have to show that P(Succ n) holds; that is, show that Zero + Succ n = Succ n holds. We do so by simplifying the left-hand expression: Zero + Succ n = Succ (Zero + n) -- by the 2nd equation defining + = Succ (n) -- by the induction hypothesis We have proven the two cases and so we have proven that Zero + n = n holds for all finite numbers of Nat. Full Induction. To prove that a property P holds not only for finite members of Nat, but also for every partial (undefined) number, then we have to prove three things: Case ( _|_ ). Show that P( _|_ ) holds. Case (Zero). Show that P(Zero) holds. Case (Succ n). Show that if P(n) holds, then P(Succ n) holds also. To just prove that a property P holds for every partial (undefined) number, then we omit the second case. To illustrate proving a property that holds for every partial number (not for the finite numbers), let us prove the rather counterintuitive result that m + n = n for all numbers m and all partial numbers n. For easy reference, we repeat the definition of + m + Zero = m m + Succ n = Succ(m + n) Proof: The proof is by partial number induction on n. Case ( _|_ ). Substitute _|_ for n in the equation m + n = n. So we have to show that m + _|_ = _|_, which is true since _|_ does not match either of the patterns in the definition of +. Case (Succ n). We assume P(n) holds; that is, assume m + n = n holds. This equation is the induction hypothesis. We have to show that P(Succ n) holds; that is, show that m + Succ n = Succ n holds. For the left-hand side we reason m + Succ n = Succ(m + n) -- by the second equation for + = Succ(n) -- by the induction hypothesis Since the right-hand side is also Succ n, we are done. The omitted case (m + Zero = Zero) is false, which is why the property does not hold for finite numbers. As an added bonus, having proved that an equation holds for all partial (undefined) numbers, we can assert that it holds for the infinite number too; that is, P(infinity) holds. Thus, we can now assert that m + infinity = infinity for all numbers m.

5 5

[Real World Haskell] Question
by Yang 22 Aug '12

22 Aug '12

Hi all, In chapter 4 in Real World Haskell comes there the first example of system I/O, namely `interactWith`. According to author, the right way is to compile and run program in system shell, though I have loaded source in GHCi and can't figure out how to invoke `main` interactively. Therefore the question is simply how can I call `main` that takes arguments in GHCi? Thanks. BTW: This is my first message to the group and if there is any restriction I violate in topics, I'd like to know. The example I mentioned can be found at the beginning of the web page followed by link http://book.realworldhaskell.org/read/functional-programming.html -- Best Regards Yang Zhao

2 1

some cabal file values
by Christopher Howard 20 Aug '12

20 Aug '12

I was getting reading to upload a module to hackage. I did that once before a long time ago, so I reused and modified an old .cabal file. Current there are two copied-in values that I am not sure about: Cabal-version: >=1.2 Build-depends: base >= 4 && < 5 What should these values be set to? code: -------- $ cabal --version cabal-install version 0.10.2 using version 1.10.2.0 of the Cabal library $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 -------- -- frigidcode.com indicium.us

2 1