- Haskell-Cafe - Haskell.org

Re: Implementing forward refs in monadic assembler and interprete r
by Mike Gunter 29 Nov '02

29 Nov '02

Thank to all who replied. After giving up on continuations (which make everything but forward branches seductively easy), I settled on something with the following interface: > class MonadGoto lbl gm | gm -> lbl where > liftG :: Monad m => m () -> gm m () > label :: Monad m => gm m lbl > gotoIf :: Monad m => m Bool -> lbl -> gm m () Note that, unlike a monad transformer, only ()-producing computations can be embedded. This limitation reflects the problem of def-use across basic-block boundaries. Of course, computations in the embedded monad can be done there, then lifted, e.g.: > ;top <- label > ; ... > ; liftG (do v <- m1 > ; ... > ; m2 v > ; ...) > ; brPositive r3 top > ; ... I've implemented MonadGoto as > newtype GotoT m a = GotoT { unGotoT :: WriterT [GotoLbldT m ()] LblSupply a } > > data GotoLbldT m a = Label !Lbl > | GotoIf (m Bool) !Lbl > | Inner (m a) > > wrL = GotoT . tell . (:[]) > instance MonadGoto Lbl GotoT where > liftG = wrL . Inner > label = GotoT $ lift fromSupply >>= \l -> tell [Label l] >> return l > gotoIf p l = wrL $ GotoIf p l where GotoLbldT gets converted to > data GotoLbldRunT m a = ThenLabel { before :: m (), next :: GotoLbldRunT m a, labelLbl :: !Lbl } > | ThenGotoIf { before :: m (), next :: GotoLbldRunT m a > , gotoPred :: m Bool, gotoLbl :: !Lbl } > | Tail (m a) which can then be run > type JumpArray m v = [(Lbl, m v)] > runGM :: Monad m => JumpArray m v -> GotoLbldRunT m v -> (JumpArray m v, m v) . My Verilog has delayed branches (because that's the easy thing to do.) So, I implemented a DelayedGotoT which provides for delayed branches by shuffling the "GotoLbldT"s and using a StateT to save the result of the gotoPred evaluation. "Erkok, Levent" <levent.erkok(a)intel.com> writes: > You need a fairly recent version of Hugs to run this > example, November 2002 release would do (try with -98). For ghc, you need > the CVS version, or wait till the next release. As far as I know, no other > implementation supports mdo, nor there are any plans for it. For the moment I've chosen to do the mdo desugaring manually instead of moving to the CVS ghc (or exclusively using Hugs.) Will mdo be in the next release? (That's 5.04.2, I think -- though I've recently been confused about GHC releases.) The relevant revision to Lex.lhs is pretty recent and doesn't seem to be on ghc-5-04-branch. thanks, mike

1 0

Merhaba;
by www.erotikmagaza.com 26 Nov '02

26 Nov '02

Sevgili internet kullanicilari; Bu mail sizlere rahatsizlik verdiyse �ok �ok �z�r diliyoruz. Biz Erotik �r�n satan bir firmayiz. Avrupada insanlarin erotik marketlerden satin alarak gerek ihtiya�larinda gerekse hediyelik esya olarak g�venle kullandiklari erotik �r�nleri ithal ederek �lkemizde m�sterilerimizin begenisine sunuyoruz. Eger ilginizi �ekerse sizleride Web sitemizi gezmeye davet ediyoruz. Saygilarimizla http://www.erotikmagaza.com

1 0

Random Color
by Mike T. Machenry 21 Nov '02

21 Nov '02

I am trying to construct an infinate list of pairs of random colors. I am hung up on getting a random color. I have: data Color = Blue | Red | Green deriving (Eq, Ord, Show) am I supposed to instantiate a Random class instance from color? I am not sure exactly how the random number generator works. Is this the best way to go about it? Should I instead get a random Integer index of an array of Colors? thanks, -mike

3 5

Re: Sets
by Christopher Milton 19 Nov '02

19 Nov '02

This might be of some help, circa Haskell 1.2, SetMap.hs - sets and maps in Haskell Author: Nick North ftp://ftp.cs.chalmers.se/pub/haskell/library/SetMap.hs Chris ===== Christopher Milton cmiltonperl(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com

1 0

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