October 2006 - Haskell-Cafe

Re: 6.4 -> 6.6, scoped type variables
by oleg＠pobox.com 18 Oct '06

18 Oct '06

I too miss the old way of handling local type variables. Previously, local type annotations worked a lot like an additional constraint, with type variables denoting some type. The same type variable denoted the same type. Here's how it works in OCaml, for example: # let pair x y = (x,y);; val pair : 'a -> 'b -> 'a * 'b = <fun> # let pair1 (x:'a) (y:'a) = (x,y);; val pair1 : 'a -> 'a -> 'a * 'a = <fun> # let pair2 x y = ((x:'a),(y:'a));; val pair2 : 'a -> 'a -> 'a * 'a = <fun> # let pair3 x (y:int) = ((x:'a),(y:'a));; val pair3 : int -> int -> int * int = <fun> # let pair4 x (y:int) = ((x:'a list),(y:'a));; val pair4 : int list -> int -> int list * int = <fun> # let pair5 (x:'a list) (y:int) = (x,(y:'a));; val pair5 : int list -> int -> int list * int = <fun> Which of the two occurrences of the type variable |'a| a binding one? Who cares... It just works: within the same expression, the same type variable stands for the same type. > I'm looking for some tips and references regarding prescribing > poly-/mono-morphism. I know of three ways to do it: > 1) rely on the monomorphism-restriction -- kind of scary in that its > not explicitly obvious > 2) introducing scoped-type variables of interest -- explicit and modular > 3) introducing all type variables with a forall -- explicit but not modular It seems that with GCH 6.6, we are forced to go back to the fourth method -- the one that was available back in Haskell98. Use useless expressions to hint the typechecker. > bop :: forall x y z m c v . > ( SubType x v, SubType y v, SubType z v > , SubType (Fun m c v) v > , Monad m, Comonad c > ) => (x -> y -> z) -> Fun m c v > bop op = Fun fn > where fn = wrap fn' > where fn' v0 = (inj . Fun) (wrap fn'') > where fn'' v1 = inj (lazyPrj v0 `op` lazyPrj v1) > wrap :: (v -> v) -> (c v -> m v) > wrap = (return .) . (. counit) > If I leave the types to inference (i.e. drop the forall and the type > ascription for |wrap|), then I end up with this type > > bop :: ( SubType x v2, SubType y v1, SubType z v1 > , SubType (Fun m c v1) v2 > , Monad m, Comonad c > ) => (x -> y -> z) -> Fun m c v2 > Note the multiple |v|s; they wreak havoc in the rest of my code. It seems that you wish that, for example, v0 and v1 be of the same type. We have to be direct then and write where fn'' v1 = inj (lazyPrj v0 `op` lazyPrj (v1 `asTypeOf` v0) or where fn'' v1 = inj (lazyPrj v0 `op` lazyPrj v1) where useless = if True then v0 else v1 or where fn'' v1 | const True [v0,v1] = inj (lazyPrj v0 `op` lazyPrj v1) or something similar...

1 0

Type level functions (type of decreasing list)
by Greg Buchholz 18 Oct '06

18 Oct '06

I'm wondering about creating a data structure that has the type of decreasing numbers. If I want an increasing list, it is easy... > {-# OPTIONS -fglasgow-exts #-} > > data Succ a = S a deriving Show > data Zero = Z deriving Show > > data Seq' a = Cons' a (Seq' (Succ a)) | Nil' deriving Show ...which can be used like... > > zero = Z > one = S zero > two = S one > three = S two > > increasing = Cons' zero (Cons' one (Cons' two (Cons' three Nil'))) ...on the other hand, if I want the decreasing list, I can try... > > class Pre a b | a -> b > instance Pre (Succ a) a > instance Pre Zero Zero > > data (Pre a b) => Seq a = Cons a (Seq b) | Nil > > decreasing = Cons three (Cons two (Cons one Nil)) ...but that complains about "Not in scope: type variable `b'". Of course that makes perfect sense, but I'd like to know if there is a Haskell idiom that I'm missing in order to get this to work. Thanks, Greg Buchholz

3 3

Best Introduction To Monads For Newbies (& Especially Imparative Minds) I'v Ever Read!!!
by Kaveh Shahbazian 18 Oct '06

