November 2005 - Haskell-Cafe

matrix computations based on the GSL
by Alberto Ruiz 21 Apr '06

21 Apr '06

Hello all! This is my first message to the list. In my work I often need linear algebra algorithms and other numeric computations. An option is using scientific computing systems like Matlab, Mathematica, Maple, etc. In Haskell there are several modules and bindings to matrix libraries; many of them are excellent. But I think that Haskell would be even more attractive if the basic matrix computations (what we find, for example, in the GNU Octave Quick Reference) were easily available in a standard library. We have all we need: an interactive environment, excellent graphics (HOpenGL), FFI and ForeignPtr with automatic garbage collection, QuickCheck, etc. Computations can be implemented by the GSL (GNU Scientific Library), a well designed numerical library written in C. Well... I know that I am trying to reinvent the wheel: I am working on a user friendly functional interface to matrix computations based on the GSL. I think that many numeric problems that can be solved using Octave or a similar system can be also solved more elegantly using Haskell. The library is very preliminary and incomplete but some simple problems can already be solved. The sources, haddock documentation and the draft of a tutorial can be found at: http://dis.um.es/~alberto/hmatrix/matrix.html I am not a Haskell expert, I only use the most basic programming techniques, so any suggestion will be greatly appreciated... Alberto

22 97

RE: [Haskell-cafe] generics question, logical variables
by Ralf Lammel 03 Apr '06

03 Apr '06

Frederik, > As for your code example, it looks very interesting, but are you > saying that this could turn into an extension of the Data.Generics > library, or that this is something I could be implementing in terms of > what's already there? The posted code works with GHC 6.4 (SYB2) intentionally and actually. I have attached another attempt (again GHC 6.4, based on SYB2) which might be more useful for your purposes, and it may be useful in general, in fact. What I defined this time is a "certainty-improving" function: idify :: (Typeable1 f, Monad m, Data (a f), Data (a Id)) => (forall a. f a -> m a) -> a f -> m (a Id) That is, the function "idify get" takes a value whose type is parameterized in a type constructor f (such as Maybe or IORef), and the function attempts to establish Id instead of f on the basis of the function argument "get". > What is the 'a' parameter for in "force"? > > force :: ( Data (t Maybe a) > , Data (t Id a) > , Term t Maybe a > , Term t Id a > ) => t Maybe a -> t Id a The previous attempt was a more parameterized blow than required in your case. (I was guessing about what "typed logical variables" could mean. I was assuming that you would need some extra layer of embedding types on top of the Haskell term types. Looking at your code, this was not the case.) > For the part which I asked for help with, to get around my trouble > with generics, I defined a class GenFunctor and an example instance. > The intent is that generics should be able to provide this > functionality automatically later on, but you can see what the > functionality is. Let's look at the type of your GenFunctor: class GenFunctor f where gfmapM :: (Monad m, FunctorM b) => (forall x . a x -> m (b x)) -> f a -> m (f b) This type can be seen as a more relaxed version of the idify operation above. That is, idify fixes GenFunctor's b to Id. The particular encoding of idify (attached) takes advantage of this restriction. I wonder whether I should bother. (Exercise for reader :-)) > However, I am stuck on something else, the program doesn't typecheck > because of use of another function I defined, 'cast1'. Maybe you can > take a look. I had thought that I would be able to write a generic > 'unify' but I get the error: > > GenLogVar.hs:82:19: > Ambiguous type variable `a' in the constraint: > `Data a' arising from use of `cast1' at GenLogVar.hs:82:19-23 > Probable fix: add a type signature that fixes these type variable(s) > > This is because I need to do something special when I encounter a > "Var" variable in unification, but the compiler seems to not like the > fact that the type argument of the Var data type is not known. Please try to avoid new cast operations at all costs. :-) Your code can be arranged as follows: (i) Use extQ1 to dispatch to a special case for "Var x" for the first argument. (ii) In this special case, use again ext1Q to dispatch to a special case for "Var y" for the second argument. (iii) At this point, *cast* the variable value of *one* variable to the type of the other. So the problem with your code, as it stands, is that the target type of cast is ambiguous because you cast *both* arguments. The insight is to make the cast asymmetric. Then, not even polymorphism is in our way. Interesting stuff! Ralf

2 2

