- Haskell-Cafe - Haskell.org

assistance with using haskell to calculate the determinant
by Carter Tazio Schonwald 29 Mar '05

29 Mar '05

I've written a simple program to calculate determinants of matrices, and while it executes to completion it fails to yield a correct answer. (and yes, I know I'm using lists to represent matrices) I would greatly appreciate any assistance in correcting this algorithm --Carter Schonwald import Prelude first [] = [] first (a:b) = a nth::Int->[a]->a nth _ [] = error "list is too small" nth 1 (a:b) = a nth n (a:b) = nth (n-1) b takeAfter::Int->[a]->[a] takeAfter _ [] = error "list too small" takeAfter 0 a= a takeAfter 1 (a:b) = b takeAfter n (a:b) = takeAfter ( n-1) b type Matrix = [[Rational]] pad a = [x++x| x<- a] time2 [] _ = [] time2 _ [] = [] time2 (a:b) (c:d) = (a * c):(time2 b d) tupleProd (a,b) = a * b altSign a = [b* (-1^num) | b<-a, num <- [2..]] index::Int->Int->Matrix->Rational index a b c = nth b (nth a c) --- ath row, bth column slice::(Int,Int)->(Int,Int)->Matrix->Matrix slice (a,b) (c,d) list = let rowSliceFront = takeAfter (a-1) list --- a and c are rows, b and c are columns in let rowSlice = take (c-a+1) list in let columnSliceFront = map (takeAfter (b-1)) rowSlice in map (take (d-b+1)) columnSliceFront determinant::Matrix->Rational determinant a = det (pad a) (length a) -- only called from determinant det::Matrix->Int->Rational det a 1 = index 1 1 a det a size =let coeffs = altSign (first (take 1 a)) newsize = size - 1 leastToMax = newsize - 1 slices = [ slice (2, i) (size, i + leastToMax) a | i <- [2..(size+1)] ] in sum (time2 coeffs (map (\l-> det l newsize) (map (pad) slices)) )

3 2

Implementation of Non-Deterministic State Machine
by Pierre Barbier de Reuille 28 Mar '05

28 Mar '05

Hello, As an exercice to learn monadic programming, I programmed a Non-Deterministic State Machine. I extended the exercice to include the deterministic "cut" function, exactly as the one existing in Prolog. That means I defined an evalutaion frame, and if the machine evaluates a "cut", that means no other alternatives are to be evaluated in the inner-most frame. In Prolog, each predicates defines also a frame. To further extend my experiment, I wanted to implement my State Machine as a Monad Transformer. But there, even if it's working, I cannot anymore work with infinite choice points :( So I was looking for some existing implementation, to try understand what I did and even if it is possible. Thanks, Pierre -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

2 1

Re: [Haskell-cafe] assistance with using haskell to calculate the determinant
by Carter Tazio Schonwald 27 Mar '05

27 Mar '05

Thanks for the feeback regarding good programming style and pointing out the logical error (which I just realized this morning). --Carter Schonwald

1 0

Question on leazy evaluation
by Pierre Barbier de Reuille 26 Mar '05

26 Mar '05

Hello, I'm very new to Haskell and I'm learning it in my spare time (ie. just for fun ;) ). I already had a quick look through tutorials, some articles, the Wiki, ... My question is: is there some (simple?) rule/criteria to ensure leazy evaluation will be efficient ? Typically, I process a list and I know each list item can be processed as it come. But I'm not sure my code uses correctly this property ! Is there some way to be sure leazy evaluation is correctly used by my code ? And are there coding rules that will "ensure" correct leazy evaluation ? Thanks, Pierre -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

3 5

Re: [Haskell] URLs in haskell module namespace
by Dimitry Golubovsky 24 Mar '05

24 Mar '05

Dear list members, I'd like to share some sketchy ideas I have on the subject to address some of the issues raised. At 12:14 22/03/05 +0000, Malcolm Wallace wrote: >I cannot see any of the Haskell compilers ever implementing this idea >as presented. It would introduce an enormous raft of requirements >(networking client, database mapping, caching, etc) that do not belong >in a compiler - they belong in separate (preprocessing/packaging) >tools. Furthermore, these tools already exist, albeit they are young >and have a long maturation process still ahead of them. An external program acting as an "URI streamer" might be the solution. Such a program (identified via an environment variable or a compiler's command line option, just like Hugs external editor) would take an URI as its command line argument, and respond with a streamed contents of that URI on its stdout. Like e. g. curl/wget -O -. All the compiler has to do is popen() that program if an import statement contains an URI. Using curl/wget helps get around various issues with proxies/encryption/etc. as those programs are specifically designed for that. I do not believe this would result in significant overhead comparing to regular fopen() used by the compiler for opening source files. On a non-networked system, such a program would be a not so complicated shell script pretending it downloads from an URI, but reading from local disk (flash, any other kind of storage) instead. To address the problem of module/package URI changes over time, the following may be suggested. Either purl.org is used (and then it is responsibility of a package maintainer to keep its URL pointer valid). Or, some kind of a purl server may be set up somewhere (at haskell.org for example) which also supports mirroring. This means that for each package/module registered with this server, multiple locations are known (well, probably willing people might allocate their computer resources for that, at least I would not object as long as I have my own web server). The hypothetical purl server serves redirects as usual, but shifting randomly to another mirroring location for each new request for a module/package. So, if an attempt to retrieve a module/package fails, it may be repeated, and other mirror location will be tried. Mirrors will be synchronized behind the scenes. Will such a centralized purl server a bottleneck or a single point of failure? Probably not more than a centralized Hackage database (or is it planned to be distributed?) Also, some resolver might be part of the URI streamer which maps module names to URIs. For example, the Prelude will most likely be stored locally, but some other module will not. This means that the resolver consults the local package database (cabal), and its own cache, and either streams a local file or popens curl with some URI constructed specifically based on the desired module name. Once downloaded, a module may be cached with some TTL, so further recompilations do not result in curl involvement (until the TTL expires). PS This all is written in the assumption that Haskell source files are served. Binary distributions, of course would require different techniques. -- Dimitry Golubovsky Anywhere on the Web

