- Haskell - Haskell.org

[ANNOUNCE] shell-haskell 1.0.0
by David Sankel 09 May '03

09 May '03

=================== shell-haskell 1.0.0 =================== shell-haskell provides utilities to communicate with other process's via Haskell code. This library can be used for something as simple as getting the output of another program or as complex as interacting with an interpreter. see http://www.electronconsulting.net/shell-haskell for details. David J. Sankel

2 3

Additional libraries with GHCi
by Graham Klyne 08 May '03

08 May '03

This message started as a question, but having found a solution I'm offering it as a suggestion for the GHC documentation... I'm trying to run my code developed under HUGS to GHCi (5.04.3), where the host OS is Win2K. I've tried -L<path> command line option, :Set -L<path>, and creating an environment variable LD_LIBRARY_PATH, but GHCi still fails to import modules from the indicated directory. My error message is: Can't find module 'HUnit' (while processing GraphTest.h) ... I finally stumbled across the fact that source files are picked up using the '-i' command line option. Further, I note that files are not located if a trailing '/' or '\' is included on the directory name. My suggestion, therefore, is to add a note to section 3.5.2 of the GHC user guide ("Extra Libraries" in the section on GHCi), along the lines of: [[ Additional libraries provided as Haskell Source files (.hs, .lhs) may be located by using the "-i" command line option. The directory name must be specified without a trailing "/" (or "\") character. ]] Is there an environment variable I can use with GHCi on Windows to achieve a similar effect? #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

Standard Array library question
by Jeff Newbern 08 May '03

08 May '03

Hello, I have a question regarding the standard Array library. In the Haskell98 report, section 16.1 it says: Not every index within the bounds of the array need appear in the association list, but the values associated with indices that do not appear will be undefined (i.e. _|_). However, this feature seems to be of diminished value because of the way the Array.indices function is defined in section 16.4: indices :: (Ix a) => Array a b -> [a] indices = range . bounds Since this returns all of the indices within the array bounds, even the ones that are undefined, it causes other functions in the Array module that use indices to build lists with undefined elements. These are fine due to lazy evaluation, but it means that such arrays cannot be shown or used in a strict manner. If I do "indices (array (1,3) [(1,1),(3,9)])", I would like to get [1,3] not [1,2,3]. Then for "elems ..." I would get [1,9] not [1,_|_,9]. So first: Is there a good reason for the current definition? And second: Is there any way to get the behavior I want within the existing set of libraries. For instance, an isDefined predicate could help. Thanks, Jeff Newbern

2 1

Naming and subexpressions
by ketil＠ii.uib.no 08 May '03

08 May '03

Hi, I have a program, structured approximately like so main = do let stage1 = e1... let stage2 = e2...stage1... stage3 <- e3...stage2 case something of foo -> output stage1 bar -> output stage2 baz -> output stage3 I think this is an improvement from using multiple main functions, since it reveals the pipeline structure of the program and the modularity of the stages. It appears¹, however, that naming the result of stage1 prevents it from being garbage collected when subsequent stages are produced. Since stage1 is a huge list, this leads to a space leak. So, is there any way to avoid this? Do I need to restructure my program? I could conceivably do main = do let stage1 = e1... let stage2 = e2...(e1...)... : and so on, but an aggressive (but slightly dumb) compiler might rediscover the similarity and CSE it. Suggestions more than welcome. -kzm ¹ Memory retainer profiling shows the product being retained by SYSTEM, so I *think* this is the right interpretation. -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Announce: buddha 0.6 released
by Bernard James POPE 08 May '03

08 May '03

Hi all, buddha 0.6 is now available: http://www.cs.mu.oz.au/~bjpop/buddha/ buddha is a declarative debugger for Haskell 98. The main new feature is an automated front end, so all you have to do is: buddha {- wait a bit -} cd Buddha; ./debug Version 0.6 supports _most_ of the language, the main missing bits are: record syntax (sometimes works, but not fully) deriving statements (you have to expand them yourself, sigh) standard libraries: Ratio Numeric Directory Time Random (because of above) buddha should work with ghc 5.04 or greater, on any unix-a-like machine. The missing bits will hopefully be added in the next few releases. Cheers, Bernie.

1 0

RE: Solved: Typing problems with polymorphic recursion and typeclasses
by Simon Peyton-Jones 07 May '03

07 May '03

| I admit I'm confused: can I compose a type expression that describes | the type of h? For example, I plan to document the function h and want | to give its type signature. I don't know what to write. We know that | "(Show fa) => t -> fa" is not it: it's too polymorphic. Is there any | type expression that is polymorphic just enough? It's only "too polymorphic" at the recursive call. You can make that call use a more specific type, using lexically scoped type variables, as has been suggested earlier in this thread. Then you can certainly have a type signature for 'h', as polymorphic as you please. Simon

1 0

Solved: Typing problems with polymorphic recursion and typeclasses
by oleg＠pobox.com 07 May '03

07 May '03

