- Haskell-Cafe - Haskell.org

Re: Monad composition
by John Hughes 25 Jan '02

25 Jan '02

Andre W B Furtado wrote: >Well, it's also possible to interchange data between these two monads by: > >unsafeIOToST :: IO a -> ST s a >stToIO :: ST s a -> IO a > >Can anyone tell the possible problems related to >unsafeIOToST? >^^^^^^ Probably in the same manner as with unsafePerformIO: it can break referential transparency. Indeed, unsafePerformIO m = runST (unsafeIOToST m) so they're just as unsafe as each other. John Hughes

1 0

Dynamic linking of Haskell modules?
by senganb＠ia.nsc.com 25 Jan '02

25 Jan '02

I'd like to be able to dynamically load Haskell code from a "plugin" binary file into a Haskell application, just as I can dynamically load .so files into a C application. Since ghci does this, I thought I could copy its implementation but after looking into it, it's very complicated. I notice that OCaml can do this (http://algol.prosalg.no/~malc/scaml/) The only simple solution I can think of is to use FFI to export the objects in the .so file as following the C interface, and then importing them into the main Haskell application as "C functions", but the extra marshalling is ugly. Has anyone solved this problem? Are there any plans to support this in the future in ghc or a third party library? Sengan

1 0

Re: Monad composition
by Tom Bevan 24 Jan '02

24 Jan '02

Andre, I can't work out how it should be done. The way I see it, the StateIO monad should have four functions associated with it. 1/ update - a function to update the state 2/ retrieve - a function to retrieve the state from the monad These two are inherited from the standard State monad 3/ input - make a character from stndIn available to the state transformation functions 4/ output - send the state of the monad after a certain set of transformations to stndOut I've managed to write functions 1-3 but not 4. Here's my work so far.I'm not really sure if this is on the right track. Tom On Thu, 2002-01-24 at 14:32, Andre W B Furtado wrote: > Hi, I have the same problem. Did anyone answered your question? > > Thanks, > -- Andre > > ----- Original Message ----- > From: Tom Bevan <tom(a)regex.com.au> > To: Haskell Cafe List <haskell-cafe(a)haskell.org> > Sent: Wednesday, January 23, 2002 4:29 AM > Subject: Monad composition > > > > > > Hi all, > > > > I'm writing a programme which requires IO actions to be interleaved with > > operations on a State monad. From what I can work out, this means that > > the IO Monad and the StateTransformation monad need to be composed into > > a single highr order monad. > > Does anyone have any references or pointers on how this should be done? > > > > > > Tom > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > >

3 2

Monad composition
by Tom Bevan 24 Jan '02

24 Jan '02

Hi all, I'm writing a programme which requires IO actions to be interleaved with operations on a State monad. From what I can work out, this means that the IO Monad and the StateTransformation monad need to be composed into a single highr order monad. Does anyone have any references or pointers on how this should be done? Tom

2 1

Re: performance of monads
by John Hughes 24 Jan '02

24 Jan '02

I've felt need to use State monads in two distinct situations: ... And I've seen two distict aproaches. Using a State monad like one provided with GHC (1), or a state monad like the one defined in the paper "Moands for the Working Haskell Programmer" (2). In (1), I can see how I can take advantage of the monad and make updates in place using referencies. But then you'll have to either: - pass the referencies as a parameter to the functions where you use them (needless too say that this defeats the (my) main purpose of using a state monad which is in case A, keep track of data with minimal signature change ) You can do this conveniently using implicit parameters bound to your references: that way you don't have to add parameters to all your function definitions just to pass in a reference. (The types do change, though). I would probably use one implicit parameter bound to a record of references. ... Another state issue, sometimes I have some values that I want to keep constant through the whole algorithm. Example: (some very simple NNs for instance) - learning rate - activation function - maximum number of steps - minimum error required So I'll just declare them as 'constants'. But what if I decide I want the user to be able to chose? Now I got two options: - pass them around as values to all the functions - And signatures get HUGE - just pass them to a higher level function that will encapsulate the functions that use them... which is ugly and complicates everything because you can't test the lower level functions in the interpreter. Am I missing something here or is this really the best you can do? Implicit parameters solve this too. Read http://www.cse.ogi.edu/~mbs/pub/implicit_parameters/ I've written a short article on global variables in Haskell, which explains this particular application. http://www.md.chalmers.se/~rjmh/Globals.ps John Hughes

1 0

Re: Monad composition
by John Hughes 24 Jan '02

24 Jan '02

The easiest way to combine State and IO is using a monad transformer. There are some lecture notes which you might find useful at http://www.md.chalmers.se/~rjmh/Combinators/Monads/index.htm which refer to a library module http://www.md.chalmers.se/~rjmh/Combinators/MonadTransformers.hs Using this library you just build the type type StateIO s a = State s IO a which is a monad with operations readState, writeState, and lift :: IO a -> StateIO s a John

1 0

more parsing paper
by David Feuer 24 Jan '02

24 Jan '02

The paper I am reading uses the following in an instance declaration for parsers: p >>= f = Parser (\cs -> concat [parse (f a) cs' | (a,cs') <- parse p cs]) Isn't this the same as p >>= f = Parser (\cs -> [(a',cs'') | (a,cs') <- parse p cs, (a',cs'') <- parse (f a) cs']) ? If so, any guesses why they chose the more obscure form?

