- Haskell-Cafe - Haskell.org

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 11 Aug '07

11 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 11 Aug '07

11 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 11 Aug '07

11 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 11 Aug '07

11 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 11 Aug '07

11 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 11 Aug '07

11 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

Interval Arithmetics
by Mitar 10 Aug '07

10 Aug '07

Hi! First, disclaimer: everything I know about interval arithmetics comes from this video: http://video.google.com/videoplay?docid=-2285617608766742834 I would like to know if there is any implementation of interval arithmetics in Haskell? I would like to play a little with that. I checked the web and the straightforward approach I found: http://cs.guc.edu.eg/faculty/sabdennadher/Publikationen/paper-wflp99.ps.gz has from my point of view invalid implementation. For example, lower bound in the sum should not be just calculated as the sum of lower bounds of summands. It should return the greatest representable number which is smaller or equal to the exact value of the sum. With just boldly making a sum we ignore any errors we could introduce and this is somehow against the idea of interval arithmetics. And as it is said at the end of the talk, a system behind interval arithmetics should do a lot of work to make those intervals as small as possible while still correct and counting in all the errors we accumulated. I think a strict-typed and lazy language like Haskell would be a good place to implement this. But I would like to know if this would be possible to do from the language itself, without making changes to the compiler and/or runtime itself? Because, for example, a good implementation should reformulate equations at the runtime accordingly to exact values it wants to compute them on. Has it been done already? Mitar

2 1

Polymorphic variants
by Jon Harrop 10 Aug '07

10 Aug '07

Does Haskell have anything similar to OCaml's polymorphic variants? They act as inferred sum types: # let rec eval = function | `Int n -> n | `Add(f, g) -> eval f + eval g | `Mul(f, g) -> eval f * eval g;; val eval : ([< `Add of 'a * 'a | `Int of int | `Mul of 'a * 'a ] as 'a) -> int = <fun> -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

4 4

Monad Description For Imperative Programmer
by Kaveh Shahbazian 10 Aug '07

10 Aug '07

This is about to put a definition/description to test. So please cooperate! ;) Is this a useful – sufficient, not complete – definition/description for a monad; for an imperative mind: (?) "A monad is like a loop that can run a new function against it's variable in each iteration." (I insist on the simplicity! And I will resist any expansion of this sentence (except for an exceptional note that I think of it hardly). I think there is not any complete definitions in computer world. At least there are many things to know when you want to use them in practice. So please have this in mind and review me!) Cheers :)

10 13