I think I can explain why Haskell compilers behave as they do with regards to Levent Erkok's problem, and how to fix it. It seems the compilers are more powerful than we imagine, but are compelled to conceal their power and to lie to us. First, let us distill the problem to the following few lines: > f:: (Show fa) => fb -> fa > f = undefined > > g:: (Show ga) => ga -> gb > g = undefined > > -- h:: (Show fa) => t -> fa > h b = f (g (h b)) This code loads and checks. If we ask the compiler for the type of h, we get the type of h that was commented out in the code above. If we remove the comment and reload the code, we get an error: Ambiguous type variable(s) `fa' in the constraint `Show fa' arising from use of `h' at /tmp/p.lhs:12 In the first argument of `g', namely `(h b)' In the first argument of `f', namely `(g (h b))' This behavior seems rather puzzling: the compiler refuses to accept its own type. The problem is that the compiler is slightly lying to us. When we ask for the type *Main> :type h forall fa t. (Show fa) => t -> fa the real type of h is forall t. t -> (function-of-t) The real type of h is not totally polymorphic : it is dependent! It goes without saying that such types cannot be expressed in Haskell. It is stunning that the compiler managed to infer such a dependent type, albeit it has no way to properly print it. The compiler could have used the following notation: forall fa t | t -> fa. (Show fa) => t -> fa Perhaps even more stunning is that we can test our hypothesis. We can explicitly specify the functional dependence between types. We will use lexically-scoped type variables, described in the eponymous paper by Simon Peyton-Jones and Mark Shields. The following works in GHC 5.04.1, given -fglasgow-exts flag. > h1:: (Show t2) => t1 -> t2 > h1 b :: g1a > = (f (g ((h1 b)::g1a))) Original example by Levent Erkok's also works.

3 3

RE: Solved: Typing problems with polymorphic recursion and typeclasses
by oleg＠pobox.com 07 May '03

07 May '03

Regarding > > f:: (Show fa) => fb -> fa > > f = undefined > > > > g:: (Show ga) => ga -> gb > > g = undefined > > > > -- h:: (Show fa) => t -> fa > > h b = f (g (h b)) Simon Peyton-Jones wrote: > so the recursive call has the same type as the main function; so the > situation is identical to the case where there is no type signature, and > the recursive call is at the same type as the function being defined. > ... > But giving an explicit type signature for h makes it *more* polymorphic, > and that in turn leads to ambiguity in this particular case. I admit I'm confused: can I compose a type expression that describes the type of h? For example, I plan to document the function h and want to give its type signature. I don't know what to write. We know that "(Show fa) => t -> fa" is not it: it's too polymorphic. Is there any type expression that is polymorphic just enough? Thank you!

1 0

RE: fun deps and constraints in data decls
by Simon Peyton-Jones 06 May '03

06 May '03

Yes, I think you could argue that this is a bug in GHC. The trouble is that the data constructor T is really quantified over 'b' as well, but the data type is not T :: forall a b. C a b => a -> T a GHC assumes that the data type is parameterised over the same type variables as the constructor. I could fix it so that it does not have this assumption, but I'm not keen to do so a) it's not trivial b) it only involves the context to a data constructor, an entirely unnecessary feature that I consider to be a mistake in Haskell. I'm reluctant to invest effort in it. So for now, let's treat it as a won't -fix bug. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Iavor Diatchki | Sent: 05 May 2003 19:47 | To: Haskell Mailing List | Subject: fun deps and constraints in data decls | | > module Test where | | Hello, | | Both GHC and Hugs report an error on the example bellow, | which to me seems wrong. Is this a bug, or am I missing something? | | > class C a b | a -> b | > newtype C a b => T a = T a | > t :: C a b => a -> T a | > t = T | | The error reported is that "b" is an undefined type variable. | Since "a" determines "b" using the functional dependency, | I was expecting the example to work. I expected the type | of the data constructor "T" to be as the one given in the | type signature for "t", as I though that constraints on | data/newtype declarations simply were added to the constructors. | Both of the implementations are happy if I simply comment out the | constraint, | so they do not consider the type signature for "t" to be malformed in | any way. | | bye | iavor | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: Solved: Typing problems with polymorphic recursion and typeclasses
by Simon Peyton-Jones 06 May '03

06 May '03

| First, let us distill the problem to the following few lines: | | > f:: (Show fa) => fb -> fa | > f = undefined | > | > g:: (Show ga) => ga -> gb | > g = undefined | > | > -- h:: (Show fa) => t -> fa | > h b = f (g (h b)) | | This code loads and checks. If we ask the compiler for the type of h, | we get the type of h that was commented out in the code above. If we | remove the comment and reload the code, we get an error: | | Ambiguous type variable(s) `fa' in the constraint `Show fa' | arising from use of `h' at /tmp/p.lhs:12 | In the first argument of `g', namely `(h b)' | In the first argument of `f', namely `(g (h b))' | | This behavior seems rather puzzling: the compiler refuses to accept | its own type. The problem is that the compiler is slightly lying to | us. When we ask for the type | *Main> :type h | forall fa t. (Show fa) => t -> fa | | the real type of h is | forall t. t -> (function-of-t) I don't agree with that. h really is polymorphic. Its result is the result of f, which is any type at all so long as it is Showable. | Perhaps even more stunning is that we can test our hypothesis. We can | explicitly specify the functional dependence between types. We will | use lexically-scoped type variables, described in the eponymous paper | by Simon Peyton-Jones and Mark Shields. The following works in GHC | 5.04.1, given -fglasgow-exts flag. | | > h1:: (Show t2) => t1 -> t2 | > h1 b :: g1a | > = (f (g ((h1 b)::g1a))) This is nothing to do with dependent types. Your type signature simply constrains the result of (h1 b) to have the type g1a, and which is specified by the LHS to be the type of the result to the whole call. So now the recursive call has an argument b which is the same as the argument to the definition of h1 and a result whose type is the same as the type of the result of h1 so the recursive call has the same type as the main function; so the situation is identical to the case where there is no type signature, and the recursive call is at the same type as the function being defined. Consider the well known show (read s) This is ambiguous unless we add a signature to make the result of 'read' less polymorphic: show ((read s) :: Int) But giving an explicit type signature for h makes it *more* polymorphic, and that in turn leads to ambiguity in this particular case. Simon

1 0