c2hs seems to ignore the types I give it when generating foreign import declarations
by Cale Gibbard 18 Dec '05

18 Dec '05

Hello, I've just started writing bindings to the Enlightenment Foundation Libraries, using c2hs. I've run into the following problem with the types in the foreign import declarations generated. In Imlib2.h, there is a function prototype: int imlib_get_visual_depth(Display * display, Visual * visual); In Imlib.chs, I have (among other things) import qualified Graphics.X11.Xlib.Types as Xlib -- ... {# fun imlib_get_visual_depth as getVisualDepth { id `Xlib.Display', id `Xlib.Visual' } -> `Int' #} I run: c2hs -k /usr/local/include/Imlib2.h Imlib.chs and in the resulting Imlib.hs, I get: --- this part is correct: getVisualDepth :: Xlib.Display -> Xlib.Visual -> IO (Int) getVisualDepth a1 a2 = let {a1' = id a1} in let {a2' = id a2} in getVisualDepth'_ a1' a2' >>= \res -> let {res' = cIntConv res} in return (res') --- this part is not: foreign import ccall safe "Imlib.h imlib_get_visual_depth" getVisualDepth'_ :: ((Ptr ()) -> ((Ptr ()) -> (IO CInt))) Why did it choose the type Ptr (), when I gave the type Xlib.Display? I could do an additional cast, but it will get tedious, as I have a lot of functions to import, and there shouldn't be any need for it anyway. As this is, it doesn't typecheck at all. If by hand, I change it to read: foreign import ccall safe "Imlib.h imlib_get_visual_depth" getVisualDepth'_ :: Xlib.Display -> Xlib.Visual -> IO CInt (which is what I expected it to produce in the first place) then it works as expected. Am I making a grievous error, or is this a bug/lack of a feature? - Cale

3 5

STM commit hooks
by Einar Karttunen 12 Dec '05

12 Dec '05

Hello I have been playing with STM and want to log transactions to disk. Defining a logging function like: log h act = unsafeIOToSTM $ hPrint h act works most the time. Aborts can be handled with: abort h = log h Abort >> retry atomic' h act = atomically (act `orElse` abort h) But is it possible to handle a commit? commit h = unsafeIOToSTM (hPrint h Commit >> hSync h) atomically2 h act = atomically ((act >> commit h) `orElse` abort h) This won't work because the transaction is validated and maybe aborted after the commit is logged to disk. Another alternative would be: atomically3 h act = atomically (act `orElse` abort h) >> atomically (commit h) But this does not work either. Given Trx1 and Trx2, the following may occur: 1) Trx1 commits <thread switch> 2) Trx2 commits (and depends on Trx1) 3) Trx2 commit is logged to disk <system crash> This means that the log would be inconsistent. Is there a way to implement the commit that works? - Einar Karttunen

2 1

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 12 Dec '05

12 Dec '05

threadDelay is IO-only; there's no way to use threadDelay in an STM transaction. For example, if you want to wait for a TVar to go from Nothing to Just x with a timeout, you could do this: readOrTimeout :: TVar (Maybe a) -> Int -> STM (Maybe a) readOrTimeout t secs = do timeout <- registerTimeout secs let check_timeout = do b <- readTVar timeout if b then return Nothing else retry check_t = do m <- readTVar t case m of Nothing -> retry Just x -> return x atomically $ check_timeout `orElse` check_t Cheers, Simon On 29 November 2005 10:11, Joel Reymont wrote: > Simon, > > How is this easier than just calling threadDelay? > > Ideally, I would be looking for something like reading from a TVar > with a timeout. So that you either get a Nothing (timeout) or the > value from the TVar. Can I implement it using the GHC timeout thread? > > Thanks, Joel > > On Nov 29, 2005, at 9:20 AM, Simon Marlow wrote: > >> Interestingly, GHC already has a timeout thread - the I/O manager >> thread handles threadDelay too. It wouldn't be too hard to adapt it >> to do STM timeouts too, with a function like >> >> registerTimeout :: Int -> STM (TVar Bool) >> >> and you wait for your timeout by waiting for the TVar to contain >> True.

3 4

Detecting Cycles in Datastructures
by Tom Hawkins 11 Dec '05

11 Dec '05

