- Haskell-Cafe - Haskell.org

Re: Multiple functions applied to a single value
by Graham Klyne 09 Dec '03

09 Dec '03

A little while ago, I sent a long rambling message [1] containing a key question in response to an earlier helpful response. I guess my ramblings were quite reasonably passed over as too much waffle, and the question was lost. Here, I isolate the question. From the earlier response, I understand that: ((->) r) is an instance of Monad, but I haven't found a definition of the Monad instance functions. I think these do the job, and they satisfy the monad laws [2]: [[ instance Monad ((->) r) where return a = const a g1 >>= f = \e -> f (g1 e) e ]] Can anyone confirm, or point me at an actual definition? #g -- [1] http://haskell.org/pipermail/haskell-cafe/2003-November/005566.html [2] Checking the Monad laws for the above definitions (cf. Haskell report p90): (A) return a >>= k = [g1/const a][f/k] \e -> f (g1 e) e = \e -> k (const a e) e = \e -> k a e = k a -- as required. (B) m >>= return = [g1/m][f/const] \e -> f (g1 e) e = \e -> const (m e) e = \e -> (m e) = m -- as required. (C) m >>= (\x -> k x >>= h) = [g1/m][f/(\x -> k x >>= h)] \e -> f (g1 e) e = \e -> (\x -> k x >>= h) (m e) e = \e -> (k (m e) >>= h) e = \e -> ([g1/k (m e)][f/h] \e1 -> f (g1 e1) e1) e = \e -> (\e1 -> h (k (m e) e1) e1) e = \e -> h (k (m e) e) e (m >>= k) >>= h = ([g1/m][f/k] \e -> f (g1 e) e) >>= h = (\e -> k (m e) e) >>= h = [g1/(\e -> k (m e) e)][f/h] \e1 -> f (g1 e1) e1 = \e1 -> h ((\e -> k (m e) e) e1) e1 = \e1 -> h (k (m e1) e1) e1 = \e -> h (k (m e) e) e So both expressions are equivalent, as required. ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

3 2

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 09 Dec '03

09 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 07 Dec '03

07 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 03 Dec '03

03 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

Multiple functions applied to a single value
by Graham Klyne 28 Nov '03

28 Nov '03

There's a possible programming idiom that I repeatedly find myself thinking about as I write my code. It feels like a kind of dual of fold, except that it's not necessarily confined to lists. I'm wondering if anything like this is discussed in the literature, or implemented in the libraries... Scene-setting: broadly speaking, fold takes a function and applies it to several values, and combines the results in some way. What I'm thinking of is a combinator or suchlike that takes two or more functions, applies them (separately) to a single value, then combines the results of those combinations. One function that I have defined and use in my code is called 'flist': flist :: [a->b] -> a -> [b] flist fs a = map ($ a) fs (which is similar to Monad.ap, except that the 'a' parameter is not a list/monad). I could imagine combining this with a fold in some cases. A more generalized form of this that works with arbitrary monads was suggested by Derek Elkin: fmonad :: Monad m => m (a->b) -> a -> m b fmonad fm a = do { f <- fm ; return $ f a } But not all cases I encounter involve lists or monads. A different case might look like this: > eval :: (b->c->d) -> (a->b) -> (a->c) -> (a->d) > eval f g1 g2 a = f (g1 a) (g2 a) So, for example, a function to test of the two elements of a pair are the same might be: > pairSame = eval (==) fst snd giving: > pairSame (1,2) -- false > pairSame (3,3) -- true Or a function to subtract the second and subsequent elements of a list from the first: > firstDiffRest = eval (-) head (sum . tail) > firstDiffRest [10,4,3,2,1] -- 0 That's about as far as I've taken this, but it feels as if it might be part of a more general pattern. Hence my question: is there anything like this in the libraries? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 2

Re: ANNOUNCE: Hugs98 November 2003 release
by Ross Paterson 26 Nov '03

26 Nov '03

[moving to haskell-cafe] On Tue, Nov 25, 2003 at 08:31:12PM +0100, Vincenzo aka Nick Name wrote: > Alle 17:51, martedì 25 novembre 2003, Ross Paterson ha scritto: > > - Integrated .NET support (on Windows). > > What does this exactly mean? See the dotnet/doc subdirectory of the bundle, or http://galois.com/~sof/hugs98.net/ > And, besides, is there any hope of supporting mono? I would guess it's possible, if someone volunteers to do the work. Can't see the point myself.

1 0