July 2007 - Haskell-Cafe

Ray tracer language comparison
by Jon Harrop 27 Jul '07

27 Jul '07

I've added four progressively optimized implementations of the Haskell ray tracer to the language comparison: http://www.ffconsultancy.com/languages/ray_tracer/ Only the first is lazy and I haven't mentioned them in the discussion yet. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

1 0

Re: [Haskell-cafe] Re: [Haskell] View patterns in GHC: Request for feedback
by Conor McBride 27 Jul '07

27 Jul '07

Me: > > In the dependently typed setting, it's often the case that the > > "with-scrutinee" is an expression of interest precisely because it > > occurs > > in the *type* of the function being defined. Correspondingly, an > > Epigram implementation should (and the Agda 2 implementation now does) > > abstract occurrences of the expression from the type. Dan: > Oh, I see: you use 'with' as a heuristic for guessing the motive of the > inductive family elim. How do you pick which occurrences of the > with-scrutinee to refine, and which to leave as a reference to the > original variable? You don't always want to refine all of them, do you? There are two components to this process, and they're quite separable. Let's have an example (in fantasy dependent Haskell), for safe lookup. defined :: Key -> [(Key, Val)] -> Bool defined k [] = False defined k ((k', _) : kvs) = k == k' || defined k kvs data Check :: Bool -> * where OK :: Check True lookup :: (k :: Key; kvs :: [(Key, Val)]) -> Check (defined k kvs) -> Val lookup k [] !! -- !! refutes Check False; no rhs {-before-} lookup k ((k', v) : kvs) p with k == k' {-after-} lookup k ((k', v) : kvs) OK | True = v lookup k ((k', v) : kvs) p' | False = lookup k kvs p' Left-hand sides must refine a 'problem', initially lookup k kvs p where k :: Key; kvs :: [(Key, Value)]; p :: Check (defined k kvs) Now, {-before-} the with, we have patterns refining the problem lookup k ((k', v) : kvs) p where k, k' :: Key v :: Val kvs :: [(Key, Val)] p :: Check (k == k' || defined k kvs) The job of "with" is only to generate the problem which the lines in its block must refine. We introduce a new variable, abstracting all occurrences of the scrutinee. In this case, we get the new problem {-after-}. lookup k ((k', v) : kvs) p | b where k, k' :: Key v :: Val kvs :: [(Key, Val)] b :: Bool p :: Check (b || defined k kvs) All that's happened is the abstraction of (k == k'): no matching, no mucking about with eliminators and motives. Now, when it comes to checking the following lines, we're doing the same job to check dependent patterns (translating to dependent case analysis, with whatever machinery is necessary) refining the new problem. Now, once b is matched with True or False, the type of p computes to something useful. So there's no real guesswork here. Yes, it's true that the choice to abstract all occurrences of the scrutinee is arbitrary, but "all or nothing" are the only options which make sense without a more explicit mechanism to pick the occurrences you want. Such a mechanism is readily conceivable: at worst, you just introduce a helper function with an argument for the value of the scrutinee and write its type explicitly. I guess it's a bit weird having more structure to the left-hand side. The approach here is to allow the shifting of the problem, rather than to extend the language of patterns. It's a much better fit to our needs. Would it also suit Haskell? Cheers Conor

1 0

Lazy in either argument?
by Dan Weston 27 Jul '07

27 Jul '07

I am trying to get my feet wet with Haskell threads with the following problem, inspired by a recent post (http://www.haskell.org/pipermail/haskell-cafe/2007-July/029408.html) saying that: > Since there's no way to have a function be lazy in both arguments, the > implicit convention is to make functions strict in the first arguments > and, if applicable, lazy in the last arguments. In other words, the > convention is > > True || _|_ = True but not _|_ || True = True > > 1 + _|_ = Succ _|_ but not _|_ + 1 = Succ _|_ > > Regards, > apfelmus Maybe not lazy in both arguments, but how about lazy in either argument? The idea is to fork a thread for each of the two functions, (||) and flip (||), pick the winner, then kill off both threads. I can wrap this up in a pure function using unsafePerformIO (given the proof obligation that the results of both threads will always be equal where both are defined). The code below seems to work, except for the following problems: 1) Commenting out the type annotation f :: Bool makes the program hang 2) If I replace f = f by f = undefined, I get an annoying print of "LazyOr: Prelude.undefined" before it returns the correct value. Does anyone know why the type annotation is needed in #1, and/or how to suppress the error message in #2? Dan Weston ----------------------------------------------------------- import Control.Monad(when) import Control.Concurrent(forkIO,killThread) import Control.Concurrent.Chan(newChan,readChan,writeChan,isEmptyChan) import Foreign(unsafePerformIO) f :: Bool f = f main = putStrLn . show $ lazyBinaryOp (||) f True lazyBinaryOp p x y = unsafePerformIO $ do c <- newChan p2 <- forkIO (lazyBinaryOpThread c p x y) p1 <- forkIO (lazyBinaryOpThread c p y x) z <- readChan c killThread p1 killThread p2 return z where lazyBinaryOpThread c p x y = do case (p x y) of True -> writeChan c True False -> writeChan c False

4 4

"Identifier" generators with QuickCheck
by J. Pablo Fernández 26 Jul '07

26 Jul '07

Hello Haskellers, I want to make a QuickCheck generator that creates identifiers, basically [a-zA-Z] as the first character and then [a-zA-Z0-9-_] for a total of 63 characters. So, I've got up to: do s <- choose (1, 63 :: Int) elements validFirstChars where validFirstChars = ['a'..'z'] ++ ['A'..'Z'] validChars = validFirstChars ++ "_-" ++ ['0'..'9'] which of course only gives me one random character. I want both, the characters, and the length to be random. Thank you. -- J. Pablo Fernández <pupeno(a)pupeno.com> (http://pupeno.com)

2 2

Order of evaluation
by Jon Harrop 26 Jul '07

26 Jul '07

If you have a boolean-or expression: a || b will "a" be evaluated before "b" in Haskell as it is in other languages? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

6 6

advantages of using fix to define rcursive functions
by Harald ROTTER 26 Jul '07

26 Jul '07

Hi, I read about the usage of "fix" to define recursive functions. Although I think that I understood how to use "fix", I still wonder what the advantages of "fix" are (as compared to the "conventional" approach to define recursive functions). Any hints are appreciated. Thanks Harald. " Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite." " This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."

8 9

ANN: Finance.Quote.Yahoo-0.2
by brad clawsie 26 Jul '07

26 Jul '07

i have released Finance.Quote.Yahoo 0.2 i have broken the 0.1 api, be careful if you use it i have added support for historical quotes which some people requested http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Quote-Ya… i received useful input from dale jordan and aaron tomb on this list in particular

2 2

Optimizing Haskell compilers
by Jon Harrop 26 Jul '07

26 Jul '07

I've heard that there are a plethora of Haskell compilers available. Which others give performance comparable to GHC? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

3 2

Fixity of >>>
by dons＠cse.unsw.edu.au 26 Jul '07

26 Jul '07

There's a theory this should work: getContents >>= lines >>> map read >>> sum >>> print But unfortunately we have: `(>>=)' [infixl 1] `(>>>)' [infixr 1] Meaning we must write: getContents >>= (lines >>> map read >>> sum >>> print) Indeed, all Arrow ops are infixr. Are there any technical/compelling reasons for this? -- Don

2 2

UTF-16
by Andrew Coppin 26 Jul '07

26 Jul '07

I don't know if anybody cares, but... Today a wrote some trivial code to decode (not encode) UTF-16. I believe somebody out there has a UTF-8 decoder, but I needed UTF-16 as it happens. (I didn't bother decoding code points outside the BMP - I'm sure you can figure out why.) If anybody is interested, I can share the code - but it's pretty minimal...

5 6