September 2008 - Haskell-Cafe

Re: [Haskell] The initial view on typed sprintf and sscanf
by Matthew Brecknell 02 Sep '08

02 Sep '08

oleg [1]: > We demonstrate typed sprintf and typed sscanf sharing the same > formatting specification. [1]http://www.haskell.org/pipermail/haskell/2008-August/020605.html Reading Oleg's post, I noticed that it is quite straightforward to generalise printing to arbitrary output types. > class Monoid p => Printf p where > printChar :: Char -> p > --etc > > intp :: Printf p => F a b -> (p -> a) -> b > intp FChr k = \c -> k (printChar c) > intp (a :^ b) k = intp a (\sa -> intp b (\sb -> k (mappend sa sb))) > --etc > > printf :: Printf p => F p b -> b > printf fmt = intp fmt id The Printf instances for String, ShowS, ByteStrings, and IO () are all trivial. Printing directly to a file (without building an intermediate string) is slightly more interesting: > instance Monad m => Monoid (ReaderT r m ()) where > mempty = return () > mappend = (>>) > > instance Printf (ReaderT Handle IO ()) where > printChar c = ask >>= \h -> liftIO (hPutChar h c) > --etc > > (<<) :: Handle -> ReaderT Handle IO () -> IO () > (<<) = flip runReaderT > > test_fprintf h = h << printf (lit "Hello " ^ lit "World" ^ chr) '!' Unfortunately, I don't seem to be able to make the expected fprintf function, because printf's format-dependent parameter list makes it impossible to find a place to pass the handle. Hence the C++-like (<<) ugliness.

5 5

Fast parallel binary-trees for the shootout: Control.Parallel.Strategies FTW!
by Don Stewart 01 Sep '08

01 Sep '08

The Computer Language Benchmarks Game recently got a quad core 64 bit machine. Initial results just porting the single-threaded Haskell benchmarks to 64 bit look rather pleasing, http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all Note that C++, D, Clean et al aren't ported to the 64 bit machine yet (and perhaps some implementations won't survive the 64 bit switch). Now, none of the Haskell programs are annotated for parallelism yet, despite that quad core sitting there ready to go. I've a conjecture that fast, smp capable, concise code, of the kind GHC produces, could dominate the shootout for a while to come, if we can effectively utilise those cores. This is a chance to make an impression! So, the first parallel benchmark has been submitted by Tom Davies and me, a parallel implementation of the binary-trees benchmark, using the Control.Parallel.Strategies lib to set up some top level parallel tasks. Initial results look promising, with the old entry: * Single core, no heap hints: 26.9s $ ghc -O2 -fasm Original.hs --make $ time ./Original 20 ./Original 20 26.79s user 0.16s system 100% cpu 26.933 total Looking at the GC stats (-sstderr) we see its spending too much time doing GC, 57.8%, so we can improve that by setting a default heap size: * Single core, with heap hints: 13.7s $ time ./Original 20 -A350M ... ./Original 20 +RTS -A350M 13.54s user 0.27s system 100% cpu 13.791 total Halves runtime in comparison to the current entry, and reduces GC to 3.8%. * Now, the parallel version, changing one line to use a parMap strategy, and using the N+1 capabilities rule, $ ghc -O2 -fasm Parallel2.hs --make -threaded $ time ./Parallel2 20 +RTS -N5 -A350M ... ./Parallel2 20 +RTS -N5 -A350M 15.38s user 1.57s system 305% cpu 5.684 total So 305% productive (not too bad for this memory-heavy program), and a good speedup. Observations: * check GC stats with -sstderr, then use -AxxxM to set a default heap size * parallelise the top level control using speculative strategies * Use -N+1 capabilities. -- Don

1 1

getting Quickcheck 2.0
by Wolfgang Jeltsch 01 Sep '08

01 Sep '08

Hello, is there a reason why Quickcheck 2.0 isn’t released via Hackage? Does anybody know where to get it? The darcs repository already has 2.1 as the version number in the Cabal file but Hackage still only has 1.1.0.0. Best wishes, Wolfgang

2 1

Haskell Propeganda
by Niels Aan de Brugh 01 Sep '08

01 Sep '08

