- Haskell-Cafe - Haskell.org

RE: GHCi, Hugs (was: Mixture ...)
by Simon Peyton-Jones 08 Dec '00

08 Dec '00

| This puzzles me a bit. From talking with people at the | Haskell Workshop, I understood that GHCi would only be an | interactive compiler. | | The disadvantage with that is that compilation time might be | very long. But it was said that that is the price we pay. | | The only advantage I can see with interpreted code is the | fact that it can be compiled (or "processed") much faster. | Will GHCi reach speeds up to Hugs level? It'll definitely be mixed compiled/interpreted. No, compiling won't be nearly as fast as Hugs, but it will, we earnestly hope be "fast enough". Execution should be faster than Hugs; apart from anything else you'll get compiled libraries. | One bad thing with Hugs is that, for large systems, the | loading/processing time gets longer, and, worse, is repeated | every time one loads the system. This is especially bad when | using "runhugs". Hopefully GHCi will work better in that | case! Yes, a lot better. The idea is only to recompile things that have changed. | Another thing that worries me is that Hugs will die. Not | only because I like Hugs a lot, but also that it is yet | another Haskell system that is dying. I think that is a very reasonable concern. I certainly want to see Hugs alive and kicking. Simon

1 0

HaXml question
by Michael Zawrotny 08 Dec '00

08 Dec '00

This question is probably a bit low-brow compared to the normal discussions of type systems, rank-2 polymorphism... Anyway, here goes nothing. I'm working on getting up to speed on haskell in general and HaXml in particular. I read through the ICFP paper that came with the distribution, but it was a bit dense for a beginner. Is there anything out there that is more oriented towards people who are less fluent in haskell? I think that my problem may be a lack of understanding of the whole idea of what combinators are and how they work. What I would like to do is something like the Xtract tool that comes with HaXml, but to select an element based on the path criteria specified (as Xtract already does), but that also satisfies an arbitrary predicate function that I would specify (e.g. a function that normalizes case and then tests for equality, regexp match, etc.). If anybody can help out on either front, I would greatly appreciate it. Thanks, Mike

1 0

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

07 Dec '00

> OK, OK, I've just added -fno-monomorphism-restriction to GHC. Great! Will there also be a similar option for Stg Hugs? Christian

1 0

RE: Mixture of Integer and Float arithmetic without "fromIntegral "?
by Simon Peyton-Jones 07 Dec '00

07 Dec '00

OK, OK, I've just added -fno-monomorphism-restriction to GHC. Simon | -----Original Message----- | From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] | Sent: 07 December 2000 10:28 | To: haskell-cafe(a)haskell.org | Subject: Re: Mixture of Integer and Float arithmetic without | "fromIntegral"? | | | > > module Defs where | > > | > > n = 3 | > > x = 12.3 | > > | > > test = ceiling (x / n) | > | > There are people (including me) who think that the monomorphism | > restriction rule, which makes the above definitions without type | > signatures monomorphic and thus defaulted to concrete types, should | > be removed. | | If you want to experiment with an implementation that do not enforce | the monomorphism restriction, try nhc98. It happily infers the types | | n :: Num a => a | x :: Fractional a => a | | for the toplevel definitions shown. I don't think anyone has ever | complained about this feature. | | Regards, | Malcolm | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

1 0

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