November 2002 - Haskell-Cafe

newbie question re linear algebra in Haskell
by Jeff Austin 19 Nov '02

19 Nov '02

I'm a complete newcomer to Haskell, having learned about only recently. I'm intrigued by the possibility of in using it for numerical applications, specifically linear algebra. I understand that (at least in its present state) Haskell 98 isn't competitive with imperative languages when it comes to primitive matrix-vector operations, which often rely on destructive updating. It strikes me that one approach that takes advantage of the strengths of both paradigms would be create an imperative subsystem to handle primitive operations, then create a functional matrix algebra layer on top of it. Based on my very limited understanding of Haskell, I envision a linear algebra library which would work something like this: (1) Create a wrapper for the standard BLAS library. Since an optimized BLAS is available for various architectures with the same interface, this would provide a way of optimizing the library for a particular architecture. (2) Encapsulate this (using a monad?) in a way that provides safe access to the imperative routines from Haskell. (3) Using this as a foundation, define a matrix algebra in a "smart" way which avoids redundant evaluations. For instance, if A is an arbitrary invertible matrix, we know that A - A = 0 A + 0 = A A * Indentity = A A * inverse A = Identity so if we write an expression like "X = A * inverse A + B - B" we should expect our library to compute the correct result, "Identity" without actually performing any inversion, multiplication or elementwise matrix addition. (4) Create a Haskell module which exposes a pure functional interface, hiding the imperative subsystem from the user. My questions are: (a) Is this idea sound? (b) Has someone already done this? (c) Is there a better way of doing efficient linear algebra in Haskell? I would greatly appreciate any advice in this regard. --Jeff Austin

4 3

Network objects (was RE: deriving (...))
by Garner, Robin 18 Nov '02

18 Nov '02

> BTW, those typed returns on sockets that Shawn mentioned sounded > interesting. IIRC Modula-3 also had some approach to worrying about data > exchange between older and newer versions of the same program. Modula-3 (actually the Network Objects library) used subtyping to handle this. Successive versions of an interface are declared as subtypes of the previous version, and the type system will resolve a network object binding to the appropriate version. Hard to see how this could be done in a purely functional setting. robin

2 1

RE: Bug? [was: Implicit params]
by Simon Peyton-Jones 18 Nov '02

18 Nov '02

Now fixed in the HEAD, and will be in 5.04.2 Thanks for pointing it out. Simon | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 14 November 2002 21:10 | To: Iavor S. Diatchki | Cc: Haskell Cafe; glasgow-haskell-users(a)haskell.org | Subject: Bug? [was: Implicit params] | | On Thursday 14 November 2002 18:47, Iavor S. Diatchki wrote: | > hello, | > | > > Well, actually you must be right since the pure field defines a pure | > > (projection) function... Hmmm, ok, can someone explain this to me, | > > | > > data E s = E{ | > > refi :: STRef s Int, | > > refc :: STRef s Char, | > > m :: Int | > > } | > > | > > -- this is fine, obviously... | > > pure :: E s -> Int | > > pure e = m e | > > | > > -- but this is not... | > > pure2 :: (?e :: E s) => Int | > > pure2 = m (?e) | > > | > > Why exactly isn't this allowed? What is the workaround? | > > Error msg: | > > ------------------------------------------------------------------------ | > > Ambiguous constraint `?e :: E s' | > > At least one of the forall'd type variables mentioned by the | > > constraint | > > must be reachable from the type after the '=>' | > > In the type: forall s. (?e :: E s) => Int | > > While checking the type signature for `pure2' | > > Failed, modules loaded: none. | > > ------------------------------------------------------------------------ - | > >- | > | > this seems like a bug in GHC. Hugs is happy with it. The "s" in the | > pure2 signature is not ambiguous because it is determined when you give | > the value of the implicit parameter. in fact the way i think about | > implicit parameters is simply as a nice notation for computations in the | > environment monad, so in my mind the above two definitions are pretty | > much the same. | | Thanks Iavor! | GHC people, can you confirm this, Is it a bug? I'm using Ghc 5.0.4 SuSE rpms. | Is there a workaround? | | Thanks, | J.A. | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

