January 2009 - Haskell-Cafe

HPC and literate haskell
by Pavel Perikov 29 Jan '09

29 Jan '09

Hi, list! I have a file: \begin{code} module Main where import MyModule main=do print "hello" \end{code} MyModule is in MyModule.lhs when building with ghc -o main -fhpc --make Main.lhs I get perfectly working code, but MyModule.mix lacks any usable coverage information: Mix "./MyModule.lhs" 1233320065 1385570408 1 [] After renaming MyModule.lhs to MyModule.hs and unlitting it everything works fine: Mix "./MyModule.hs" 1233320249 3220649115 1 [(3:8-3:8,ExpBox False), (3:9-3:9,Exp Box False),(3:7-3:10,ExpBox False),(3:1-3:10,TopLevelBox ["func2"])] I'm using ghc 6.10.1 on Mac OSX. Does anyone have this problem? are any workarounds available? Pavel

2 1

A ghc-6.10.1 bug or a feature?
by Juraj Hercek 29 Jan '09

29 Jan '09

Hello people, I've recently tried this: $ uname -smpr Linux 2.6.28-ARCH x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> a <- readFile "/sys/devices/system/cpu/online" Prelude> length a `seq` a "^CInterrupted. Prelude> writeFile "/tmp/test.txt" "12345\n" Prelude> b <- readFile "/tmp/test.txt" Prelude> length b `seq` b "12345\n" Prelude> The main problem is the "C^Interrupted." above. The input doesn't get read out till the end of the file for some reason when dealing with files in /sys directory (tried also others: /sys/devices/plaform/coretemp.0/temp1_input or /sys/devices/system/cpu/cpu0/cpufreq/cpufreq_cur_freq). Sometimes, the string from file in /sys gets read (with a slow delay), but most of the times it didn't. Everything works fine for a file in /tmp. Cat-ing files from shell works perfectly in /sys and /tmp. I tried also other machine: % uname -smpr Linux 2.6.28-ARCH i686 Intel(R) Pentium(R) 4 CPU 2.00GHz with the same effect. I didn't have this problem with ghc-6.8.2. Any idea? -- Juraj

3 4

The future of purely functional user interfaces?
by Andrzej Jaworski 29 Jan '09

29 Jan '09

Yes, it is something unhealthy to seat on a bunch of far reaching ideas and still use artifact that even Microsoft tries to shake off (outsourcing their Office XML Ribbons). But as recent roar about monoids have shown - those who are Haskell most productive programmers are also most unlikely to tap on anything theoretical. Researchers on the other hand wouldn't be who they are if they thought mainly in terms of code. Perhaps some new model of cooperation between a researcher and a group of volunteers should be worked out. > Other work [4] seems to indicate that arrows are too general for the > dataflow programming and co-monads are more suitable and hence might be > usable for interactive interfaces. I would be careful with moderating ambition here. It should be extremely open framework that could allow to accommodate all present experimental (mostly reactive) stuff but also allow close integration with functional database in the future. The GUI should also lower overheads for Geometric Algebra. I think that in the future GA, fractals and wavelets will be inbuilt on graphic cards and GUI might take a role of a sort of a synthesizer. But of course anything functional would open lots of new possibilities and give us a lot of fun. Cheers, Andrzej

1 0

Current research on overlapping/closed type families?
by Ryan Ingram 29 Jan '09

29 Jan '09

What's the status of overlapping/closed type families? I'm interested in something like the following, which can currently be implemented in GHC with Oleg-magic using functional dependencies, but cannot, to my knowledge, be implemented with type families: data HTrue = HTrue data HFalse = HFalse type family IsFunction f {- not legal in GHC6.10 -} type instances IsFunction (a -> b) = HTrue IsFunction a = HFalse -- ryan

3 4

Re: C-like Haskell
by John Lato 29 Jan '09

29 Jan '09

> On Wed, 2009-01-28 at 20:11 -0500, sam lee wrote: >> Did you print it? I'm using same code with ghc --make -O2 and it >> takes forever to finish. > > Yes, you can see in the output that it prints the same answer in each > case. I was using r = 10^9 as you suggested. I wouldn't call these answers the same. Can this be ascribed to an overflow error? > >> > C version: >> > $ time ./circ >> > 3141592649589764829 ^^ > >> > Haskell version: >> > time ./circ2 >> > 3141592653589764829 ^^ John Lato