1 0

QuickChecking classes
by Benjamin Pierce 24 Mar '05

24 Mar '05

Today I've been learning about the wonders of QuickCheck. :-) One (obvious?) question that is not addressed in at least the original paper is how one might use QC to automatically verify the algebraic laws that are often associated with type classes. E.g., could we add some QC properties as members of the Functor class and somehow arrange (probably by some combination of automation and idiom) that they would be checked every time somebody creates an instance of Functor? Regards, - Benjamin

3 2

Re: [Haskell] URLs in haskell module namespace
by Graham Klyne 23 Mar '05

23 Mar '05

Switching to -cafe... At 12:14 22/03/05 +0000, Malcolm Wallace wrote: > > import http://domain.org/package-1.0.cabal#Network.HTTP as HTTP > > import http://hage.org/package-2.1.cabal#Network.HTTP as HTTP2 > > --note use of HTTP fragment identifier for module name > >I cannot see any of the Haskell compilers ever implementing this idea >as presented. It would introduce an enormous raft of requirements >(networking client, database mapping, caching, etc) that do not belong >in a compiler - they belong in separate (preprocessing/packaging) >tools. Furthermore, these tools already exist, albeit they are young >and have a long maturation process still ahead of them. Well, I'd agree the networking stuff don't belong in the compiler. In the operating system, I'd suggest, as part of the I/O and file system. In the long, I believe the distinction between local and networked resources will fade away (other than for practical purposes, as today with specific networked file systems), and URIs are an effective and standardized way to identify all kinds of resources. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: [Haskell] Arrows GUI Library Based on GTK+
by ross＠soi.city.ac.uk 22 Mar '05

22 Mar '05

On Sat, Mar 19, 2005 at 12:17:46PM -0700, Kevin Atkinson wrote: > On Sat, 19 Mar 2005 ross(a)soi.city.ac.uk wrote: > > I would also have expected loopFG to have been defined using fixIO. > > Could you be more specific. Ie How? For the type definitions newtype FG' a b = FG' (Control -> a -> IO (Control, b)) newtype FG a b = FG (FGState -> IO (FG' a b, FGState)) newtype Container a b = Container (FG ([WidgetP], a) b) the usual instances would be (give or take a ~): instance Arrow FG' where arr f = FG' $ \ c x -> return (c, f x) FG' f >>> FG' g = FG' $ \ c x -> do (c', x') <- f c x g c' x' first (FG' f) = FG' $ \ c (x, y) -> do (c', x') <- f c x return (c', (x', y)) instance ArrowLoop FG' where loop (FG' f) = FG' $ \ c x -> do (c', x', _) <- mfix $ \ ~(_, _, y) -> do ~(c', ~(x', y')) <- f c (x, y) return (c', x', y') return (c', x') instance Arrow FG where arr f = FG $ \ s -> return (arr f, s) FG f >>> FG g = FG $ \ s -> do (f', s') <- f s (g', s'') <- g s return (f' >>> g', s'') first (FG f) = FG $ \ s -> do (f', s') <- f s return (first f', s') instance ArrowLoop FG where loop (FG f) = FG $ \ s -> do (f', s') <- f s return (loop f', s') instance Arrow Container where arr f = Container (arr (f . snd)) Container f >>> Container g = Container $ arr (\ (ws, a) -> (ws, (ws, a))) >>> second f >>> g first (Container f) = Container $ arr (\ ~(ws,~(x,y)) -> ((ws,x),y)) >>> first f instance ArrowLoop Container where loop (Container f) = Container $ loop (arr (\ ((ws,x),y) -> (ws,(x,y))) >>> f) The FG instances seem to match yours, except for ArrowLoop.

2 4

Re: [Haskell-cafe] Linux device drivers
by Keean Schupke 22 Mar '05

22 Mar '05

I don't think I said anything controversial. I guess I was just over-simplifying things by only considering PC IDE hardware - but then again that must get you running on 90% of the systems people are likely to have lying around to play with a developmental OS on. On the other hand the average network driver seems to be about 2,000 lines of code, whereas if you add all the parts of the generic ide driver together you get about 20,000 lines of code. I guess that answers my question - storage is an order of magnitude harder than networking, even before including SCSI. Regards, Keean. Simon Marlow wrote: >Keean, you should be aware that Lennart is something of a device driver >guru. He knows what he's talking about :-) Go grep for Augustsson in >the NetBSD kernel sometime. > >Cheers, > Simon > >

2 1

Re: Arrows GUI Library Based on GTK+
by Kevin Atkinson 22 Mar '05

22 Mar '05

[From haskell@ to haskell-cafe@] On Sat, 19 Mar 2005 ross(a)soi.city.ac.uk wrote: > Some more minor suggestions: > - I'd suggest making Container a newtype, so it could have an Arrow > instance (it would be a reader arrow). Then hbox and vbox could be > used as arrow operators/combinators. What will that give me? Could you give me an example of how I would use it in such a manner? -- http://kevin.atkinson.dhs.org

1 0