- Haskell-Cafe - Haskell.org

Re: [Haskell] [Fwd: Re: Computer Language Shootout]
by Fawzi Mohamed 27 Feb '07

27 Feb '07

On Feb 27, 2007, at 3:51 PM, Andrzej Jaworski wrote: > [...] > Nevertheless my point is still valid: when on compiler side the > heap is > stretched and on program side you need Ockham's Razor in action > Haskell > chokes. I hoped at least to stimulate interest in repeating GP > experiment > with latest GHC version. This could make a hot publication and > save nice > people from reappearance of this thread:-) > > (the experiment: > http://www.dcs.ed.ac.uk/home/stg/sfpw/book/Garmendia-Doval/ > cameraready.ps) Thanks for the link! I had not found it. An interesting read. Indeed it would be very interesting to repeat the experiment with the actual GHC... Sincerely Fawzi

1 0

Re: [Haskell] [Fwd: Re: Computer Language Shootout]
by Fawzi Mohamed 27 Feb '07

27 Feb '07

On Feb 27, 2007, at 1:59 PM, Sven Panne wrote: > On Tuesday 27 February 2007 13:44, Andrzej Jaworski wrote: >> I have learned logic from much deeper sources;-) >> My statement was: >> Guys started in Haskell and got to conclusion that for performance >> reasons >> it is better to move to C. The guys know what they are doing. >> >> I hope that helps;-) > > Hmmm, is there any paper/blog/etc. describing exactly what the > performance > problems were? If something is too slow, usually either the language > implementor or the language user can learn something. Furthermore, > when > moving from programming language X to Y and seeing performance > improvements, > it is more often than not the case that the reason for this is not > that Y is > faster than X, but that one has learned a lot about the problem when > implementing in X. So in general you see an improvement even when X > == Y, > i.e. dump your old Haskell code and start from scratch. I could not find references for the other stuff, but for Algebraic Dynamic Programming I found this http://bibiserv.techfak.uni-bielefeld.de/adp/adplit.html and citing my previous message ;) >>> they went from an embedded haskell implementation to a direct >>> compiler implementation. >>> >>> From what I understood I believe that mis-performance in that >>> case came from the embedded nature of the DSL >>> 1) not having a specialized parsing step (making the usage more >>> difficult) >>> 2) no abstract representation of the program that could be >>> optimized with special transformations relative to the DSL >>> 3) not fully optimized kernel methods >>> >>> writing a real compiler for that language made sense, and also >>> the choice of c as language for it, but I think that it would >>> have been possible to write it in haskell without a big >>> performance hit. I haven't seen that haskell compiler >>> significantly worse than others except in really low level >>> computational code, which (with more effort than with C) can be >>> optimized so that it is not really so terribly worse. >>

1 0

Delaling with State StateT and IO in the same function
by Alfonso Acosta 27 Feb '07

27 Feb '07

