August 2003 - Glasgow-haskell-users

RE: Polymorphic kinds
by Simon Peyton-Jones 05 Aug '03

05 Aug '03

The real question is: why does GHC distinguish kind * from kind #? For example, Int has kind * Int# has kind # The main reason is this: a polymorphic function assumes that values of type 'a' are represented by a pointer. For example: const :: a -> b -> a const assumes that its arguments are represented by pointers. The machine instructions simply would not work if it was passed (say) two double-precision floats, of type Double#. To avoid this bad thing happening, GHC imposes the following rule (described in detail in "Unboxed values as first class citizens" http://research.microsoft.com/~simonpj/Papers/unboxed-values.ps.Z) A polymorphic type variable (such as 'a' and 'b' in the type of const) can only be instantiated by a boxed type (of kind *) Value whose type is of kind * are always represented by a pointer. Value whose type is of kind # are represented in a type-dependent way. In your particular case, consider '>>='. It is required to transport the value returned by its left argument to the function that is its right argument. The machine instructions reqd to do that differ if the value so transported is an Int#. [One of the big advantages of .NET is that its generic type system *does* allow polymorphic type variables to be instantiated with unboxed types, using run-time code generation to "fluff up" copies of the function code instantiated with the representation type.] [An Int# is the same size as a pointer, yes, but its GC behaviour is different.] Now, do-notation expands to the overloaded '>>=' stuff, so you are stuck. It would be possible, I guess, to change the way in which do-notation expanded, so that in the special case of the IO monad unboxed LHSs were allowed. That might allow you to use do-notation, but it seems a bit ad hoc. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Sebastien Carlier | Sent: 04 August 2003 16:09 | To: glasgow-haskell-users(a)haskell.org | Subject: Polymorphic kinds | | | Hello, | | I am experimenting with GHC to write low level code (e.g., device | drivers, interrupt handlers). The ultimate goal is to write a | prototype operating system in Haskell, using the GHC RTS as a kind of | microkernel (this appears to be relatively easy by removing all the | dependencies on an operating system, and providing a block allocator | and interval timers). | | I have added the necessary primitive operations to generate privileged | instructions for IA32 to GHC, and it seems to work fine, good quality | assembly code is generated. | | Now, I would like to make use of do-notation to write cleaner code | (threading a State# RealWorld through computations is quite ugly). | I want to avoid allocating memory in parts of the code, so I would | like to be able to have monadic computations which return unboxed | values. Sadly, GHC currently does not appear to allow that. | | The following example illustrates the problem: | | > {-# OPTIONS -fglasgow-exts #-} | > | > import GHC.Prim | > | > x :: IO Int# | > x = | > return 1# | | GHC (HEAD from 2003-08-01) reports: | | T.lhs:5: | Kind error: Expecting a lifted type, but `Int#' is unlifted | When checking kinds in `IO Int#' | In the type: IO Int# | While checking the type signature for `x' | | T.lhs:7: | Couldn't match `*' against `#' | When matching types `a' and `Int#' | Expected type: a | Inferred type: Int# | In the first argument of `return', namely `1#' | | After looking into the problem for a while, I realized that GHC does | not have polymorphic kinds - after checking a bunch of definitions, it | "zonks" all kind variables to (Type *) and all boxity variables to *. | So IO has kind (Type * -> Type *), and cannot be applied to an unboxed | value of kind (Type #). | | GHC has had explicit kind annotations for a while: | <http://www.haskell.org/pipermail/haskell/2002-February/008906.html> | So I ought to be able define an IO# type for computations that return | unboxed values. | (By the way, is there already an unboxed unit value and type?) | | Strangely, GHC did not recognizes # as the kind of unlifted types, so | I added that to the compiler, and hoped that things would work out. | Well, almost. | | > {-# OPTIONS -fglasgow-exts #-} | > | > import GHC.Prim | > | > newtype IO# (a :: # ) = IO# (State# RealWorld -> (# State# RealWorld, a #)) | > | > x :: IO# Int# | > x = IO# (\ s -> (# s, 1# #)) | | GHC reports: | | T.lhs:8: | Illegal unlifted type argument: Int# | In the type: IO# Int# | While checking the type signature for `x' | | The example is accepted if "newtype" is replaced by "type" (and by | removing uses of the IO# value constructor), so I can proceed with my | experiment by not using do-notation (defining return#, then#, etc | appears to work fine). | | Not being able to use do-notation is slightly inconvenient; is there a | reason why newtypes cannot be applied to unlifted type arguments? | | I expect that I would eventually have been beaten anyway when trying | to make an instance of the Monad type class for the above IO# newtype, | since Monad is probably regarded as a predicate of kind (* -> *) -> P | (where P would be the hypothetical kind of propositions); application | to an operator of kind (# -> *) would fail. | | What would need to be done to extend the compiler so that it allows IO | computations to be able to return unboxed values? For some reason I | am worried that "just" having polymorphic kind may not be enough. | I also fail to understand all the implications of having polymorphic | kinds, so I would greatly appreciate if one of the GHC experts could | say something about that too. | | -- | Sebastien | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: linker errors
by Simon Peyton-Jones 05 Aug '03

