March 2009 - Beginners

having trouble compiling
by 7stud 27 Mar '09

27 Mar '09

Here is the error I am getting (I always get the first warning so that is nothing new): $ ghc -o Main.hs SimpleJSON.hs PrettyJSON.hs Prettify.hs compilation IS NOT required compilation IS NOT required /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning -F: directory name (/Users/me/Library/Frameworks) does not exist /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _ZCMain_main_closure ___stginit_ZCMain collect2: ld returned 1 exit status Here are my files: Main.hs ----- module Main () where import SimpleJSON import PrettyJSON import Prettify main = let s = JString "hello world" aDoc = renderJValue s in printPrettified aDoc SimpleJSON.hs -------- module SimpleJSON ( JValue(..) ) where data JValue = JNumber Double | JString String | JArray [JValue] | JObject [(String, JValue)] | JBool Bool | JNull deriving (Eq, Ord, Show) PrettyJSON.hs: ------- module PrettyJSON where import SimpleJSON import Prettify renderJValue :: JValue -> Doc renderJValue (JNumber f) = DNumber f renderJValue (JString s) = DText s renderJValue (JBool True) = DBool True renderJValue (JBool False) = DBool False renderJValue JNull = DNull Prettify.hs: ------ module Prettify where data Doc = DNumber Double | DText String | DBool Bool | DNull deriving (Show) getPrettyOutput :: Doc -> String getPrettyOutput (DNumber d) = "double: " ++ show d getPrettyOutput (DText s) = "string: " ++ show s getPrettyOutput (DBool True) = "bool: true" getPrettyOutput (DBool False) = "bool: false" getPrettyOutput DNull = "null" printPrettfied :: Doc -> IO () printPrettified aDoc = putStrLn (getPrettyOutput aDoc)

1 1

question about show -- RWH chapter 5
by 7stud 26 Mar '09

26 Mar '09

In chapter 5, RWH defines a JValue data type like this: SimpleJSON.hs: -------------- module SimpleJSON ( JValue(..) ) where data JValue = JNumber Double | JString String | JArray [JValue] | JObject [(String, JValue)] | JBool Bool | JNull deriving (Eq, Ord, Show) ------------ Then RWH defines some functions like this: PutJSON.hs: ---------- module PutJSON where import SimpleJSON renderJValue::JValue->String renderJValue (JNumber f) = show f renderJValue (JString s) = show s renderJValue (JBool True) = "true" renderJValue (JBool False) = "false" renderJValue JNull = "null" ---------- My question is about the function: renderJValue (JString s) = show s A JString value contains a string, so why does the function use show to convert s to a string? Why isn't that function defined like this: renderJValue (JString s) = s Using that modified function seems to work: Main.hs: --------- module Main () where import SimpleJSON import PutJSON main = let x = JString "hello" in putStrLn (renderJValue x) $ ghc -o simple Main.hs PutJSON.hs SimpleJSON.hs /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning -F: directory name (/Users/me/Library/Frameworks) does not exist $ simple hello Also can anyone tell me why I always get that warning? Thanks

4 7

module path? qtHaskell examples?
by Michael Mossey 25 Mar '09

25 Mar '09

Does GHC or GHCi let you specify the module search path via an environment variable? I notice it can be specified on the command line with -i. I don't want to type that every time, but I could always create an alias (or on Windows, a "macro") for running ghc/ghci. A second, unrelated question which I will put in the same email to reduce traffic volume: does anyone have working examples of qtHaskell programs? Thanks, Mike

1 0

Explicit specification of function types
by Zachary Turner 24 Mar '09

24 Mar '09

Everything I've read has said that it's generally considered good practice to specify the full type of a function before the definition. Why is this? It almost seems to go against the principles of type inference. Why let the compiler infer types if you're just going to tell it what types to use for everything? Ok well, not really for everything, you don't typically specify types for local bindings, but still why the inconsistency? I have a little experience with ML and F# and there you're encouraged to -not- specify types explicitly, and let the compiler infer them for you. In fact, it seems like it would be fairly common where you specify a type that is -less- general than the type that the compiler would infer for you, because the most general type might involve a combination of type classes used in various ways, and it may not always be obvious to the programmer how to specify it correctly.