Hello, I know StateT is exactly aimed at dealing with a state and an inner monad but I have an example in which I have to mix State and IO and in which I didn't get to an elegant solution using StateT. I have a higher order function which gets some State processing functions as input, makes some internal operations with IO and has to return a State as output. My (ugly) function interface is netlist :: DT.Traversable f => (State s (S HDPrimSignal) -> State s v ) -> -- new (State s (Type,v) -> S v -> State s ()) -> -- define State s (f HDPrimSignal) -> -- the graph StateT s IO () The returned type is a StateT and the only way in which I succesfully managed to internally work with both State and StateT is converting from the former to the later one using this function (not elegant at all) state2StateT :: Monad m => State s a -> StateT s m a state2StateT f = StateT (return.runState f) I tried avoiding to use state2StateT by changing the interface to netlist :: DT.Traversable f => (State s (S HDPrimSignal) -> State s v ) -> -- new (State s (Type,v) -> S v -> State s ()) -> -- define State s (f HDPrimSignal) -> -- the graph State s (IO ()) but the function ended up being even uglier and I had to be care full about all the internal IO actions being executed (it is aesy to formget about it), let me show a (quite stupid) example myState :: State () (IO ()) myState = (return $ putStrLn "first line") >> (return $ putStrLn "second line") > eval myState () second line The first line is obviously lost Here is the full code of my function (many type definitions are missing but I hope it is understandable anyway) import qualified Data.Traversable as DT (Traversable(mapM)) import qualified Control.Monad.Trans import Language.Haskell.TH(Type) netlist :: DT.Traversable f => (State s (S HDPrimSignal) -> State s v ) -> -- new (State s (Type,v) -> S v -> State s ()) -> -- define State s (f HDPrimSignal) -> -- the graph StateT s IO () -- Generates a netlist given: -- new: generates the new (and normally unique) tag of every node given -- the iteration state which is updated as well. -- define: given the tag of a node, -- current iteration state, its type, and the tag of its children, -- generates the netlist of that node, updating the iteration state -- pSignals: the graph itself, a traversable collection of root -- signals including the initial state of the iteration -- It returns the final iteration state and the tags of outputs -- (root primitivesignals) netlist new define pSignals = do f <- state2StateT pSignals tab <- lift table let -- gather :: State s HDPrimSignal -> StateT s IO v gather sm = do HDPrimSignal t node <- sm visited <- lift (find tab node) case visited of Just v -> return v Nothing -> do let sP = deref node v' <- state2StateT (new (return sP)) lift (extend tab node v') sV <- DT.mapM (gather.return) sP state2StateT (define (return (t,v')) sV) return v' in DT.mapM (gather.return) f >> return() ---- just in case it helps table :: IO (Table a b) find :: Table a b -> Ref a -> IO (Maybe b) extend :: Table a b -> Ref a -> b -> IO () ---- Maybe is asking too much but would anyone be able to provide a more elegant netlist function which ... option a) returns StateT but doesn't make use of state2StateT? or option b) returns State but doesnt end up being messy? Thanks in advance, Alfonso Acosta

3 5

Safe lists with GADT's
by oleg＠pobox.com 27 Feb '07

27 Feb '07

