- Haskell-Cafe - Haskell.org

Fwd: stg_uncheckedShiftRL64 unresolved when compiling with GHC 6 8 2
by golubovsky＠gmail.com 23 Dec '07

23 Dec '07

Hi, I posted this to the HAppS discussion group, but maybe somebody is able to answer in the Cafe, at least where this unresolved symbol belongs to. It looks like the same problem was discussed earlier related to GHC 6.7, but I got this problem right now, compiling HPaste with HAppS (using SearchPath). The linker message is: =================================== During interactive linking, GHCi couldn't find the following symbol: stg_uncheckedShiftRL64 This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and - lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-b...@haskell.org =================================== Output from ghc-pkg -l: =================================== /home2/dima/install//lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, array-0.1.0.0, base-3.0.1.0, binary-0.4.1, bytestring-0.9.0.1, containers-0.1.0.1, directory-1.0.0.0, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, hscolour-1.6, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old- time-1.0.0.0, packedstring-0.1.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, unix-2.3.0.0, xhtml-3000.0.2.1, zlib-0.4.0.1 =================================== To save time I compiled only GHC without extralibs, and later installed packages that were msissng during compilation from extralibs or hackage. Are there any modules shown whose versions raise any suspicions? Thanks.

2 1

MPC 2008: SECOND CALL FOR PAPERS
by Shin-Cheng Mu 23 Dec '07

23 Dec '07