2 2

ANN: logfloat 0.10, 0.11
by wren ng thornton 29 Jan '09

29 Jan '09

-------------------------------------------- -- logfloat 0.10, 0.11 -------------------------------------------- This package provides a type for storing numbers in the log-domain, primarily useful for preventing underflow when multiplying many probabilities as in HMMs and other probabilistic models. The package also provides modules for dealing with floating numbers correctly. -------------------------------------------- -- Compatibility / Portability -------------------------------------------- The package is compatible with Hugs (September 2006) and GHC (6.8, 6.10). For anyone still using GHC 6.6, the code should still work if you replace LANGUAGE pragma by equivalent OPTIONS_GHC pragma. The package is not compatible with nhc98 and Yhc because Data.Number.RealToFrac uses MPTCs. The other modules should be compatible. -------------------------------------------- -- Changes for 0.11 (since 0.10) -------------------------------------------- * Moved the RealToFrac class from Data.Number.Transfinite to Data.Number.RealToFrac. This breaks backwards compatibility if you depended directly on that module for the class. If you imported the class from Data.Number.LogFloat then you're still fine. -------------------------------------------- -- Changes for 0.10 (since 0.9.1) -------------------------------------------- * Hugs' Prelude definitions of isInfinite and isNaN for Float and Double are buggy. The new Hugs.RealFloat module provides correct implementations (defaulting to the Prelude definition for non-Hugs compilers). * The PartialOrd and Transfinite instances for Double and Float have been updated to use these corrected functions. * Added maxPO and minPO to PartialOrd and added comparingPO to Data.Number.PartialOrd. * Minor changes to circumvent bugs in Hackage's new version of Haddock. You should be able to see all the documentation now. * (0.9.1.1) Minor changes to compile cleanly on GHC 6.10 -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat/ Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ code.haskell.org is down at present so the Darcs repo is lagging Hackage. This will be corrected soon. -- Live well, ~wren

1 0

clean's gui toolkit
by Martin DeMello 29 Jan '09

29 Jan '09

I've been wondering - Clean ships with a fairly capable looking GUI toolkit [http://clean.cs.ru.nl/About_Clean/Standard_I_O_Lib/standard_i_o_lib.html] - has anyone used it? How does it compare to the available Haskell options? martin

1 0

The future of purely functional user interfaces? (was "Why binding to existing widget toolkits doesn't make any sense")
by Peter Verswyvelen 29 Jan '09

29 Jan '09

Haskell desperately needs something like Windows Presentation Foundation or http://www.piccolo2d.org... (so no GUIs but ZUIs :) but then purely functional. I'm pretty sure when a good framework is made, the community would contribute all kinds of widgets. IMO currently no Haskell framework has made it into something of production quality for creating purely functional user interfaces. Some research papers have been written (Fudgets, Gadgets, Fruit, Yampa, Reactive, ...), and some attempts have been made, but I guess nobody has written a large UI application with any of these toolkits (maybe House [1] - on OS written in Haskell that uses an updated Gadgets library - is the exception, but I haven't looked at the details of it yet) Maybe Yampa could be usable for building UIs - but I believe it has scalability issues because it is fully pull based, although it seems work is being done here [2] Reactive should be more scalable, and maybe one day it will be stable enough to build large interactive UIs (maybe together with Fieldtrip), but it seems it will need some redesign [3] Grapefruit also looks promising, as it combines arrows with push based techniques. Other work [4] seems to indicate that arrows are too general for the dataflow programming and co-monads are more suitable and hence might be usable for interactive interfaces. It would be nice to hear opinions about "purely functional user interfaces" and its future. Isn't it a bit of a lost battle if people can't create *real* and complex user interfaces in Haskell without completely switching to an imperative style of programming (GTK2HS, wxHaskell, etc) Cheers, Peter Verswyvelen [1] http://web.cecs.pdx.edu/~kennyg/house/ [2] http://www.citeulike.org/user/msakai/article/3813058 [3] http://conal.net/blog/posts/why-classic-frp-does-not-fit-interactive-behavi… [4] http://lambda-the-ultimate.org/node/988 On Wed, Jan 28, 2009 at 10:01 PM, Achim Schneider <barsoap(a)web.de> wrote: > John Lato <jwlato(a)gmail.com> wrote: > > > Achim Schneider wrote: > > > > > > So what's left of those TK's if we don't use their abstractions and > > > replace them with Haskell? Drawing and layouting, that's what's > > > left[3]. Both, IMNSHO, do not justify carrying around bloaty > > > external dependencies, they're too trivial. They certainly don't > > > justify using unsafePerformIO to hide foreign side effects and the > > > headaches associated with it. > > > > > > > > > So, if you don't mind, I'm going to stop trying to fit cubes into > > > round holes and gonna use reactive and fieldtrip[4] to do things. > > > > > > > Does this mean you're volunteering to create a fieldtrip-based toolkit > > with widgets and layout? > > > Most likely, no. fieldtrip uses glut, which only supports one os-level > window and is therefore borked for a considerable amount of stuff one > wants a TK be able to do. It (currently) also doesn't support > orthographic projection, which you need to properly position 2d. In > the end, it's a small and great library for stuff you don't need for > a TK, and is thus quite unsuited as a platform for one. Fieldtrip > widgets are another thing, of course. > > > I'm not volunteering for anything. I'm just hacking away on stuff and > following some inspiration I had while I implemented a simplistic > widget UI under J2ME, limited to what the game needed. > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Dependencies conflict
by Martijn van Steenbergen 29 Jan '09