Stefan O'Rear wrote: > Personally I like the GADT approach best since it is very flexible and > convienient. I have never used a purpose-build computer proof system, > but (modulo _|_) it took me less than 10 minutes to answer > LoganCapaldo (on #haskell)'s challenge to proof that + was commutative > ( http://hpaste.org/522 ) I'm afraid it may be premature to call this a proof. Here's your code > data S x > data Z > > data Add :: * -> * -> * -> * where > AddZZ :: Add Z Z Z > AddS1 :: !(Add x y z) -> Add (S x) y (S z) > AddS2 :: !(Add x y z) -> Add x (S y) (S z) > > add_is_commutatative :: Add a b c -> Add b a c > add_is_commutatative (AddZZ) = AddZZ > add_is_commutatative (AddS1 a) = AddS2 (add_is_commutatative a) > add_is_commutatative (AddS2 a) = AddS1 (add_is_commutatative a) First of all, where is the coverage proof? Given two numbers, S (S Z) and S Z, how to find their sum using the above code? Someone needs to construct the sequence of Adds, _at run-time_! But where is the proof that the sequence of Add applications expresses all possible ways of computing the sum, and each possible sum can be represented as a sequence of Adds? One may say -- this is so trivial; to which I reply that the original question was trivial as well. If we talk about the formal _proof_, then let's do it rigorously and formally all the way. Also, we can write > main = let x = AddS1 (undefined::Add Z Z (S Z)) in print "OK" > main2 = let x = add_is_commutatative (undefined::Add Z Z (S Z)) in print "OK" and the evaluation of 'main' and main2 prints OK. Thus we need to do forcing _all_ the way. But what if we forget some forcing? Incidentally, this is exactly what happened: add_is_commutatative should have been strict. But the code above misses the strictness annotation and still it compiles and seems to work -- and gives one a reason to call it a proof despite the deficiency. I'm afraid I have little trust in the system that permits such lapses. > but (modulo _|_) That is quite an unsatisfactory disclaimer! From the CH point of view, Haskell is inconsistent as every type is populated. Showing that a function is total is precisely demonstrating that the function is the proof of its type. So, showing the absence of bottoms is precisely making the proof! The problem with GADTs and other run-time based evidence is just that: _run-time_ based evidence and pattern-matching. In a non-strict system, checking that the evidence is really present is the problem on and of itself. BTW, Omega, Dependent ML and a few other systems with GADTs are strict.

3 2

problems installing ghc 6.6 with extralibs (bad interface file)
by Thomas Hartman 27 Feb '07

27 Feb '07

I installed ghc 6.6 from source ok. But then when I tried installing it with the "extralibs" to get all the functionality that had been unbundled in 6.6, I hit a glitch. Anyone ever seen anything like this? In case it matters, this is ssh-ed in to a virtualized user mode linux session. ***************************************** thartman@linodewhyou:~/haskellInstalls$ cat install-ghc-6.6.sh if [ ! -f ghc-6.6-src.tar.bz2 ]; then wget http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src.tar.bz2 fi if [ ! -f ghc-6.6-src-extralibs.tar.bz2 ]; then wget http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src-extralibs.tar.bz2 fi tar -tvjf ghc-6.6-src.tar.bz2 tar -tvjf ghc-6.6-src-extralibs.tar.bz2 pushd ghc-6.6 ./configure make make install popd thartman@linodewhyou:~/haskellInstalls$ sudo ./install-ghc-6.6.sh 2>&1 | tee out.txt thartman@linodewhyou:~/haskellInstalls$ tail -n20 out.txt ------------------------------------------------------------------------ make[2]: Nothing to be done for `install'. ------------------------------------------------------------------------ == make install - --no-print-directory -r; in /home/thartman/haskellInstalls/ghc-6.6/utils/ghc-pkg ------------------------------------------------------------------------ Creating a symbolic link from ghc-pkg-6.6 to ghc-pkg in /usr/local/bin for i in ghc-pkg-6.6; do \ /usr/bin/install -c -m 755 $i /usr/local/bin; \ done /usr/local/bin/ghc -H16m -O -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -i../../compat -ignore-package Cabal -Rghc-timing -c Main.hs -o Main.o -ohi Main.hi Main.hs:19:0: Bad interface file: ../../compat/Distribution/InstalledPackageInfo.hi mismatched interface file versions: expected 6060, found 6 <<ghc: 24591324 bytes, 4 GCs, 106128/106128 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.02 elapsed), 0.25 MUT (0.42 elapsed), 0.10 GC (0.12 elapsed) :ghc>> make[2]: *** [Main.o] Error 1 make[1]: *** [install] Error 1 make: *** [install] Error 1 ~/haskellInstalls thartman@linodewhyou:~/haskellInstalls$

2 1

Re: Re: [Haskell-cafe] Build failed - hidden package ?
by Dunric 27 Feb '07

27 Feb '07

Yes, that did the trick. Thank You. >-----Puvodni zprava----- >Od: J. Garrett Morris [mailto:trevion@gmail.com] >Komu: Dunric <dunric29a(a)atlas.cz> >Předmět: Re: [Haskell-cafe] Build failed - hidden package ? > > >Hello, > >Are you building with Cabal? In case you are, Cabal hides all >packages by default and only shows those which are mentioned in your >cabal file. To fix this, you can add 'base' to the build-depends: >list. > >If you're not using Cabal, I don't have a clue. (-; > >Good luck! > >/g > >On 2/26/07, Dunric <dunric29a(a)atlas.cz> wrote: >> Hi. >> I've got stuck with the following compilation error I probably can't fully understand: >> >> ---------------------------------------------------------------------- >> Building library... >> ... >> Using package config file: /usr/local/lib/ghc-6.6/package.conf >> wired-in package base mapped to base-2.0 >> wired-in package rts mapped to rts-1.0 >> wired-in package haskell98 mapped to haskell98-1.0 >> wired-in package template-haskell mapped to template-haskell-2.0 >> Hsc static flags: -static >> ... >> Graphics/UI/SDL/Rotozoomer.hs:15:7: >> Could not find module `Foreign.C': >> it is a member of package base, which is hidden >> >> ---------------------------------------------------------------------- >> >> What does such error mean ? >> >> Modules Foreign and Foreign.C are installed and available from the default path. >> Lines 12-15 of Rotozoomer.hs: >> ------------------------------------------ >> module Graphics.UI.SDL.Rotozoomer where >> >> import Foreign >> import Foreign.C >> ------------------------------------------ >> >> Any idea what's wrong, resp. some explanation why compilation fails ? >> >> Thanks in an advance. >> >> ------------------------------------------ >> >> www.icqsms.cz >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > >-- >It is myself I have never met, whose face is pasted on the underside of my mind. ------------------------------------------ www.icqsms.cz

1 0

rebinding >>= for restricted monads
by David Roundy 27 Feb '07

27 Feb '07

Hello fellow haskellers, I am wondering if anyone has an idea whether I'd run into trouble if I rebound >>= in order to provide a more restricted monad. My idea is to define a class: class WitnessMonad wm where (>>=) :: wm w w' a -> (a -> wm w' w'' b) -> wm w w'' b (>>) :: wm w w' a -> wm w' w'' b -> wm w w'' b return :: a -> wm w w' a fail :: String -> wm w w' a which obviously just adds a couple of phantom types indicating the monad state prior to and after each operation. I actually rather like this redefined monad, as it seems like it'd be useful in lots of places (e.g. a restricted IO monad that disallows use of a file handle after it's closed). It seems to me like this would be a pretty cool kind of monad. It'd allow us to encode typechecked "properties" in a monad, and there'd be very little restriction on how tricky those properties could be. And we'd get this all using the same do syntax we all love (and the new properties are by definition sequential, so a monad is precisely what we want, only at the type level). One trouble I see is how to move an ordinary monad into the WitnessMonad class. Of course, they differ in kind, so we need to do something, but I'm not sure what, and suspect that folks with experience using monad transformers will immediately see the answer. Of course, I want to be able to use both my fancy witnessed monad and IO in the same module, and I want to be able to use do notation for both of them. I suppose we could easily define data M m w w' c = M (m c) lift = M lower (M m) = m instance WitnessMonad (M m) where f >>= g = lift $ Prelude.(>>=) (lower f) (lower . g) ... but then we'd have to lift all our operations, so an ordinary IO function in a module that used my fancy rebound do notation would look like f :: IO Char f = lower $ do lift $ putStr "Hello world" lift $ getChar which seems rather heavy. Can anyone think of syntax-light way to allow my hypothesized rebound do-notation to also work with ordinary monads? -- David Roundy Department of Physics Oregon State University

10 17

FFI basics
by Yitzchak Gale 27 Feb '07

27 Feb '07

Hi, I would like to use FFI for the first time. Can someone give me a really, really simple complete example? I want to be able to take a simple C program and access a function from it in Haskell. A simple example of the other way around would be nice, too, but I don't happen to need that just now. I started reading the Addendum, but that looks like it would be a lot easier to read if I saw a simple complete example first. Everything I found on the wiki seems way beyond that - maybe I missed it. I am using GHC. I am not using Windows. Thanks, Yitz

10 16

Splitting Hairs Over Terminology
by P. R. Stanley 27 Feb '07

27 Feb '07

Hi folks in C and C++ world the humble comma is an operator. Is this also the case in Haskell or, is it classed as a function? In the wikibook they talk about consing new elements onto a list. Does this cons stand for anything meaningful in the English language? For example, is it short for construction or something similar? I'm assuming that the ":" function takes two arguments and returns a newly constructed list which is assigned to the variable holding/pointing to the old list. Cheers Paul

4 6

OO Design in Haskell Example (Draft)
by oleg＠pobox.com 27 Feb '07

27 Feb '07

Steve Downey wrote: > In the last OO design in Haskell thread (and probably in every one > preceeding it), it was suggested that having some examples might be a good > idea. > > Since most people with existing designs will have some familiarity with > Design Patterns, and those are typical building blocks for OO designs, it > occured to me that implementing some of them might be a useful > excersize. Have you looked at OOHaskell? http://homepages.cwi.nl/~ralf/OOHaskell/ http://darcs.haskell.org/OOHaskell/ With the exception of pure-functional objects and binary methods, I think we have considered almost every OO pattern/idiom we could find, including nominal/structural subtyping, co- and contra-variance, self-typing, etc. The DARCS repository contains the complete code for all of the examples and patterns. To clarify, the point of OOHaskell is to use Haskell as a tool, laboratory bench, for exploring various (thorny) OO issues.

2 1