18 Oct '06

This is the best introduction to "Monads" for newbies and imparative mined that I'v ever read! For a long time I was searching for such an excellent text on monads. Ofcourse there are many good text there. But all of them are about mathematics and how clever the monads are. After all most of them are useless for a practical approach. Take a look at this http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html !! Have a good time with it!!

1 0

6.4 -> 6.6, scoped type variables, prescribing poly-/mono-morphism
by Nicolas Frisby 17 Oct '06

17 Oct '06

I've been writing some code that relies heavily on the type system. Some of my polymorphic functions end up too polymorphic. I'm looking for some tips and references regarding prescribing poly-/mono-morphism. I know of three ways to do it: 1) rely on the monomorphism-restriction -- kind of scary in that its not explicitly obvious 2) introducing scoped-type variables of interest -- explicit and modular 3) introducing all type variables with a forall -- explicit but not modular The rest of this email is a discussion of a particular problem I'm having. Scoped-type variables worked in 6.4, but no longer in 6.6. I'm sure there's good reasons for this (I think I found a Peyton-Jones message regarding it in 6.4->6.5) I just didn't quite catch on to them. The problem is in the |bop| function: class SubType a v where -- the lack of fundeps is required by design inj :: a -> v lazyPrj :: v -> Maybe a bop :: forall x y z m c v . ( SubType x v, SubType y v, SubType z v , SubType (Fun m c v) v , Monad m, Comonad c ) => (x -> y -> z) -> Fun m c v bop op = Fun fn where fn = wrap fn' where fn' v0 = (inj . Fun) (wrap fn'') where fn'' v1 = inj (lazyPrj v0 `op` lazyPrj v1) wrap :: (v -> v) -> (c v -> m v) wrap = (return .) . (. counit) The explicit forall is needed to introduce the scoped type variables so that I can prescribe the type of |wrap|. After that, the monomorphism restriction on |wrap| takes care of the rest of my worries (that there is only one |m|, only one |c|, and only one |v|). If I leave the types to inference (i.e. drop the forall and the type ascription for |wrap|), then I end up with this type bop :: ( SubType x v2, SubType y v1, SubType z v1 , SubType (Fun m c v1) v2 , Monad m, Comonad c ) => (x -> y -> z) -> Fun m c v2 Note the multiple |v|s; they wreak havoc in the rest of my code. (The monomorphism restriction still takes care of the |m| and |c|.) I'd like to not have to introduce the forall, because with that comes introducing the entire context of the type. Thus I have to maintain any changes to the context, which I would prefer to leave to inference for modularity's sake. In 6.4 I was able to fix this without having to introduce the forall; I could introduce scoped type-variables in patterns to get the job done. That felt a bit like voodoo, especially when trying to get it right for 6.6--which I gave up on doing. I can post the code that works with 6.4 if anyone would like to see it (I just can't find it at the moment). I know there's some work on introducing partial signatures (fun pat | False = ...), but I don't see how to prescribe monomorphism for particular type variables in that way. Any thoughts on how to get the preferred signature using scoped-type variables in 6.6? I'd also welcome any references you might think are relevant. Thanks for your time, Nick

1 0

Re: [Haskell-cafe] Newbie and working with IO Int and Int
by Víctor A. Rodríguez 17 Oct '06

17 Oct '06

Hi, > What's wrong with doing it this way? > > -- ** UNTESTED CODE ** > > verifyAdd :: Int -> Int -> Int -> Bool > verifyAdd a b sum | a + b == sum = True > otherwise = False > > testAddMundane :: Int -> Int -> Bool > testAddMundane a b = verifyAdd a b (a + b) > > -- all the IO-dependent stuff is below this line -- > > testAddRandom :: IO Bool > testAddRandom = do a <- randomIO > b <- randomIO > return verifyAdd a b (a + b) > First "thanks", but the problem is that I can't check if testAddRandom was sucessfull or not. If I replace (a+b) with (a+b-1) it still executes but couldn't check if it's True or False :-P -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

1 0

Newbie and working with IO Int and Int
by Víctor A. Rodríguez 17 Oct '06

17 Oct '06

Hi all, I'm really newbie to Haskell, and working on a program I'm trying to make some testing. I make some test on certain know values ( e.g. adding 10 to 15 must return 25) and some test on random values (eg. adding rnd1 to rnd2 must return rnd1+rnd2). The problem that makes me mad is the random number generation. I can obtain random numbers through module Random but all of them return IO Int values (all I need are Ints) instead of Int. I know that I can adjust my own functions to use IO Int instead of Int but the call to certain functions must contain Int parameters, because these ones can't be changed to accept IO Int (I read http://haskell.org/hawiki/ThatAnnoyingIoType and know that can convert from IO Int to Int :-P). How can I deal with this problem ?? Thanks in advance. -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

4 3

Error detection in GLR Happy grammar
by Iván Pérez Domínguez 16 Oct '06

16 Oct '06

Hi! I'm trying to detect parse errors in a happy GLR grammar, but I can't! I insert the special "token" 'error', and call the error function when an error is found. However, the program prints no error messages, and simply returns a ParseError at the end. Does any of you have an good example of a GLR parser with error detection and, if possible, error recovery as well?

2 2

Extended functionality for record field accessors
by Henning Thielemann 16 Oct '06

16 Oct '06

Here is some proposal for Haskell 2 1/2 or so: {- | In Haskell 98 the name of a record field is automatically also the name of a function which gets the value of the according field. E.g. if we have @ data Pair a b = Pair {first :: a, second :: b} @ then @ first :: Pair a b -> a second :: Pair a b -> b @ However for setting or modifying a field value we need to use some syntactic sugar, which is often clumsy. @ modifyFirst :: (a -> a) -> (Pair a b -> Pair a b) modifyFirst f r@(Pair {first=a}) = r{first = f a} @ We propose to extend the meaning of the record field names to a function which allows setting, getting and modifying values easily. -} module RecordAccess where import Control.Monad.State (MonadState) import qualified Control.Monad.State as State {- | The access functions we propose, look very similar to those needed for List.mapAccumL (but parameter order is swapped) and State monad. They get the new value of the field and the record and return the old value of the field and the record with the updated field. -} type Accessor r a = a -> r -> (a, r) {- * Access helper functions, these are similar to State methods and should be in Prelude -} {- | Set the value of a field. -} set :: Accessor r a -> a -> r -> r set f x = snd . f x {- | Get the value of a field. -} get :: Accessor r a -> r -> a get f = fst . f undefined {- | Transform the value of a field by a function. -} modify :: Accessor r a -> (a -> a) -> (r -> r) modify f g rOld = let (a,rNew) = f (g a) rOld in rNew {- * Access helper functions in a State monad. -} setState :: MonadState r m => Accessor r a -> a -> m () setState f x = State.modify (set f x) getState :: MonadState r m => Accessor r a -> m a getState f = State.gets (get f) modifyState :: MonadState r m => Accessor r a -> (a -> a) -> m () modifyState f g = State.modify (modify f g) {- * Example accessors for the pair type -} {- | Access to the first value of a pair. -} first :: Accessor (a,b) a first xNew (xOld,y) = (xOld, (xNew,y)) {- | Access to the second value of a pair. -} second :: Accessor (a,b) b second yNew (x,yOld) = (yOld, (x,yNew)) {- * Example accessors for the pair type -} {- | Example of using 'set', 'get', 'modify'. -} example :: Int example = get second $ modify second succ $ set first 'a' $ ('b',7) exampleState :: State.State (Char,Int) Int exampleState = do setState first 'a' modifyState second succ getState second

1 0

Debugging Newton's method for square roots
by Vraj Mohan 16 Oct '06

16 Oct '06

I am new to Haskell and need help in debugging my code. I wrote the following function for calculating square roots using Newton's method: my_sqrt :: Float -> Float my_sqrt x = improve 1 x where improve y x = if abs (y * y - x) < epsilon then y else improve ((y + (x/y))/ 2) x epsilon = 0.00001 This works for several examples that I tried out but goes into an infinite loop for my_sqrt 96. How do I go about debugging this code in GHC or Hugs? (The equivalent code is well-behaved on MIT Scheme)

8 8

Re[4]: [Haskell-cafe] windows file locking
by Bulat Ziganshin 15 Oct '06

15 Oct '06

Hello Stefan, Wednesday, October 11, 2006, 4:53:19 PM, you wrote: > So far the windows API seems to work for me. Currently I'm still struggling to not > write garbage to the file but the shared access works now. Does anyone have an > example how to use it (e.g. the implementation of hPutStr on windows or something, > i did not find it in the ghc source code)? > I tried to use Streams before but without the windows API. sorry, i'm a bit to fool you. there is a way to apply Handle API to HANDLE. you should just 1) open file using win32 API and get HANDLE 2) convert this HANDLE to FD using _open_osfhandle from win32 api 3) open Handle over FD using fdToHandle function from GHC.Handle module alternatively, you can use Streams with the same mechanism: 1) open file using win32 API and get HANDLE 2) convert this HANDLE to FD using _open_osfhandle from win32 api // it's in C language: fd = _open_osfhandle (someHANDLE, _O_TEXT | _O_WRONLY); 3) use bufferBlockStream to make full-featured Stream from this FD: do stream <- bufferBlockStream fd it is from MS docs: SUMMARY There are multiple types of file handles that can be opened using the Win32 API and the C Run-time: Returned Type File Creation API API Set --------------------------------------------- HANDLE CreateFile() Win32 HFILE OpenFile()/_lcreat() Win32 int _creat()/_open() C Run-time FILE * fopen() C Run-time In general, these file I/O "families" are incompatible with each other. On some implementations of the Win32 application programming interfaces (APIs), the OpenFile()/_lcreat() family of file I/O APIs are implemented as "wrappers" around the CreateFile() family of file I/O APIs, meaning that OpenFile(), _lcreat(), and _lopen() end up calling CreateFile(), returning the handle returned by CreateFile(), and do not maintain any state information about the file themselves. However, this is an implementation detail only and is NOT a design feature. NOTE: You cannot count on this being true on other implementations of the Win32 APIs. Win32 file I/O APIs may be written using different methods on other platforms, so reliance on this implementation detail may cause your application to fail. The rule to follow is to use one family of file I/O APIs and stick with them--do not open a file with _lopen() and read from it with ReadFile(), for example. This kind of incorrect use of the file I/O APIs can easily be caught by the compiler, because the file types (HFILE and HANDLE respectively) are incompatible with each other and the compiler will warn you (at warning level /w3 or higher) when you have incorrectly passed one type of file handle to a file I/O API that is expecting another, such as passing an HFILE type to ReadFile(HANDLE, ...) in the above example. MORE INFORMATION Compatibility ------------- The OpenFile() family of file I/O functions is provided only for compatibility with earlier versions of Windows. New Win32-based applications should use the CreateFile() family of file I/O APIs, which provide added functionality that the earlier file I/O APIs do not provide. Each of the two families of C Run-time file I/O APIs are incompatible with any of the other file I/O families. It is incorrect to open a file handle with one of the C Run-time file I/O APIs and operate on that file handle with any other family of file I/O APIs, nor can a C Run-time file I/O family operate on file handles opened by any other file I/O family. _get_osfhandle() ---------------- For the C Run-time unbuffered I/O family of APIs [_open(), and so forth], it is possible to extract the operating system handle that is associated with that C run-time handle via the _get_osfhandle() C Run-time API. The operating system handle is the handle stored in a C Run-time internal structure associated with that C Run-time file handle. This operating system handle is the handle that is returned from an operating system call made by the C Run-time to open a file [CreateFile() in this case] when you call one of the C Run-time unbuffered I/O APIs [_open(), _creat(), _sopen(), and so forth]. The _get_osfhandle() C Run-time call is provided for informational purposes only. Problems may occur if you read or write to the file using the operating system handle returned from _get_osfhandle(); for these reasons we recommend that you do not use the returned handle to read or write to the file. _open_osfhandle() ----------------- It is also possible to construct a C Run-time unbuffered file I/O handle from an operating system handle [a CreateFile() handle] with the _open_osfhandle() C Run-time API. In this case, the C Run-time uses the existing operating system handle that you pass in rather than opening the file itself. It is possible to use the original operating system handle to read or write to the file, but it is very important that you use only the original handle or the returned C Run-time handle to access the file, but not both, because the C Run-time maintains state information that will not be updated if you use the operating system handle to read or write to the file. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0