29 Jan '09

Hello, $ cabal install category-extras Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 What does this message mean? It makes little sense to me -- ghc-6.10.1 requires both process ==1.0.1.1 and process ==1.0.1.0? And, more importantly, how do I solve this? Below is my output of ghc-pkg list. Thanks much, Martijn. $ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf: Cabal-1.6.0.1, HUnit-1.2.0.3, QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), editline-0.2.1.0, filepath-1.1.0.1, (ghc-6.10.1), ghc-prim-0.1.0.0, haddock-2.3.0, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.2, integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.0, template-haskell-2.3.0.0, time-1.1.2.2, unix-2.3.1.0, xhtml-3000.2.0.1 /Users/Martijn/.ghc/i386-darwin-6.10.1/package.conf: HTTP-3001.1.5, binary-0.4.4, brainfuck-0.1, cpphs-1.6, data-accessor-0.1.4, data-accessor-template-0.1.4, extensible-exceptions-0.1.1.0, fgl-5.4.2.2, ghc-paths-0.1.0.5, haddock-2.4.1, haskeline-0.6.0.1, haskell-src-exts-0.3.12, haskell-src-exts-0.4.4, haskell-src-exts-0.4.6, haskell-src-exts-0.4.8, haskell98-1.0.1.0, hscurses-1.3.0.2, iconv-0.4.0.2, lambdabot-utils-4.2, oeis-0.2, parsec-3.0.0, process-1.0.1.1, readline-1.0.1.0, show-0.3.1, smallcheck-0.4, tagsoup-0.6, terminfo-0.3, uniplate-1.2.0.3, unlambda-0.1, utf8-string-0.3.3, zlib-0.5.0.0

3 3

ANN: incremental-sat-solver
by Sebastian Fischer 29 Jan '09

29 Jan '09

Simple, Incremental SAT Solving as a Library ============================================ This Haskell library provides an implementation of the Davis-Putnam- Logemann-Loveland algorithm (cf. <http://en.wikipedia.org/wiki/DPLL_algorithm >) for the boolean satisfiability problem. It not only allows to solve boolean formulas in one go but also to add constraints and query bindings of variables incrementally. The implementation is not sophisticated at all but uses the basic DPLL algorithm with unit propagation. The package is available at: <http://hackage.haskell.org/cgi-bin/hackage-scripts/package/incremental-sat-… > Unlike 'sat' and 'sat-micro-hs' it is a library, and unlike 'libsat' it provides an interface for incremental solving. On the other hand, the implementation is much simpler (and probably less efficient) than 'libsat's. You are invited to improve on that, if you like. The code is on github: <http://github.com/sebfisch/incremental-sat-solver> Cheers, Sebastian

2 2