2 1

Re: monad parsing article....
by David Feuer 23 Jan '02

23 Jan '02

> Also, why were monad comprehensions > removed from Haskell? Was it for efficiency? > > No, it was to help beginners. When list comprehensions, and other list > operators like ++ and filter were overloaded, then errors involving the > class > system became much more common, and in particular cropped up for simple > list I now understand the problem. However, I'm not sure that the solution is the right one. I think that it makes more sense to change the way that Haskell deals with the Prelude. I think the way this issue is handled in DrScheme (www.plt-scheme.org) is pretty reasonable. There are a number of different "language levels" available. In the beginner's mode, complex operations are prohibited, and (I think) some operations have restricted semantics. It would seem to make sense for Haskell implementations to provide something similar: a prelude customized for beginners would have no overloaded functions, a prelude for experts would have many of them. Special syntactic forms like comprehensions and do notation can be specialized to the language mode. Examples for beginner's mode: monad comprehensions become list comprehensions do notation is restricted to IO numbers are not overloaded: 4,5,6::Integer and 4.0,5.0,6.0::Float This kind of multi-level system would allow beginner's an easy introduction without forcing people who know what they're doing to remember bizarre names for simple overloaded operators. David Feuer

1 0

Re: [Fwd: Re: type class VS struct/functor]
by John Hughes 23 Jan '02

23 Jan '02

The advantage of functors shows up when you need to have multiple implementations of a module for a type. For instance, suppose you want to implement a set, and you write the functors (OCaml below): ... Now, suppose you want two kinds of sets of string, one of which is case-sensitive and one of which is not. You can easily do this with functors like so module SensitiveCase = struct type t = string let eq s s' = (s = s') end module InsensitiveCase = struct type t = string let eq s s' = (String.lowercase s) = (String.lowercase s') end module SensitiveSet = Set(SensitiveCase) module InsensitiveSet = Set(InsensitiveCase) Each of these Set types takes a string, but the membership test is different. This is an annoying case in Haskell, because you can make a String a member of the Eq typeclass in only one way. Of course, you can always define newtype CaseInsensitiveString = CaseInsensitive String whereupon you can define an Eq instance that ignores case. Maybe this isn't common Haskell style, but it does have many advantages. In particular, the type-checker now checks that you don't pass a case sensitive string where an insensitive one is expected, or vice versa, and this should help catch bugs. I've begun to use this style more, particularly when using QuickCheck. There I define a new type when I want a different distribution of test data from the default. I've found it's error-prone to specify which distribution to use explicitly; much better to let the type-checker figure it out. John

1 0

Re: monad parsing article....
by John Hughes 23 Jan '02

23 Jan '02

Also, why were monad comprehensions removed from Haskell? Was it for efficiency? No, it was to help beginners. When list comprehensions, and other list operators like ++ and filter were overloaded, then errors involving the class system became much more common, and in particular cropped up for simple list processing functions. These are exactly the kinds of functions that beginning Haskell programmers write, and error messages involving class Monad are unlikely to help them! We decided consciously to keep the types of list functions simple, so that learners aren't forced to face the complexity of the class system from the word go. Overloading comprehensions is nice for experts, but even experts were beginners once! It's important that learning Haskell is not too difficult, otherwise there will eventually be no experts. Hence the decision. John Hughes

1 0