On Sun, Aug 24, 2008 at 5:44 AM, Thomas M. DuBuisson < thomas.dubuisson(a)gmail.com> wrote: > wrt head [], Niels said: > > So now what? Action plan = [] > > Oh come now. Between ghci, hpc, and manual analysis I've never hit a > Haskell error and thrown my hands up, "I can't go any further, I'm at a > complete loss!" Also it helps that I run into this extremely rarely - I > have a larger habit of hidding black holes :-( I've never used Haskell in an engineering environment, but I have encountered problems that would've been easier to analyze with a step function (almost without exception in a stateful computation, e.g. functions using recursion or some state monad). For example, a graphical frond-end to the GHCi debugger would've been really helpful, especially for new users. C/C++ programmers on Linux have gdb but I know nobody that uses the tool directly on the bare command line. Niels said: > > Thank you for the URL, but I'm aware of the work in GHC(i). > > It might interest you to know some people actually use hpc for debugging > with reasonble success - it colors the unevaluated sections and this can > be very helpful in determining where a program stopped and threw an > exception. I haven't used HPC myself (I use -fwarn-incomplete-patterns but that's about it for "coverage" analysis) but it looks like a powerful tool. Statement and branch coverage are very imporant metrics e.g. to measure test coverage. However, I feel that using a profiler to do a debuggers job is really a poor man's solution. Just like the trace function (tracing/logging itself is useful, but not as a debugger tool). > If you have your eyes on the future you should see Dana Xu's work on > static contract checking (check out her Cambridge page). Thanks for the suggestion, I'll be sure to check that out. I use design by contract on a daily basis, but in a language like C++ it's never more than a couple of glorified asserts. My opinion is that if you want to do contracts good (i.e. not with some macro kludge) it needs to be embedded into the language. I've been looking at Spec#, that looks like a very powerful extension to C#. I think contracts could fit even better in a pure functional language. Checking contracts statically would be awesome, but doing dynamic DbC well is already harder than it seems (e.g. in concurrent code that uses locks). Regards, Niels

1 0

cabal update : getHostByName
by minh thu 01 Sep '08

01 Sep '08

Hi, I've followed the instruction from the upcoming book Real World Haskell to install cabal. Now, when I enter "cabal update", it answers this: Downloading package list from server 'http://hackage.haskell.org/packages/archive' cabal: getHostByName: does not exist (no such host entry) What's the problem ? Thanks a lot, Thu

3 4

Types in bounds
by Brettschneider, Matthias 01 Sep '08

01 Sep '08

Hey there, i was just thinking about types in Haskell and I asked myself, Is there a mechanism, that allows me to define a new type out of an existing one with some restrictions? So that the new type is a subset of the existing one. Lets imagine I want a type for a point like: type Point = (Int, Int) But what, if I can predict that the X and Y values are in a range between 0 and 100? If someone defines a new point like: p :: Point p = (200, 400) that is totally fine with the type definition above, but not correct in my context. Is it possible, to put this information into the type? So that the compiler is able to recognize my mistake? -- Matthias

3 3

Re: [Haskell-cafe] Re: Research language vs. professional language
by Sean Leather 01 Sep '08

01 Sep '08

> >> > This concept of `day-to-day work' is a curious one. Haskell is not a > >> > mature language, and probably shouldn't ever be one. > >> > >> I see where you are coming from here, but I think that train has > >> already started and can't be stopped. > > > > Yeah, it's too late. Too many people have their pay checks riding on > > GHC, the Hackage library set (now up to 740 libraries and tools!), and > > the continued development of the language in general. > > > > If Haskell's not "mature" yet, then perhaps it has reached its early > > twenties, with an reliable heavy duty optimizing compiler, fast runtime, > > large library set, standard documentation, testing, debugging and > > packaging tools, and large community. > > > > We're serious about this thing. > > So, what fills its shoes as a great research language with great tools? > I think the great thing about Haskell is that it works so well now and yet there's room for growth as well. That means that not only is research with the language more efficient, but also that the research tends to be more applicative to people using it. Consider, for example, the fact that the Haskell Workshop has grown into a symposium [1] and that there are so many relevant workshops affiliated with ICFP [2]. [1] http://www.haskell.org/haskell-symposium/ [2] http://www.icfpconference.org/#Affiliated Sean

1 0

Re: [Haskell-cafe] language proposal: ad-hoc overloading
by Philippa Cowderoy 01 Sep '08

01 Sep '08

Oops, forgot to send to list. On Mon, 2008-09-01 at 01:27 +0100, Philippa Cowderoy wrote: > On Mon, 2008-09-01 at 01:11 +0100, David House wrote: > > 2008/8/31 Ryan Ingram <ryani.spam(a)gmail.com>: > > > My proposal is to allow "ad-hoc" overloading of names; if a name is > > > ambiguous in a scope, attempt to type-check the expression against > > > each name. It is only an error if type-checking against all names > > > fails. If type-checking succeeds for more than one then the > > > expression is ambiguous and this is also an error. > > > > -1, at least for now. > > > > Haskell already has one method of overloading: type classes. What you > > propose is a seemingly innocent extension that I now doubt has > > extremely far-reaching consequences into the language. Such a feature > > should be properly researched before it is added to the language. > > Here's an example of such a concern: you write the following: > > > > import Data.Map > > foo = map > > > > What is the type of `foo'? > > If I've understood the proposal, that wouldn't check unless foo was used > in a way (within the module) that makes it clear which of Prelude.map or > Data.Map.map to use and uses it consistently. So if that's the entire > module, it wouldn't check. > > I'm still not keen, but in a sense the idea here is to avoid this > variety of overloading leaking into the type system itself: it could be > implemented (extremely naively) as "typecheck with each possible > permutation for resolving the overloading, use any unique solution or > fail if there isn't one". -- Philippa Cowderoy <flippa(a)flippac.org>

2 1