05 Aug '03

| The code is hand-written and the maximum tuple-size | used is 4. It works fine in Hugs. It uses the Parsec | library (not the version in GHC's "text" package, but | from a local copy. The ParsecPrim.hs was replaced by | the version from Parsec's web-site -- it works as I | expected, but not the one distributed with GHC or | Hugs). Well that is mysterious. Can you send the offending source code (plus the modules it imports, and a Makefile)? Preferably with as few imports as possible... Simon

1 0

ANNOUNCE: GHC version 6.0.1
by Simon Marlow 04 Aug '03

04 Aug '03

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.0.1 ============================================================= We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 6.0.1. This is a bug-fix release relative to 6.0. The most important bugfixes are: * Fixes to make GHC work with GCC 3.3 * Fix for the "GHC deletes source files" bug * :cd now unloads any loaded modules in GHCi. * -mk-dll should work better on Windows. in addition to various other bugfixes. The release notes lists the changes in the 6.0 line relative to 5.04: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998, and revised in December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (Mac OS X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

6 6

Polymorphic kinds
by Sebastien Carlier 04 Aug '03

04 Aug '03

Hello, I am experimenting with GHC to write low level code (e.g., device drivers, interrupt handlers). The ultimate goal is to write a prototype operating system in Haskell, using the GHC RTS as a kind of microkernel (this appears to be relatively easy by removing all the dependencies on an operating system, and providing a block allocator and interval timers). I have added the necessary primitive operations to generate privileged instructions for IA32 to GHC, and it seems to work fine, good quality assembly code is generated. Now, I would like to make use of do-notation to write cleaner code (threading a State# RealWorld through computations is quite ugly). I want to avoid allocating memory in parts of the code, so I would like to be able to have monadic computations which return unboxed values. Sadly, GHC currently does not appear to allow that. The following example illustrates the problem: > {-# OPTIONS -fglasgow-exts #-} > > import GHC.Prim > > x :: IO Int# > x = > return 1# GHC (HEAD from 2003-08-01) reports: T.lhs:5: Kind error: Expecting a lifted type, but `Int#' is unlifted When checking kinds in `IO Int#' In the type: IO Int# While checking the type signature for `x' T.lhs:7: Couldn't match `*' against `#' When matching types `a' and `Int#' Expected type: a Inferred type: Int# In the first argument of `return', namely `1#' After looking into the problem for a while, I realized that GHC does not have polymorphic kinds - after checking a bunch of definitions, it "zonks" all kind variables to (Type *) and all boxity variables to *. So IO has kind (Type * -> Type *), and cannot be applied to an unboxed value of kind (Type #). GHC has had explicit kind annotations for a while: <http://www.haskell.org/pipermail/haskell/2002-February/008906.html> So I ought to be able define an IO# type for computations that return unboxed values. (By the way, is there already an unboxed unit value and type?) Strangely, GHC did not recognizes # as the kind of unlifted types, so I added that to the compiler, and hoped that things would work out. Well, almost. > {-# OPTIONS -fglasgow-exts #-} > > import GHC.Prim > > newtype IO# (a :: # ) = IO# (State# RealWorld -> (# State# RealWorld, a #)) > > x :: IO# Int# > x = IO# (\ s -> (# s, 1# #)) GHC reports: T.lhs:8: Illegal unlifted type argument: Int# In the type: IO# Int# While checking the type signature for `x' The example is accepted if "newtype" is replaced by "type" (and by removing uses of the IO# value constructor), so I can proceed with my experiment by not using do-notation (defining return#, then#, etc appears to work fine). Not being able to use do-notation is slightly inconvenient; is there a reason why newtypes cannot be applied to unlifted type arguments? I expect that I would eventually have been beaten anyway when trying to make an instance of the Monad type class for the above IO# newtype, since Monad is probably regarded as a predicate of kind (* -> *) -> P (where P would be the hypothetical kind of propositions); application to an operator of kind (# -> *) would fail. What would need to be done to extend the compiler so that it allows IO computations to be able to return unboxed values? For some reason I am worried that "just" having polymorphic kind may not be enough. I also fail to understand all the implications of having polymorphic kinds, so I would greatly appreciate if one of the GHC experts could say something about that too. -- Sebastien

2 1

RE: linker errors
by Simon Peyton-Jones 04 Aug '03

04 Aug '03

One of GHC's infelicities is that it only supports tuples up to a certain size -- currently 62. You just can't get bigger tuples. Your program uses a 73-tuple. My guess is that your code is generated by some other program that's generating big tuples? The only workaround is to nest your tuples. It would really be much better if GHC complained in the front end about over-size tuples. I'll fix that. The "real" fix (arbitrary size tuples) isn't really hard, but it involves real work so we keep postponing it on the gounds that it seldom bites. So please continue to say if it bites you, so that we know. It used to be the case that simply having a nest of more than 62 mutually-recursive functions would trigger this bug, but that should no longer be the case with 6.0. Please say if that is happening. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of A.P. Rao | Sent: 04 August 2003 05:50 | To: glasgow-haskell-users(a)haskell.org | Subject: linker errors | | Hi, | | I am getting an "undefined reference" error listed | below when I try to | build my program. I am able to successfully compile | and link a trivial | "Hello World" program, but not my application code. | | I tried 3 different versions of ghc (5.04.3, 6.0 and | 6.0.1) on my | redhat-9 linux pc. The gcc compiler is at version | 3.2.2 (gcc (GCC) | 3.2.2 20030222 (Red Hat Linux 3.2.2-5)). I even | tried the ghc 6.0.1 | compiler built on my own pc. The result is the same. | | Error: | -------------------- | AsnParser.o(.text+0x21139): In function `r2CD0_entry': | : undefined reference to `DataziTuple_Z73T_con_info' | collect2: ld returned 1 exit status | -------------------- | | Any suggestions as to what may be causing this and | how I can get rid | of it. To me, it looks like a code-generation bug on | ghc's side. | | Thanks, | A.P. Rao | | | __________________________________ | Do you Yahoo!? | Yahoo! SiteBuilder - Free, easy-to-use web site design software | http://sitebuilder.yahoo.com | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

linker errors
by A.P. Rao 04 Aug '03

04 Aug '03

Hi, I am getting an "undefined reference" error listed below when I try to build my program. I am able to successfully compile and link a trivial "Hello World" program, but not my application code. I tried 3 different versions of ghc (5.04.3, 6.0 and 6.0.1) on my redhat-9 linux pc. The gcc compiler is at version 3.2.2 (gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)). I even tried the ghc 6.0.1 compiler built on my own pc. The result is the same. Error: -------------------- AsnParser.o(.text+0x21139): In function `r2CD0_entry': : undefined reference to `DataziTuple_Z73T_con_info' collect2: ld returned 1 exit status -------------------- Any suggestions as to what may be causing this and how I can get rid of it. To me, it looks like a code-generation bug on ghc's side. Thanks, A.P. Rao __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Profiling Optimised Code
by Ashley Yakeley 03 Aug '03

03 Aug '03

The profiling report from my program compiled with GHC 6.0 with -O -fvia-C on Mac OS X isn't making a lot of sense. The line with the most time, 30.1%, has an entry count of zero, as do most of them: exprLetMap Org.Org.Semantic.HScheme.Interpret.LambdaExpression 1939 0 0.3 0.0 30.3 0.0 liftF2 Org.Org.Semantic.HBase.Category.Functor 1940 0 0.0 0.0 30.1 0.0 liftF1 Org.Org.Semantic.HBase.Category.Functor 1941 0 30.1 0.0 30.1 0.0 It's also a fairly unlikely candidate for time consumption. liftF1 is defined as simply equal to fmap, which presumably doesn't have a cost-centre because it's defined in the standard libraries. But the instance of fmap that it calls is fairly trivial. Am I misinterpreting the report, or would I be better off profiling a unoptimised program to see where the slow bits are in that? I have successfully improved code based on reports from unoptimised programs from GHC 5.*, since those reports made much more sense. -- Ashley Yakeley, Seattle WA

1 0

RE: Strange Building problem...
by Simon Marlow 01 Aug '03

01 Aug '03

> On Fri, 1 Aug 2003 12:51:21 +0100, you wrote: > >> > >> It is not empty and the entries look reasonable. > >> > - Is there a discrepancy between leading underscores on the > >> > symbols in libHSbase.a and the missing symbols? > >> No; neither have any leading underscores. > >Can you compile a small "hello world"-type program using > >ghc/compiler/stage1/ghc-inplace? > > $ more hello.hs > main = print "Hello world!" > $ ./ghc-inplace hello.hs > hello.o(.text+0x28): In function 'rE8_srt': undefined reference to > 'GHCziShow_zdfShowChar_closure" Perhaps this is a gcc-3.3 problem. I notice that you're compiling ghc 6.0 rather than 6.0.1, and 6.0 had some problems with gcc 3.3. Could you try compiling 6.0.1 instead, and see if that helps? Cheers, Simon

1 0

RE: Strange Building problem...
by Simon Marlow 01 Aug '03

01 Aug '03

> >> It's a lower-case 'c'. Sorry - I typed it out by hand as > the build is > >> on a different machine. > > > >Could you check the following things: > > - ghc/driver/package.conf: is it empty? Does it contain > > reasonable-looking package entries? > > It is not empty and the entries look reasonable. > > > - Is there a discrepancy between leading underscores on the > > symbols in libHSbase.a and the missing symbols? > > No; neither have any leading underscores. Can you compile a small "hello world"-type program using ghc/compiler/stage1/ghc-inplace? Cheers, Simon

2 1

RE: Strange Building problem...
by Simon Marlow 01 Aug '03

01 Aug '03

> On Thu, 31 Jul 2003 13:57:02 +0100, you wrote: > >> What is odd is that ghc-inplace is invoked by the make > process several > >> times before this big one (which appears to be the start > of stage 2?) > >> and works fine... > >Do the errors really refer to "GHCziBase_True_Closure", or is it > >"GHCziBase_True_closure"? (with lower-case 'c')? > > It's a lower-case 'c'. Sorry - I typed it out by hand as the build is > on a different machine. Could you check the following things: - ghc/driver/package.conf: is it empty? Does it contain reasonable-looking package entries? - Is there a discrepancy between leading underscores on the symbols in libHSbase.a and the missing symbols? Cheers, SImon

2 1