SECOND CALL FOR PAPERS 9th International Conference on Mathematics of Program Construction (MPC'08) Marseille (Luminy), France, July 15-18th 2008 http://mpc08.lri.fr BACKGROUND The biennial MPC conferences aim to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. Topics of interest range from algorithmics to support for program construction in programming languages and systems. The previous conferences were held in Twente, The Netherlands (1989), Oxford, UK (1992), Kloster Irsee, Germany (1995), Marstrand, Sweden (1998), Ponte de Lima, Portugal (2000), Dagstuhl, Germany (2002), Stirling, UK (2004, colocated with AMAST '04) and Kuressaare, Estonia (2006, colocated with AMAST '06). The 2008 conference will be held in Marseille, France at the International Center for Mathematical Meetings (http://www.cirm.univ-mrs.fr/web.ang) INVITED SPEAKERS To be announced. IMPORTANT DATES * Submission of abstracts: 14 January 2008 * Submission of full papers: 21 January 2008 * Notification of authors: 10 March 2008 * Camera-ready version: 10 April 2008 TOPICS Papers are solicited on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Some typical areas are type systems, program analysis and transformation, programming-language semantics, program logics. Theoretical contributions are welcome provided their relevance for program construction is clear. Reports on applications are welcome provided their mathematical basis is evident. SUBMISSION Submission is in two stages. Abstracts (plain text, 10 to 20 lines) must be submitted by 14 January 2008. Full papers (pdf) adhering to the llncs style must be submitted by 21 January 2008. There is no official page limit, but authors should strive for brevity. The web-based submission system is now open http://www.easychair.org/conferences/?conf=mpc08. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the conference by one of the authors. The proceedings of MPC'08 will be published in the Lecture Notes in Computer Science series of Springer-Verlag. After the conference, the authors of the best papers will be invited to submit revised versions to a special issue of the Science of Computer Programming journal of Elsevier. PROGRAMME COMMITTEE Christine Paulin-Mohring INRIA-UniversitÈ Paris-Sud, France (chair) Philippe Audebaud Ecole Normale SupÈrieure Lyon, France (co-chair) Ralph-Johan Back Abo Akademi University, Finland Eerke Boiten University of Kent, UK Venanzio Capretta University of Nijmegen, Netherlands Sharon Curtis Oxford Brookes University, UK Jules Desharnais UniversitÈ Laval, QuÈbec, Canada Peter Dybjer Chalmers University of Technology, Sweden Jeremy Gibbons University of Oxford, UK Lindsay Groves Victoria University of Wellington, New Zealand Ian Hayes University of Queensland, Australia Eric Hehner University of Toronto, Canada Johan Jeuring Utrecht University, Netherlands Dexter Kozen Cornell University, USA Christian Lengauer Universit‰t Passau, Germany Lambert Meertens University of Utrecht, Netherlands Bernhard Mˆller Universit‰t Augsburg, Germany Carroll Morgan University of New South Wales, Australia Shin-Cheng Mu Academia Sinica, Taiwan Jose Nuno Oliveira Universidade do Minho, Portugal Tim Sheard Portland State University, USA Tarmo Uustalu Institute of Cybernetics Tallin, Estonia VENUE The conference will be held in Marseille, the second largest city in France next to Paris. Its port is the most important in France, and opens the city to the world through the Mediterranean Sea. MPC'08 will be hosted by the International Center for Mathematical Meetings. The center is located inside the Campus of Luminy Faculty. It is close to the "Calanques", an astounding wild coastline composed of creeks stretching from Marseille to Cassis. LOCAL ORGANIZERS MPC 2008 is organized with the support of INRIA. The local organizers are Philippe Audebaud and Christine Paulin-Mohring with the help of Marie-RenÈe Fleury. Enquiries regarding the programme (submission etc.) should be addressed to mpc08(at)lri.fr

1 0

[15/16] SBM: Predictions compared to the measurements
by Peter Firefly Brodersen Lund 23 Dec '07

23 Dec '07

Don Stewart and Duncan Coutts were nice enough to give me some predictions regarding the performance of the programs in my teaser email. When I answered them, I hadn't yet written the code to merge reports so I hadn't yet noticed the general pattern of much worse memory performance on 6.9. Also, Don Stewart hadn't yet released bytestring 0.9.0.2 (he did so in order to fix performance problems pointed out by my teaser benchmarks, actually). >From Duncan Coutts: >I'll try guessing at some ratios: > >1.0 space-bslc8-foldlx-1 >1.1 space-bslc8-acc-1 >2.0 space-bs-c8-foldlx-1 >2.1 space-bs-c8-acc-1 >4.0 space-xxxxx-acc-1 >15 space-xxxxx-foldl I would put them in two groups (I disregard the lenfil benchmark because it was for "extra credit"): space-bslc8-foldlx-1 around 1.4/1.5s (1.2/1.1s with bytestring 0.9.0.2) space-bs-c8-foldlx-1 around 1.2s space-bs-c8-acc-1 around 1.1s (1.3s on 6.6.1) space-bslc8-acc-1 around 3.4s (6.4s on 6.6.1!) space-xxxxx-acc-1 around 5.0s (5.4s on 6.8.2) space-xxxxx-foldl around 5.0s (5.3/5.4s on 6.8.2) >From Duncan Coutts (on the "extra credit" program hs/space-bslc8-lenfil-1): >Hmm. So that should work in constant memory, a few 64 chunks at once. >I'd expect this to be pretty fast. Ok, this was mean of me. I knew there was a memory bug here :) >From Don Stewart: >Summary: the suspicious lazy bytestring program works now. (constant >space, and fastest overall, as expected originally) > >Program 1, lazy bytestring length . filter > > Yesterday: > ./A +RTS -sstderr < 150M 1.01s user 0.10s system 98% cpu 1.123 total > 40M allocated > > * Today (fixed!): > ./A +RTS -sstderr < 150M 0.26s user 0.06s system 96% cpu 0.332 total > 2M allocated > > Reason, deprecated array fusion mucking up the optimiser. > >I think we can close this regression. Nope. Look at the memory graphs: hs/space-bslc8-lenfil-1: 38632 ██████████▌ | -- 38644 ██████████▌ | -- 1940 ▌ | -- 109404 █████████████████████████████▋ | -- 82324 ██████████████████████▍ | -- 109388 █████████████████████████████▋ | -- 82304 ██████████████████████▎ | It is fixed for ghc 6.8.2 running bytestring 0.9.0.2 but not for ghc 6.9.20071119 and head (as of noon 2007-12-19), no matter the bytestring version. There are lots of memory performance bugs in ghc 6.9. I've reordered the time bar charts to use the same order as my teaser email. hs/space-bslc8-lenfil-1: 1.521 7‰ 0.2 ███████▊ | -- 1.295 1‰ 0.2 ██████▌ | -- 0.429 0‰ 0.2 ██▏ | -- 1.323 1‰ 0.1 ██████▊ | -- 0.483 2‰ 0.4 ██▌ | -- 1.327 1‰ 0.2 ██████▊ | -- 0.482 2‰ 0.4 ██▌ | (this was the "extra credit" program) hs/space-bs-c8-acc-1: 1.287 20‰ 0.2 ██████▌ | -- 1.131 2‰ 0.1 █████▊ | -- 1.132 2‰ 0.3 █████▊ | -- 1.145 1‰ 0.2 █████▊ | -- 1.150 1‰ 0.2 █████▉ | -- 1.147 2‰ 0.1 █████▊ | -- 1.147 2‰ 0.2 █████▊ | hs/space-bslc8-acc-1: 6.367 17‰ 0.2 ████████████████████████████████▎ | -- 3.396 7‰ 0.1 █████████████████▎ | -- 3.508 4‰ 0.1 █████████████████▊ | -- 3.388 10‰ 0.1 █████████████████▏ | -- 3.441 10‰ 0.1 █████████████████▍ | -- 3.438 3‰ 0.0 █████████████████▍ | -- 3.434 13‰ 0.1 █████████████████▍ | hs/space-xxxxx-acc-1: 5.036 7‰ 0.1 █████████████████████████▌ | -- 5.381 6‰ 0.0 ███████████████████████████▎ | -- 5.358 8‰ 0.1 ███████████████████████████▏ | -- 4.991 1‰ 0.1 █████████████████████████▎ | -- 5.047 7‰ 0.1 █████████████████████████▌ | -- 5.051 3‰ 0.1 █████████████████████████▋ | -- 5.049 4‰ 0.1 █████████████████████████▋ | hs/space-bs-c8-foldlx-1: 1.272 1‰ 0.2 ██████▌ | -- 1.205 2‰ 0.2 ██████▏ | -- 1.164 3‰ 0.0 █████▉ | -- 1.221 1‰ 0.1 ██████▏ | -- 1.176 1‰ 0.3 ██████ | -- 1.259 1‰ 0.1 ██████▍ | -- 1.176 1‰ 0.2 ██████ | hs/space-bslc8-foldlx-1: 1.430 1‰ 0.1 ███████▎ | -- 1.400 1‰ 0.1 ███████▏ | -- 1.197 1‰ 0.0 ██████ | -- 1.458 0‰ 0.1 ███████▍ | -- 1.060 1‰ 0.0 █████▍ | -- 1.457 1‰ 0.1 ███████▍ | -- 1.060 1‰ 0.2 █████▍ | hs/space-xxxxx-foldl: 5.024 5‰ 0.0 █████████████████████████▌ | -- 5.371 9‰ 0.0 ███████████████████████████▎ | -- 5.301 9‰ 0.1 ██████████████████████████▉ | -- 5.035 2‰ 0.1 █████████████████████████▌ | -- 5.037 3‰ 0.0 █████████████████████████▌ | -- 5.046 4‰ 0.0 █████████████████████████▌ | -- 5.042 4‰ 0.0 █████████████████████████▌ | -Peter

2 1

GtkMathView wrapper for Haskell / Gtk2HS?
by Peter Verswyvelen 23 Dec '07

23 Dec '07

Did anybody already wrap http://helm.cs.unibo.it/mml-widget so it can be used with Haskell / Gtk2HS? If not, would it be good project for me to learn Haskell's FFI? It involves C++, so I guess that would be harded to wrap? Thanks, Peter

2 1

Reducing the executable output filesize with GHC (on Windows)
by Peter Verswyvelen 22 Dec '07

22 Dec '07

I remember having read how to do this a while ago, but I can't google it back. How can I force the linker to exclude all the sections that are not referenced? I thought it had to do something with -split-objs? I've written a short consolemode program, but it compiles to 1.3MB. Since I will be creating a lot of these small apps, surely this filesize can be reduced? Thanks, Peter PS: The program I wrote is 250 lines of code. It is a simple vectormath exercise generator for my students which I wrote in 5 hours, something I would never been able to do in C++/C#, even though I have much more experience in the latter languages. Haskell's sooo nice, and I'm just scratching the surface of it. Thank to all of you guys for the hard work J

2 1

Is a type synonym declaration really a synonym ?
by alpheccar 22 Dec '07

22 Dec '07

Can someone confirm me that: type TA = A :+: B type TB = C :+: D type T = TA :+: TB is not equivalent to type T = A :+: B :+: C :+: D where I have defined infixr 6 :+: data (f :+: g) data A data B data C data D I have a computation at type level which is working with the later definition of T but not with the former (ghc 6.8.1) Thanks.

3 3

MonadFix
by Joost Behrends 22 Dec '07

22 Dec '07

Hi, since about three weeks i am learning Haskell now. One of my first excercises is to decompose an Integer into its primefactors. I already posted discussion on the solution to the problem 35 in "99 excercises". My simple algorithm uses a datatype DivIter of 4 named fields together with the core iteration divstep :: DivIter -> DivIter divstep x | divisor x > bound x = x | ximod > 0 = x { divisor = (divisor x) +2 } | otherwise = x {dividend=xidiv, bound=intsqrt(xidiv), result = result x ++ [divisor x] } where (xidiv, ximod) = divMod (dividend x) (divisor x) (dividend x is already odd, when this is called). The problem to solve for really large Integers is how to call divstep iterated without not accumulating billions of stack frames. Here is one possibility: divisions = do y <- get if divisor y <= bound y then do put ( divstep y ) divisions else return y (this for a version of divstep without the first guard) called from res = execState divisions (DivIter { dividend = o1, divisor = 3, bound = intsqrt(o1), result = o2 }) ( where o1 "the odd part" of the number to decompose, o2 a list of its "contained" twos). This computes the primefactors of 2^120+1 in 17 minutes after all. But i cannot help feeling that this is an abuse of the State monad. The MonadFix has a function fix (a -> a) -> a and i added the first guard in divstep above for making this a fixpoint problem. For me the signature looks, as if using fix doesn't afford to create explicitely a variable of a MonadFix instance and a simple twoliner for divisions could do the job. What i do not understand at all from the documentation of fix is: "fix f is the least fixed point of the function f, i.e. the least defined x such that f x = x." What does "least" mean here ? There is nothing said about x being a variable of an instance of Ord. And why fix has not the type a -> (a -> a) -> a, means: How can i provide a starting point of the iteration x ==> f x ==> f (f x) ==> ...?

7 17

Hoogle search scope question -- was: [HXT] Simple question
by Steve Lihn 22 Dec '07

22 Dec '07

I have a hoogle question. While I was reading the HXT discussion (below), I tried to search "runX" and "readString" in Hoogle (since I am new to HXT and Arrows). But neither search yielded any result and I had to use google to find the Haskell docs. So I am wondering what is the scope of Hoogle that people can search? Only things in the standard library? How much does it cover in the Hackage? I tried to find the scope description in the Tutorial but in vain. It is fair to say if someone needs to use Hoogle, he/she probably has no idea what he is looking for, needless to say, what is in scope of Hoogle or what is not. Thanks, Steve On Dec 19, 2007 7:48 AM, Miguel Mitrofanov <miguelimo38(a)yandex.ru> wrote: > Seems rather strange for me, I've just installed HXT and got this: > > Prelude Text.XML.HXT.Arrow> runX $ readString [(a_validate,"0")] "<this> </this>" >>> writeDocumentToString [] > ["<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<this> </this>"] > > > Everything works fine except for the fact that all the nodes <this> > > </this> > > (that is, a space (an XML text node whose contents are a single space > > character) > > within a <this> element node) get transformed to a <this/> element node, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Functions are first class values in C
by Cristian Baboi 22 Dec '07

22 Dec '07

Let me show you an example to prove it. The example is limited to composition of unary functions defined on int u::Int->Int v::Int->Int o ::(Int->Int)->(Int->Int)->(Int->Int) o u v= \x->u(v(x)) #include <stdio.h> #include <conio.h> #include "functional.h" int f1(int x){ return x+x; } int f2(int x){ return 2*x; } int g1(int x){ return x+1; } int g2(int x){ return x-1; } #define P1 P0 int main(){ #define P2 P1 printf("%d,%d,%d\n",2, #define P3 O(f1,f2,P2)(2), #define P4 O(g1,g2,P3)(3)); #define P5 P4 getch(); #define P6 P5 } MAIN P6 Here is the file functional.h #define FUNC2(x,y) x##y #define FUNC1(x,y) FUNC2(x,y) #define FUNC(x) FUNC1(x,__COUNTER__) #define COMP(c,f,g,p) \ int c (int x) { return f(g(x)); }; \ p \ c #define O(f,g,p) COMP( FUNC(a), f, g, p) #define P0 #define MAIN

6 9

Dynamic typing of polymorphic functions
by oleg＠okmij.org 22 Dec '07

22 Dec '07

Alfonso Acosta wrote: > mapSY :: (Typeable a, Typeable b) => (a -> b) -> Signal a -> Signal b > mapSY f (Signal primSig) = Signal (PrimSignal (MapSY (toDyn f) primSig)) > > The following process would be really useful but its compilation > obviously fails: > > mapSnd :: Signal (a, a) -> Signal a > mapSnd = mapSY snd > > > Could not deduce (Typeable a) from the context () arising from a > use of `mapSY' > Possible fix: > add (Typeable a) to the context of the type signature for `mapSnd' It seems the compiler's complaint is reasonable. The signature of the mapSY function says that mapSY may only be applied _provided_ that type variables 'a' and 'b' are instantiated to the types that are members of Typeable. That is, mapSY has a condition on its use. When you write > mapSndInt :: Signal (Int, Int) -> Signal Int > mapSndInt = mapSY (snd :: (Int, Int) -> Int) the condition is satisfied: 'a' and 'b' are instantiated to Int, and Int is a member of Typeable. The definition of mapSnd has no constraint. The compiler is upset: mapSY requires a condition, and mapSnd does not provide any, and there is no obvious way how an obligation Typeable a could have been satisfied otherwise. So, writing > mapSnd :: Typeable a => Signal (a, a) -> Signal a > mapSnd = mapSY snd is the logical thing to do. > Well, strangely enough, adding the "Typeable a" constraint hushed GHC > but an error was instead triggered at runtime. Perhaps the latter is the real problem. If one switches to dynamic typing, the type errors show up as run-time errors. I believe the typing of eval is a bit odd (and also not very useful). The following code seems to work. It also shows how to apply a polymorphic function, pairing, to to signals of any type. Here's a test: > signal3 = cons const0 (cons const0 const1) *Foo> :t signal3 signal3 :: Signal (Int, (Int, Float)) > test1 = mapSnd signal3 test1 :: Signal (Int, Float) > test12 = beval test1 *Foo> :t test12 test12 :: (Int, Float) *Foo> test12 (0,1.0) {-# OPTIONS -fglasgow-exts #-} module Foo where import Data.Typeable import Data.Dynamic -- the phantom type parameter makes signal typing consistent newtype Signal a = Signal PrimSignal newtype PrimSignal = PrimSignal (Proc (PrimSignal)) data Proc input = MapSY Dynamic -- The processing function input -- The process input -- the rest of the processes are omitted | Const Dynamic | Cons Dynamic input input eval :: PrimSignal -> Dynamic -- evaluates the output of a process for one input eval (PrimSignal (MapSY dynF dynIn)) = dynApp dynF (eval dynIn) eval (PrimSignal (Cons cns a1 a2)) = dynApp (dynApp cns (eval a1)) (eval a2) eval (PrimSignal (Const inp)) = inp -- better eval beval :: Typeable a => Signal a -> a beval (Signal s) = maybe undefined id (fromDynamic (eval s)) -- sample signals const0 :: Signal Int const0 = Signal (PrimSignal (Const (toDyn (0::Int)))) const1 :: Signal Float const1 = Signal (PrimSignal (Const (toDyn (1::Float)))) -- the map process constructor mapSY :: (Typeable a, Typeable b) => (a -> b) -> Signal a -> Signal b mapSY f (Signal primSig) = Signal (PrimSignal (MapSY (toDyn f) primSig)) add1 :: Signal Int -> Signal Int add1 = mapSY ((+1) :: Int -> Int) mapSndInt :: Signal (Int, Int) -> Signal Int mapSndInt = mapSY (snd :: (Int, Int) -> Int) -- it is important to give the signature to (,) below: we pack the cons -- function of the right type! cons :: forall a b. (Typeable a, Typeable b) => Signal a -> Signal b -> Signal (a,b) cons (Signal sig1) (Signal sig2) = Signal (PrimSignal (Cons (toDyn ((,)::a->b->(a,b))) sig1 sig2)) mapSnd :: (Typeable a, Typeable b) => Signal (b, a) -> Signal a mapSnd = mapSY snd signal3 = cons const0 (cons const0 const1) -- *Foo> :t signal3 -- signal3 :: Signal (Int, (Int, Float)) test1 = mapSnd signal3 -- test1 :: Signal (Int, Float) test11 = let Signal s = test1 in eval s -- *Foo> test11 -- <<(Int,Float)>> -- Too bad. But we can do better. test12 = beval test1 {- *Foo> :t test12 test12 :: (Int, Float) *Foo> test12 (0,1.0) -}

2 2