- Haskell-Cafe - Haskell.org

Showing Data.Ratio - different on GHC vs Hugs/Yhc
by Neil Mitchell 17 Nov '07

17 Nov '07

Hi Under Hugs and Yhc, showing a Ratio 1%2 gives "1 % 2". Under GHC showing 1%2 gives "1%2". Does the standard say anything about this? Is someone wrong? And how do Yhc/nhc/Hugs pass Bernouilli in the Nofib suite given that the output doesn't match? Thanks Neil

3 2

Re: let vs. where
by John Lato 16 Nov '07

16 Nov '07

This actually clears up something that's been bothering me for some time. I've never really like syntax of types for functions with multiple arguments. Using the same token, "->", to separate both arguments and the result seems very poor, because when reading a type you don't know if the value after that token is another argument or the final result without going further ahead. However, knowing that a function takes exactly one argument makes the syntax seem much more expressive for me. > From: Henning Thielemann <lemming(a)henning-thielemann.de> > > ... In > contrast to that, Haskell functions have exactly one argument and one > result, which I find is a nice thing.

2 1

List of all powers
by Kurt Hutchinson 16 Nov '07

16 Nov '07

As part of a solution I'm working on for Project Euler problem 119, I wanted to create an ordered list of all powers of all positive integers (starting with squares). This is what I came up with: powers = ( uniq . map fst . iterate next ) ( 1, ( 0, powertable ) ) powertable = map (\ n -> map (\ p -> n ^ p ) [ 2 .. ] ) [ 2 .. ] next ( _, ( lim, ps ) ) = ( p, ( lim', ps' ) ) where ( c, p ) = minimumBy ( compare `on` snd ) . zip [ 0 .. lim ] . head . transpose $ ps lim' = lim + ( if c == lim then 1 else 0 ) ( front, b : back ) = splitAt c ps ps' = front ++ ( tail b : back ) -- like the unix utility uniq [] = [] uniq [x] = [x] uniq (x:y:ys) | x == y = uniq (y:ys) | otherwise = x : uniq (y:ys) Basically, think of a grid of numbers, each row is the list of powers for one integer. To find the next power in the sequence, look at the the first number in each row (since that will be the smallest number in the row), up to limit number of rows. The limit is calculated as the number of rows that we've already taken one number from, plus one. This exploits the fact that the row heads are initially ordered. If we use a number from a row, shift that row down to remove the number used. It does pretty well, but I'd welcome any comments, or even suggestions of a completely different algorithm (for this little exercise, or problem 119). Thanks. Kurt Hutchinson

6 10

Erik Meijer's talk at Google?
by Galchin Vasili 16 Nov '07

16 Nov '07

Hello, Last week (?) Erik Meijer gave a talk at Google. Has a video been uploaded somewhere? Kind regards, Vasya

3 2

The percent operator
by PR Stanley 16 Nov '07

16 Nov '07

Hi I understand 2%4 will construct a fraction in Haskell. I've tried this in GHCI but got an error message. Is there such an operator in Prelude and if so how is it applied? Cheers, Paul

3 2

Chart plotting libraries
by Jon Harrop 16 Nov '07

16 Nov '07

