August 2007 - Haskell-Cafe

Defining new operators
by rodrigo.bonifacio 11 Aug '07

11 Aug '07

Hi all, Given the follwing function: > owner :: Step -> Scenario > owner (Step id scenario action state response) = scenario Is it possible to define the owner function in such way that I can write x.owner (returning the scenario related with the Step x)? Thanks in advance, Rodrigo.

5 4

How odd...
by Andrew Coppin 11 Aug '07

11 Aug '07

> 0^2 0 > (0 :+ 0)^2 0 :+ 0 > 0**2 0 > (0 :+ 0)**2 NaN :+ NaN (Is this a bug?)

10 16

arrow question HXT related
by Andrea Rossato 11 Aug '07

11 Aug '07

Hi, I think this is just a stupid arrow question. Still I cannot find where my mistake is located. Suppose I have a simple xml document I want to process with HXT: <root> <elem> <sub /> <risub>text</risub> </elem> </root> After extracting <elem> I want to duplicate the children trees with the arrow operator (&&&) and process them to get each sub element, like I try in treMe2. Below the example code. While I can get each sub element with tryMe and tryMe1, tryMe2 will produce a []. Instead I want something like tryMe3. I think I'm missing something stupid but right now I just feel stupidly blind. Thanks for your help, Andrea import Text.XML.HXT.Arrow xml = "<root><elem><sub /><risub>text</risub></elem></root>" tryMe = runLA arrow [] where arrow = constA xml >>> xread >>> deep (hasName "elem") >>> getChildren >>> (hasName "risub" >>> getChildren >>> getText) tryMe1 = runLA arrow [] where arrow = constA xml >>> xread >>> deep (hasName "elem") >>> getChildren >>> (hasName "sub" >>> withDefault (getChildren >>> getText) "ciao") tryMe2 = runLA arrow [] where arrow = constA xml >>> xread >>> deep (hasName "elem") >>> getChildren >>> (hasName "sub" >>> withDefault (getChildren >>> getText) "ciao") &&& (hasName "risub" >>> getChildren >>> getText) tryMe3 = runLA arrow [] where arrow = constA xml >>> xread >>> constA "first" &&& constA "second" The output: *test> tryMe ["text"] *test> tryMe1 ["ciao"] *test> tryMe2 [] *test> tryMe3 [("first","second")] *test>

1 1

Small question
by Andrew Coppin 11 Aug '07

11 Aug '07

Which of these is likely to go faster? type Quad = (Bool,Bool) foo (r,t) = let x = if r ... y = if t ... in ... data Quad = BL | BR | TL | TR foo q = let x = if q == TL | q == TR ... y = if q == BR | q == TR ... in ... (Unless somebody has a better idea...) I'm hoping that the latter one will more more strict / use less space. But I don't truely know...

14 31

Problem with question 3 about knights and knaves on wikipedia
by Peter Verswyvelen 10 Aug '07

10 Aug '07

I was writing some haskell code for fun to solve some "knights and knaves" problems, and I have troubles with http://en.wikipedia.org/wiki/Knights_and_knaves#Question_3 So knights always tell the truth and knaves always lie. John and Bill are two persons, but you don't know what they are, and you have to find out. Question 3 You: Are you both knights? John: answers either Yes or No, but you don't have enough information to solve the problem. You: Are you both knaves? John: answers either Yes or No, and you can now solve the problem. My haskell code gave the following result: --(what is john, what is bill, first answer from john, second answer from john) ("John is a knight","Bill is a knight","Yes","No ") ("John is a knight","Bill is a knave ","No ","No ") ("John is a knave ","Bill is a knight","Yes","Yes") ("John is a knave ","Bill is a knave ","Yes","No ") Anyone has an idea what I missed here? Thanks, Peter PS: The (quick and dirty) haskell code I wrote for this is: infixl 1 <=> infixl 1 ==> -- Equivalence x <=> y = (x == y) -- Implication True ==> False = False _ ==> _ = True -- Knights tell the truth name `isa` True = name ++ " is a knight" -- Knaves always lie name `isa` False = name ++ " is a knave " answer True = "Yes" answer False = "No " --Logician: Are you both knights? --John answers either Yes or No, but the Logician does not have enough information to solve the problem. --Logician: Are you both knaves? --John answers either Yes or No, and the Logician can now solve the problem. condition j b answer1 answer2 = (j <=> ((b && j) == answer1)) && (j <=> ((not b && not j) == answer2)) solution = [("John" `isa` j, "Bill" `isa` b, answer answer1, answer answer2) | j <- [True,False], b <- [True, False], answer1 <- [True, False], answer2 <- [True, False], condition j b answer1 answer2 ] main = mapM_ putStrLn (map show solution)

3 3

listify
by Chad Scherrer 10 Aug '07

10 Aug '07

Don't be too impressed, I think I was way off base. Looks like just a homomorphism: http://en.wikipedia.org/wiki/Homomorphism Chad > > I wonder, is listify a contravariant functor? > I wonder - will I ever reach the stage where I too make off-hand remarks > like this? :-} > Now I know how all the "normal" people feel when I tell them that a > relation is simply a subset of the extended Cartesian product of the > respective domains of its attributes...