In a pure language, is it possible to detect cycles in recursive data structures? For example, is it possible to determine that "cyclic" has a loop? ... data Expr = Constant Int | Addition Expr Expr cyclic :: Expr cyclic = Addition (Constant 1) cyclic Or phased differently, is it possible to make "Expr" an instance of "Eq" such that cyclic == cyclic is smart enough to avoid a recursive decent? -Tom

14 32

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 04 Dec '05

04 Dec '05

On 29 November 2005 12:08, Tomasz Zielonka wrote: > On Tue, Nov 29, 2005 at 12:00:03PM -0000, Simon Marlow wrote: >> threadDelay is IO-only; there's no way to use threadDelay in an STM >> transaction. For example, if you want to wait for a TVar to go from >> Nothing to Just x with a timeout, you could do this: >> >> readOrTimeout :: TVar (Maybe a) -> Int -> STM (Maybe a) >> readOrTimeout t secs = do timeout <- registerTimeout secs >> let check_timeout = do >> b <- readTVar timeout >> if b then return Nothing else retry >> check_t = do >> m <- readTVar t >> case m of >> Nothing -> retry >> Just x -> return x >> atomically $ check_timeout `orElse` check_t > > Wouldn't it be > readOrTimeout :: TVar (Maybe a) -> Int -> IO (Maybe a) > ^^ > ? Sorry, yes. > Alternatively, it would be nice to have a new STM primitive: > > wailUntil :: ClockTime -> STM () > > so you would wait until some time-point passes, not for a number of > time-units (waiting for a number of time-units wouldn't work because > of retries). I think it could be efficiently implemented, wouldn't it? Interesting. You could use that do wait for idle time, for example: atomically $ do t <- readTVar last_mouse_click waitUntil (t+1000) ... so this transaction only completes when some idle time has passed since the last mouse click. But you could also implement this using registerTimeout, albeit with some more code and an extra thread, and waitUntil requires an implementation in the runtime which is not entirely trivial. Cheers, Simon

3 4

wxHaskell and do statements
by mempko 02 Dec '05

02 Dec '05

Hello, I have a program that just will not compile and I cannot figure out why. I am starting out with wxHaskell but keep getting certain errors. Here is the source: ------------------------- module Main where import Graphics.UI.WX main :: IO () main = start hello hello :: IO () hello = do f <- frame [text := "Super Window"] lab <- staticText f [text:= "Hello"] quit <- button f [text:= "Quit", on command := close f] touch <- button f [text:= "Touch Me", on command := set quit [text:= "Yay"]] set f [layout:= floatCenter (widget lab) $ floatCenter (widget touch) $ floatCenter (widget quit)] ------------------ I keep the following error **** Compiling Main ( test1.hs, test1.o ) test1.hs:9:11: The last statement in a 'do' construct must be an expression ***** I looked at source code for the do statement and can not understand why I get that error.

5 5

RE: [Haskell-cafe] STM, orElse and timed read from a channel
by Simon Marlow 01 Dec '05

01 Dec '05

On 29 November 2005 13:01, Joel Reymont wrote: > Would you share your implementation for us advanced users? It's a modification of GHC.Conc, so I can't supply a standalone implementation I'm afraid. > I could use Tomasz's workaround in the meantime but isn't GHC 6.6 > supposed to be out in a year? Rather less than a year, I hope. Cheers, Simon

2 1

:t main
by Scherrer, Chad 01 Dec '05

01 Dec '05

I've been reading some of the articles about comonads, and I thought the idea of giving main the type OI () -> () was pretty interesting. So I was wondering, would it be possible to allow the type of main to be inferred? It seems like IO () OI () -> () OI () -> IO () all make sense (at least I think they do). One particularly nice side effect of this (pardon the pun) is that a good number of useful programs can be written as getContentsW :: OI () -> a doSomeStuff :: (Show b) => a -> b print :: (Show b) => b -> IO () main = print . doSomeStuff . getContentsW so much less understanding about monads et al is required to do some basic stuff. I think it would be much easier in this case to make the transition to Haskell. Also, has anyone given any thought to syntactic sugar for comonads? Since arrows and monads share the (<-) symbol, it seems like a nice unification could be possible... Maybe (-<) alone could be used similarly? Thanks, Chad Scherrer

2 1