I'd like some free software to help me plot charts like the one from the ray tracer language comparison: http://www.ffconsultancy.com/languages/ray_tracer/results.html I was using Mathematica but its stopped working and an upgrade is £2,000. Are there Haskell bindings to any free libraries or even Haskell implementations that would make something like this painless? There isn't anything for OCaml (that I'm not still writing ;-) so this might be a good opportunity to force me to do a little more Haskell. :-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

6 7

dropSpace not exported in ByteString
by Olivier Boudry 16 Nov '07

16 Nov '07

Hi all, I'm writing a Haskell program to do some address cleansing. The program uses the ByteString library. Data.ByteString.Char8 documentations shows functions for removing whitespace from start or end of a ByteString. Those functions are said to be more efficient than the dropWhile / reverse mixes. It looks exactly like what I'm searching for, but apparently those functions are not exported by the Data.ByteString.Char8 module. Are those functions only called by rules? Transformation of dropWhile isSpace into dropSpace? I've seen such a rule for dropSpace but did not found an equivalent rule for dropSpaceEnd. Is there a way to call the dropSpace and dropSpaceEnd or do I have to code with dropWhile and hope that some rule will magically transform my dropWhileS into dropSpaceS? Thanks, Olivier.

4 8

Re: Guidance on using asynchronous exceptions
by oleg＠pobox.com 16 Nov '07

16 Nov '07

Yang wrote: > Furthermore, is there any way to embed this information [about async > execptions] in the type system, so that Haskellers don't produce > async-exception-unaware code? (Effectively, introducing checked > interrupts?) Yes, it is possible to make the information about exceptions and interrupts a part of operation's type: http://www.haskell.org/pipermail/haskell/2004-June/014271.html Here is a simple illustration for your specific case > {-# OPTIONS -fglasgow-exts #-} > > module B where > import Control.Exception > > idarn _ msg = error msg > > myPutStrLn _ | False = idarn ?e_async "myPutStrLn is interruptible" > myPutStrLn x = putStrLn x *B> :t myPutStrLn myPutStrLn :: (?e_async::()) => String -> IO () Now it is obvious that myPutStrLn is subject to async interruptions > test1 x = do myPutStrLn "String" > myPutStrLn x *B> :t test1 test1 :: (?e_async::()) => String -> IO () and so can test1. The compiler figured that out. > myblock :: ((?e_async::()) => IO a) -> IO a > myblock x = let ?e_async = undefined -- meaning, we `handle' the exc > in block x If we try to *B> test1 "here" <interactive>:1:0: Unbound implicit parameter (?e_async::()) arising from use of `test1' at <interactive>:1:0-11 In the expression: test1 "here" In the definition of `it': it = test1 "here" meaning that we ought to `handle' that exceptional condition. The typechecker will not let us overlook the test. > -- ?e_async::t causes a problem: we really have to `handle' it > -- main = test1 "here" > test3 = myblock (test1 "here") *B> :t test3 test3 :: IO () The type of test3 shows that the condition is `handled'. And so test3 may now be run. > (Something like this is straightforward to build if I abandon > Concurrent Haskell and use cooperative threading, and if the > operations I wanted to perform could be done asynchronously.) All operations could be done asynchronously, at least on Linux and many Unixes: http://www.usenix.org/events/usenix04/tech/general/full_papers/elmeleegy/el… > (Something like this is straightforward to build if I abandon > Concurrent Haskell and use cooperative threading, and if the > operations I wanted to perform could be done asynchronously.) That seems as a very good idea. You might be aware that well-respected and well-experienced systems researchers call for *abandoning* threads. Threads are just a very bad model. The Problem with Threads Edward A. Lee http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html Also, IEEE computer, May 2006, pp. 33-42. >From the abstract: ``Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism. Although many research techniques improve the model by offering more effective pruning, I argue that this is approaching the problem backwards. Rather than pruning nondeterminism, we should build from essentially deterministic, composable components. Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed. The consequences of this principle are profound. I argue for the development of concurrent coordination languages based on sound, composable formalisms. I believe that such languages will yield much more reliable, and more concurrent programs.'' I believe that delimited continuations is a good way to build coordination languages, because delimited continuations let us build a sound model of computation's interaction with its context.

3 2

Haskellforge?
by Maurício 16 Nov '07

16 Nov '07

Hi, Is there a "Haskellforge" somewhere, i.e., something like a sourceforge for open source Haskell programs, with darcs, automatic cabalization etc.? Has anyone tried that already? Maurício

4 4

let vs. where
by John Lato 16 Nov '07

16 Nov '07

Hello, I know there are several important differences between let-expressions and where-clauses regarding scoping and the restriction of "where" to a top-level definition. However, frequently I write code in which either one would be allowed, and I was wondering if there were any guidelines or preferences for one structure over the other. Currently my choice is guided by aesthetics more than anything else ( I prefer the look and ordering of a where clause). Is there anything else I should consider? What do veteran Haskell programmers prefer? Thank you, John Lato

20 29