GTKHS
by Martin Huschenbett 18 Nov '02

18 Nov '02

Hi! Is there meanwhile any tutorial on GTK-HS? Huschi

2 1

storing to a file
by Johan Steunenberg 18 Nov '02

18 Nov '02

Hello, I am new to haskell, and to functional programming, and wondering how to store a Double, or any non-char, to a file. Do I have to make a char array of the double and store that? Or is it preferred to use the show and read functions? Thanks in advance, johan steunenberg

8 11

Formatting function types
by Lauri Alanko 17 Nov '02

17 Nov '02

Just a silly thing that's been nagging me. a very common way (at least in the base libraries) of formatting function types seems to be this: hPutBuf :: Handle -- handle to write to -> Ptr a -- address of buffer -> Int -- number of bytes of data in buffer -> IO () I remember when I first started learning Haskell, and these many-arrowed functions seemed very strange to me: "Okay, we give it a handle, and get a pointer, and, um, from this we get an int, and from this an action? Er?" The problem here is that the first parameter has a distinguished look while the other parameters and the return value all look the same. I think that a naive reader is inclined to assume that line breaks are situated at major structural boundaries. Consider two different interpretations of the structure of the type term: (((Handle (Handle -> Ptr a) ->(Ptr a -> Int) ->(Int -> IO ()) -> IO ()))) Which looks more natural? The point of this rant is just this: the aforementioned multi-line formatting style should only be used for left-associative infix operators. For right-associative ones (such as the function arrow), the One True Way is this: Handle -> Ptr a -> Int -> IO () Nuff said. Lauri Alanko la(a)iki.fi

1 0

RE: Bug? [was: Implicit params]
by Simon Peyton-Jones 15 Nov '02

15 Nov '02

| > this seems like a bug in GHC. Hugs is happy with it. The "s" in the | > pure2 signature is not ambiguous because it is determined when you give | > the value of the implicit parameter. in fact the way i think about | > implicit parameters is simply as a nice notation for computations in the | > environment monad, so in my mind the above two definitions are pretty | > much the same. | | Thanks Iavor! | GHC people, can you confirm this, Is it a bug? I'm using Ghc 5.0.4 SuSE rpms. | Is there a workaround? Interesting. I hadn't thought of that. Yes, I think you can consider it a bug, or at least the lack of a feature. I'll fix it next week S

1 0

RE: deriving (was Re: storing to a file)
by Simon Peyton-Jones 15 Nov '02

15 Nov '02

| I was thinking that it might be nice to be able to write Haskell to add, | say, a "deriving XML" or "deriving ASN1" feature whose instances provide | methods to convert between Haskell data structures and those formats, | instead of having to hack the compiler to achieve such automated method | writing. When Template Haskell is out, you'll be able to do just that, I think. Simon

1 0

RE: Time library underspecified
by Simon Peyton-Jones 15 Nov '02

15 Nov '02

This is a community thing! They aren't our libraries, they're yours. Haddockising them is something anyone can do -- it doesn't have to be GHC head office (we are always way behind on our to-do list). Please help! Simon | -----Original Message----- | From: Mark Carroll [mailto:mark@chaos.x-philes.com] | Sent: 15 November 2002 13:54 | To: haskell-cafe(a)haskell.org | Subject: Re: Time library underspecified | | On Fri, 15 Nov 2002, George Russell wrote: | | > The TimeExts library probably does most of what you want. I really ought to | Haddockify | > the comments some time . . . | | Heh - this reminds me that one problem I often have with the GHC online | library Haddock docs is that many library function definitions are | uncommented and I have to try them out in ghci to figure out exactly what | they do. (-: | | --- Mark | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: Time library underspecified
by Mark Carroll 15 Nov '02

15 Nov '02

On Fri, 15 Nov 2002, George Russell wrote: > The TimeExts library probably does most of what you want. I really ought to Haddockify > the comments some time . . . Heh - this reminds me that one problem I often have with the GHC online library Haddock docs is that many library function definitions are uncommented and I have to try them out in ghci to figure out exactly what they do. (-: --- Mark

1 0