11 16

folds again -- myCycle
by 7stud 24 Mar '09

24 Mar '09

I spent a long time working on a solution for an exercise in RWH: if you can, use foldr to mimic haskell's cycle function. At first, I wondered whether it was even possible. Then I worked on some ideas, and finally I came up with a solution. Surprisingly, my solution ended up being very simple: myCycle [] = [] myCycle xs = helperFunc xs [1..] where helperFunc ys foldrXs = foldr accFunc [] foldrXs where accFunc _ acc = ys ++ acc I tested it out, and it worked like a charm: *Main> let x = myCycle [1, 2, 3] *Main> take 2 x [1,2] *Main> take 10 x [1,2,3,1,2,3,1,2,3,1] *Main> take 30 x [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3] After re-examining my solution, I decided that this line: --where accFunc _ acc = ys ++ acc read better like this: --where accFunc _ acc = acc ++ ys The altered function returns a list just fine. But when I use take on the list, I get a stack overflow. What is being thunked in both cases? Thanks.

4 19

appropriateness of haskell for GUIs
by Michael P Mossey 23 Mar '09

23 Mar '09

Hello, I'm totally new to Haskell. I'm thinking of using it for a personal project, which is a gui-based musical score editor. (*) Why Haskell? I've always been interested in proving my software's correctness, usually in practical and informal sense. In other words, I would like to reduce bugs by having a really good understanding of what my software does. I also just want to learn Haskell. Before I invest a lot of time in learning Haskell, however, I want to understand if it's the right language for doing a gui-based musical score editor. First of all, I need a gui toolkit of some sort, and I notice that bindings to Qt exist. I'm already very familiar with Qt, so that's good. I also need to access the Windows midi api, and I see there is a module called hmidi. However, a gui program is essentially event driven and heavily interacts with the outside world. I don't know how compatible these ideas are with Haskell. If I don't use Haskell, I will probably use Python, which I already know well. So basically the question is: Haskell or Python? Note: I would enjoy learning Haskell, so this is not a question of which language is better in an absolute sense... if Haskell is suitable, but not the best choice, I will still probably use it. Thanks, Mike (*) For those who ask why I'm doing my own music score editor when many already exist, it's because it needs to be integrated with my own computer-assisted composition system. As an editor, it will be primitive: that's not its main purpose.

5 4

splitWith and foldr stack overflow
by Sean Bartell 22 Mar '09

22 Mar '09

I wrote a splitWith function (from RWH) and then converted it to use foldr: splitWith, splitWith2 :: (a -> Bool) -> [a] -> [[a]] splitWith p xs = let (ls, ts) = f xs in ts:ls where f [] = ([], []) f (x:xs) | p x = (ls, x:ts) | otherwise = (ts:ls, []) where (ls, ts) = f xs splitWith2 p xs = let (ls, ts) = foldr f ([],[]) xs in ts:ls where f x (ls, ts) | p x = (ls, x:ts) | otherwise = (ts:ls, []) Tested with something simple like take 8 $ splitWith id (cycle [False,True]) splitWith works fine, but splitWith2 causes a stack overflow. Don't they have the same recursive structure, though?

2 1

Re: [Haskell-beginners] about beta NF in lambda calculus
by Brent Yorgey 21 Mar '09

21 Mar '09

