December 2003 - Haskell-Cafe

RE: Common subexpressions are not optimized to single one?
by Simon Marlow 09 Dec '03

09 Dec '03

> I'm wondering about the optimization of ghc. I thought that since > functions are pure in haskell, compiler can/do factorize common > subexpressions when it optimizes a code. But the result of > the following > experiment looks negative; "g 10 100" is caluculated twice. > > Am I missing something? If not, > What prevents ghc from performing that optimization? > Should I always factorize common subexpressions > manually(using let or where)? GHC *does* do common sub-expression elimination. However it only considers simple applicative subexpressions as candidates for commoning up, and in your example it turns out that by the time the CSE pass runs, various inlinings and transformations have happened which means that the candidate expressions are quite large. Perhaps we could run the CSE pass at an earlier stage, or perhaps it should run twice - that's one of those tradeoffs between compilation time and runtime. Perhaps the extra pass should be done for -O2 only. We'll look into it. Thanks for the example, anyhow. Cheers, Simon

1 0

Infinite types
by Jeffrey A. Scofield 08 Dec '03

08 Dec '03

Greetings. Say I have the following function, adapted from Pierce, Types and Programming languages: f n () = (n, f (n + 1)) Now, this function fails to typecheck in ghc 6.0.1 because the subexpression f (n + 1) has the infinite type t = () -> (t1, t) And so I assume (perhaps wrongly?) that f is ill-typed in Haskell 98. I have two questions: 1. How can I tell from the Haskell 98 Revised Report that this function isn't allowed? The discussions of typing in the Report generally defer to the ``standard Hindley-Milner analysis.'' Is this really enough to tell that the function isn't well-typed in Haskell? I concede that I haven't read the cited Hindley and Damas/Milner papers, but it seems like there might be more to say about what is and isn't allowed. 2. Is there by chance a compiler option for ghc that causes the restriction to be dropped? I don't need this kind of function for anything practical (and I realize I can get an equivalent effect with an algebraic datatype). I'm just trying to figure out what typing restrictions (if any) are implicitly assumed in the Report. (Generally, this is the kind of stuff I don't know, as a relative newcomer to fp.) Regards, Jeff Scofield (PhD) Seattle

6 9

Re: Infinite types
by jeff＠dhitechnologies.com 06 Dec '03

06 Dec '03

Alastair Reid wrote: > > 1. How can I tell from the Haskell 98 Revised Report that [a function > > with an infinite type] > > isn't allowed? The discussions of typing in the Report > > generally defer to the ``standard Hindley-Milner analysis.'' > 1) The only way to write the recursive type you want > in Haskell is using type synonyms. > 2) The section describing type synonyms (4.2.2) explicitly rules it out. This really makes sense, but I had been interpreting 4.2.2 as a limitation on type synonym declarations rather than on types themselves. It says: Although recursive and mutually recursive datatypes are allowed, this is not so for type synonyms, unless an algebraic datatype intervenes. To my (untutored) eye, this looks like a limitation on what can appear in a type synonym declaration, not a limit on what types can appear in a program. Is it a reliable mental model to assume that if there's no way to declare a type in Haskell, the type itself isn't allowed in a program? (Note that this can't be true in every case; according to 4.5.4, the monomorphism restriction introduces types that can't be declared in Haskell.) Thanks very much for the response. Regards, Jeff Scofield Seattle

1 0

Common subexpressions are not optimized to single one?
by Koji Nakahara 03 Dec '03

03 Dec '03

Hi, I'm wondering about the optimization of ghc. I thought that since functions are pure in haskell, compiler can/do factorize common subexpressions when it optimizes a code. But the result of the following experiment looks negative; "g 10 100" is caluculated twice. Am I missing something? If not, What prevents ghc from performing that optimization? Should I always factorize common subexpressions manually(using let or where)? --- $ cat op.hs module Main where import System.IO.Unsafe foreign import ccall "count" io_count:: IO Int f :: Int -> IO Int f x = do {y <- io_count; return $ x + y} g :: Int -> Int -> Int g x y = unsafePerformIO $ do {z <- f x; return $ z + y} main = do print (g 10 100, g 10 100) $ $ cat ffi_test_c.c static int counter = 0; int count() {return counter++;} $ $ gcc -c ffi_test_c.c;ghc -O2 -ffi op.hs;ghc -o op_test op.hs ffi_test_c.o $ ./op_test (110,111) --- I want to use some C functions from haskell each of which is not pure but the result of their sequential combination is pure. I'm planning to write some functions like g above(but more complex and actually pure) and considering the optimization of the code using them. Thanks in advance. Koji Nakahara

3 3

Re: show function
by Hamilton Richards 02 Dec '03

02 Dec '03

At 10:05 PM -0500 12/2/03, rui yang wrote: >I want to print a function which itself have some functions as it's parameters >and will return some functions as the results, and I want to print out the >result, does anyone knows how to define the instance declaration of show class >to this function type? [moving to Haskell Cafe] The mechanics of such an instance definition are simple enough. Letting F be your function type, this would do it: > instance Show F where > showsPrec f = ... some String ... The hard question is what the result should be. Unlike the types already in Show (such as Bool, Int, Char, etc.), there's no canonical representation for functions (other than a complete list of argument-result pairs, which would not be very useful). Regards, --Ham -- ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138 Austin, Texas 78712-0233 ham(a)cs.utexas.edu hrichrds(a)swbell.net ------------------------------------------------------------------

1 0

Mistake in Haskell wiki MonadError?
by Graham Klyne 01 Dec '03

01 Dec '03

At: http://www.haskell.org/hawiki/MonadError I see: [[ instance Monad (Either e) where return = Right (Left e) >>= _ = e (Right a) >>= f = f a ]] Shouldn't that be: [[ (Left e) >>= _ = Left e ]] ? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Re: Why are strings linked lists?
by Mark Carroll 01 Dec '03

01 Dec '03

(shifting to Haskell-Cafe) On Fri, 28 Nov 2003, Donald Bruce Stewart wrote: > ajb: (snip) > > As a matter of pure speculation, how big an impact would it have if, in > > the next "version" of Haskell, Strings were represented as opaque types > > with appropriate functions to convert to and from [Char]? Would there be > > rioting in the streets? I'd be sad to lose some convenient list-based string type because I make a lot of use of the fact that strings are lists in processing them. > You could look at GHC's FastString representation (used internally). > It is in $fptools/ghc/compiler/utils/FastString.lhs It does make sense to have a rather faster form of string conveniently available in /some/ form. -- Mark

4 3