1 0

re: [Haskell-cafe] Pure functional GUI (was "a regressive view of support for imperativeprogramming in Haskell")
by Peter Verswyvelen 10 Aug '07

10 Aug '07

As a newbie (okay I will not write this again, you all know I'm a newbie by now ;-), I don't understood what the problem of a pure functional GUI is. To me, having an imperative background, a graphical application is just a big tree of data that evolves when events from the OS come in. (this data is NOT per se the data for the GUI element; instead use the model-view-controller design pattern) In Haskell, instead of mutating the data (as done in C/C++), a infinite stream of this tree-data is generated responding to an infinite steam of events, as in Paul's SOE book (the reactive stuff). Since most of the data can be shared, the performance impact should be minimal. So could you please tell me more about the problem with pure functional GUIs and why this is not part of the Haskell library? I mean a GUI library completely written in Haskell, not wrapping a popular library. Thanks, Peter >----- Oorspronkelijk bericht ----- >Van: Donn Cave [mailto:donn@drizzle.com] >Verzonden: woensdag, augustus 8, 2007 08:56 PM >Aan: haskell-cafe(a)haskell.org >Onderwerp: Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell > >On Wed, 8 Aug 2007, Paul Hudak wrote: >... >> Well, you could argue, monad syntax is what really made Haskell become >> more accepted by the masses, and you may be right (although perhaps >> Simon's extraordinary performance at OSCOM is more of what we need). On >> the other hand, if we give imperative programmers the tools to do all >> the things they are used to doing in C++, then we will be depriving them >> of the joys of programming in the Functional Way. How many times have >> we seen responses to newbie posts along the lines of, "That's how you'd >> do it in C++, but in Haskell here's a better way...". > >It seems to me that Brian Hulley threw the glove down hard. Does >pure functional Haskell offer a better way to write a GUI? > >I love the functional stuff myself, but if real applications depend >on extensive imperative logic, we're best served by a language that >cheerfully embraces the inevitable and handles it well. Monads, the >do syntax, whatever it takes (I have a soft spot for O'Haskell, but >alas I must be nearly alone on that.) Hopefully, it's still better, >and not at all irreconcilable with the Functional Way. > > Donn Cave, donn(a)drizzle.com > >(That's a genuine question, by the way - my attempt to build a >current Haskell GUI library on NetBSD foundered and I have no >experience with Haskell GUI coding, but it's on the list of things >I would like to look at. So if there's one that really illustrates >the virtues of pure functional Haskell programming, that would be >a welcome tip!) > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe > >

7 6

where to put handy functions?
by Chad Scherrer 10 Aug '07

10 Aug '07

Is there process for submitting functions for consideration for inclusion into future versions of the standard libraries? For example, I'd like to see this in Data.List: extract :: [Int] -> [a] -> [a] extract = f 0 where f _ _ [] = [] f _ [] _ = [] f k nss@(n:ns) (x:xs) = if n == k then x:f (k+1) ns xs else f (k+1) nss xs This behaves roughly as extract ns xs == map (xs !!) ns except that it's a lot more efficient, and it still works if ns or xs (but not both) are infinite. Oh, and "ns" are required to be ordered and non-negative. I'm guessing there are a lot of similarly simple handy functions, and I'm wondering if there's anything in place to avoid (1) reinventing the wheel, and (2) name clashes. Someone else may have written "extract" as well, meaning one of us wasted our time. And chances are, if they did, it has a different name, leading to forced qualified imports. Finally, even if no one else is using it, it would be good to settle on reasonable names for things more easily. Is there a better name for this function? Is there a reason not to call it "extract"? -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

9 11

Matters of precision
by Andrew Coppin 10 Aug '07

10 Aug '07

Hi folks. I'm trying to write a Mandelbrot generator, and I've having a few problems with precision. First of all, currently I'm just using Double to represent coordinates. Can anybody tell me what the smallest value you can represent with one is? (Not including denormals.) (I've built a function that checks for cycles in the orbit - by looking for previous points that are sufficiently "near" to the current one. But I want to know how much precision a Double gives me so I can figure out how near is "near".) Next up, at some point I'm going to need more precision than a Double can give me. (But, obviously, I still want the thing to go as fast as humanly possible.) In particular, I do NOT want to go into "infinite" precision. (E.g., exact arithmetic with arbitrary fractions.) I want to be able to make the precision arbitrarily high, but still finite and fixed. (The idea being that the further you zoom in, the more the computer turns up the precision.) Is there anything useful for this in the standard libraries? Or will I have to write something?

3 2

Erlang-style concurrency
by Kyle Consalus 10 Aug '07

10 Aug '07

In digest #69, Hugh Perkins mentioned the coolness of Erlang-style message passing concurrency. It just so happened that I was playing with that yesterday, so I figured I'd post a link to a 'ping-pong' thing that I based on an example in the erlang tutorial. I figured "Haskell has lightweight threads, higher order functions, and pattern matching. No reason that with a little bit of STM and some monadic convenience we can't do message passing." It's really simplistic and doesn't parameterize message type (well, not this version; that version is still in the works), but I thought someone might find it amusing just the same. http://hpaste.org/2174

1 0