December 2000 - Haskell-Cafe

Mixture of Integer and Float arithmetic without "fromIntegral"?
by Christian Lescher 07 Dec '00

07 Dec '00

When defining expressions with arithmetic operations on a mixture of Integers and Floats (except literals), an explicit conversion by "fromIntegral" for the Integers is necessary, for example: ceiling (fromIntegral n / x) Is it possible to do the "fromInteger" conversion automatically? What's the best way to do it? (overloading of operators, etc.?) Christian

4 6

RE: Rank-2 polymorphism & type inference
by Carlos Camarao de Figueiredo 06 Dec '00

06 Dec '00

Hello. < class C t where op :: t -> Bool < instance C [t] where op x = True < < p y = (let f :: c -> Bool; f x = op (y >> return x) in f, y ++ []) < q y = (y ++ [], let f :: c -> Bool; f x = op (y >> return x) in f) < <The definitions of p and q differ only in the order of the components in <the pair on their right-hand sides. And yet: < < ghc and "Typing Haskell in Haskell" reject p, but accept q; < Hugs rejects q, but accepts p; < hbc rejects both p and q; < nhc98 ... (Malcolm, can you fill in the blank for us!). System CT accepts both. No type signature is required. The types inferred for p and q are, resp.: Forall a,b. [a] -> (b -> Bool, [a]) and Forall a,b. [a] -> ([a], b -> Bool) You can run the attached "encoded" program (in which 'op' is overloaded, instead of having its type annotated in a type class) in CTinH (http://www.dcc.ufmg.br/~camarao/CT/CTinH.tar.gz) Type inference in system CT is explained in a paper available at http://www.dcc.ufmg.br/~camarao/CT/CT.ps.gz (see also homepage at http://www.dcc.ufmg.br/~camarao/CT) Carlos

1 0

RE: Rank-2 polymorphism & type inference
by Mark P Jones 06 Dec '00

06 Dec '00

Johan Nordlander and I have been looking at these interesting examples, and would like to offer another entertaining variation to the collection: class C t where op :: t -> Bool instance C [t] where op x = True p y = (let f :: c -> Bool; f x = op (y >> return x) in f, y ++ []) q y = (y ++ [], let f :: c -> Bool; f x = op (y >> return x) in f) The definitions of p and q differ only in the order of the components in the pair on their right-hand sides. And yet: ghc and "Typing Haskell in Haskell" reject p, but accept q; Hugs rejects q, but accepts p; hbc rejects both p and q; nhc98 ... (Malcolm, can you fill in the blank for us!). The type signature for f forces context reduction to take place, and the results of this depend on whether or not the type of y is known, which in turn depends on which component of the pair the type checker analyzes first. I'm sure we will all continue to ponder this for some time to come ... All the best, Mark & Johan

2 1

Haskell Module Browser
by Jan Skibinski 05 Dec '00

05 Dec '00

A prototype of this tool is shown here: www.numeric-quest.com/haskell/explorer/browser.html Jan

1 0

RE: Rank-2 polymorphism & type inference
by Simon Peyton-Jones 05 Dec '00

05 Dec '00

| reported the bug several months ago.) Sorry! The bug has been fixed, but our nhc98 installation hasn't been rebuilt. | If your nhc98 compiler | was built by gcc, hbc, or nhc98 itself, then it gives a proper error | message here, viz: | | Couldn't simplify the context ((_180#) _171). | Possible sources for the problem are:11:20 No cigar! What is Joe Programmer going to do with that? But seriously, it's interesting that nhc fails in the same way as GHC and Hugs. Simon

1 0

RE: Rank-2 polymorphism & type inference
by Malcolm Wallace 05 Dec '00

05 Dec '00

> Both GHC and Hugs reject this module if the type signature for > test is omitted. NHC (v1.00, 2000-09-15) falls over completely, with > Fail: Prelude.chr: bad argument Rushing to the defence of nhc98 (as always!), I should point out that nhc98 actually falls over here because of a bug in ghc. (I reported the bug several months ago.) If your nhc98 compiler was built by gcc, hbc, or nhc98 itself, then it gives a proper error message here, viz: Couldn't simplify the context ((_180#) _171). Possible sources for the problem are:11:20 However, this is totally unrelated to the question of interest regarding type inference. Regards, Malcolm

1 0

List types
by Eric Allen Wohlstadter 04 Dec '00

04 Dec '00

Is there a way to make a list that contains multiple types? If not, why, and isn't this a serious restriction? I would like to be able to say: map show ['a',5] Since both Char and Num derive Show it seems like a reasonable thing to do. I realise classes in haskell don't work this way so I guess my question is, why not? Could I do something like this in O'Haskell, Clean, or some other functional language? In particular I am interested in exploring software engineering implications of monadic IO, separation of concerns, etc... Eric Wohlstadter UCDavis Software Engineering

4 3

RE: Beginner: error when using multiple where stmts in hugs98
by Mark P Jones 01 Dec '00

01 Dec '00

| I've been trying some examples in functional programming. Most things | work fine, but I have trouble with expressions with 'where' clauses | that define more then one local definition. | ... | For example: | ... | mydiff f = f' | where f' x = ( f (x+h) - f x) / h | h = 0.0001 The second line in the where clause (your attempt to define local variable h) will be treated as if it were part of the first definition (for the variable f'). Why? Because that's what the layout/indentation in your code specifies. In fact, to a Haskell compiler, your input looks a lot like the following, clearly incorrect definition: mydiff f = f' where f' x = ( f (x+h) - f x) / h h = 0.0001 If you want h to be defined as a local variable at the same level as f', then you should make sure the two definitions start with the same indentation: mydiff f = f' where f' x = ( f (x+h) - f x) / h h = 0.0001 The indentation you've actually used suggests that you might have intended the definition of h to be local to f'. In that case, you should add an extra "where" keyword: mydiff f = f' where f' x = ( f (x+h) - f x) / h where h = 0.0001 All the best, Mark

3 2

RE: a trap for the unwary
by Mark P Jones 01 Dec '00

01 Dec '00

Hi Malcolm, | Today, I thought I had discovered a bug in ghc. Then I tried hbc | and Hugs, and they also rejected my program with the same error. | nhc98 alone accepts it without complaint. I looked up the Report, | and it seems that the program is indeed incorrect. | | > f x = y | > where | > y | isSpace x = True | > y | otherwise = False For what it's worth, older versions of Hugs would have accepted this too. Only quite recently was it changed to conform to the report. Incidentally, although the above is not valid Haskell, the following should work just fine: f x = y where y | isSpace x = True | otherwise = False The difference is that I haven't repeated the left hand side of the definition in the second equation, which means that it's treated as one definition, not two. All the best, Mark (PS. An even nicer way to write this definition: f = isSpace :-)

1 0