- Haskell-Cafe - Haskell.org

Re: functions not in type classes
by Yoann Padioleau 02 Feb '02

02 Feb '02

"Cagdas Ozgenc" <co19(a)cornell.edu> writes: > Greetings. > > Why does Haskell let you write functions that are not a part of type class? > For example instead of the goal of type class is to allow overloading of function, so for example id x = x is not subject to overloading => no use to put it in a type class. > > elem :: Eq a => a -> [a] -> Bool > map :: (a -> b) -> [a] -> [b] > > class Container a where > elem :: Eq b => b -> a b -> Bool > map :: (b -> c) -> a b -> a c > > would define methods that can work on all containers, and create a > discipline to write more reusable and generic functions. yes, that's right that map and elem could be put in a type class, but that's hard and require more advanced feature of haskell (here you use constructor class but you need more : multi-parameter class, ....) see http://www.cse.ogi.edu/~mpj/fds.html. > > Thanks > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Yoann Padioleau, INSA de Rennes, France, Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**

6 6

monad thinking process
by Cagdas Ozgenc 25 Jan '02

25 Jan '02

Greetings. I have very little experience with monads. However my first impression is that there is too much thinking process involved in programming with monads, and it is very time consuming, at least for a beginner like myself. I don't know how productivity changes once you get used to programming with them. Also, I have serious concerns about the maintenance of programs written in monadic style. Since there is too much plannning overhead, it doesn't seem suitable for evolutionary software development process. What do monad experts think? What do you think of code readability? How easy is it to prove that programs written with monads are correct? How does changing one function affect other functions, in terms of maintenance? Thanks

4 3

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 24 Jan '02

24 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