On Sat, Mar 21, 2009 at 07:59:25PM +0000, Algebras Math wrote: > sorry, I missed something.. > > actually (\x.x) (\x.x) reduces to \x.x, they are equal under beta > reduction, isn't it? > (\x.x) (\x.x) =beta \x.x. > > so they are the same? It depends what you mean by "equal", but usually what we mean by "equal" is actual structural equality, so (\x.x) (\x.x) and \x.x are not equal, since they are different terms (one is an application of one term to another, the other is a lambda term). It makes no difference whether one reduces to the other; they are not the _same_ term so they are not equal.* However, sometimes we _don't_ want to distinguish between terms which reduce to one another; in this case we can define some sort of equivalence relation, and say, for example, S =beta T if S can be reduced to T by a series of beta reductions, or vice versa. But it is important to realize that =beta is just an equivalence relation we have defined, it is not the same thing as equality. It is quite possible to have S =beta T but S /= T, as in your example. -Brent *Technical note: actually, we usually allow terms to be equal "up to alpha equivalence", that is, you are allowed to rename bound variables. So (\x.x) and (\y.y) are equal, since you can convert between them by renaming x to y, which doesn't really change anything. > > On Sat, Mar 21, 2009 at 7:37 PM, Brent Yorgey <byorgey(a)seas.upenn.edu>wrote: > > > On Sat, Mar 21, 2009 at 07:28:48PM +0000, Algebras Math wrote: > > > hi, > > > > > > What is the different between 'in beta normal form' and 'has beta normal > > > form' ? Does the former means the current form of the term is already in > > > normal form but the latter means that it is not a normal form yet and can > > be > > > reduced to be normal form? Like \x.x is in NF and (\x.x) (\x.x) has NF? > > > > Exactly. > > > > > If above is true, I am confused why we have to distinguish the terms > > which > > > have NF and be in NF? isn't the terms have NF will eventually become in > > NF? > > > or there are some way to avoid them becoming in NF? > > > > If a term _has_ a normal form, we can be confident that we will > > eventually reach a normal form by reducing it; if a term _is in_ > > normal form, we know that reducing it will have no effect. It is > > useful to distinguish them in the same way as it is useful to > > distinguish between someone who _is currently_ at home and someone who > > is at the grocery store but has a way of getting home. (\x.x) (\x.x) > > reduces to \x.x, but they are not the same term. We could "avoid" > > having (\x.x) (\x.x) become a normal form by simply choosing not to > > reduce it. > > > > Does that help? > > > > -Brent > > _______________________________________________ > > Beginners mailing list > > Beginners(a)haskell.org > > http://www.haskell.org/mailman/listinfo/beginners > >

1 0

about beta NF in lambda calculus
by Algebras Math 21 Mar '09

21 Mar '09

hi, What is the different between 'in beta normal form' and 'has beta normal form' ? Does the former means the current form of the term is already in normal form but the latter means that it is not a normal form yet and can be reduced to be normal form? Like \x.x is in NF and (\x.x) (\x.x) has NF? If above is true, I am confused why we have to distinguish the terms which have NF and be in NF? isn't the terms have NF will eventually become in NF? or there are some way to avoid them becoming in NF? Thanks Alg

2 1

laziness and optimization
by Michael Mossey 21 Mar '09

21 Mar '09

I understand a bit about the concept of "lazy evaluation." I think of that as saying an imperative language would always make one evaluation, whereas Haskell might make 0 evaluations. I have another similar situation where an imperative language would make N evaluations of the same expression, and I would like Haskell to make only 1. This is the situation: the graphical score editor displays "LayoutItems." A LayoutItem can be a single displayed entity, like a round notehead, or it can be composed of several entities. A common situation in my code is the need to determine the size and shape of a LayoutItem. For a fundamental item, this can be looked up in a table or read from the font properties. For a composite item, some computation is required: the code must determine the positions of each sub-item and compute the bounds of a shape containing all of them. It's this latter computation, finding the bounds of a composite item, which might come up multiple times. Consider that I ask for the bounds of a composite-composite item (a composite item composed of composite items). It will run the computation associated with each composite sub-item, even though it is very likely I already make that computation when I first constructed and placed that sub-item. In an imperative language, one might cache values for later lookup. This raises the problem of keeping the cache current to the current state. So I'm wondering to what extent the haskell compiler recognizes computations it's done before. In a purely functional language this should be pretty easy, right? If it sees the same expression, it knows it will have the same value. That's my understanding, so far. Thanks, Mike

2 1