- Glasgow-haskell-users

Scoped type variables
by Simon Peyton-Jones 20 Dec '04

20 Dec '04

OK, OK, I yield! This message is about lexically scoped type variables. I've gradually become convinced that if you write f :: [a] -> [a] f x = <body> then the type variable 'a' should be in scope in <body>. At present in GHC you have to write f (x :: [a]) = <body> to bring 'a' into scope. I've fought against this because it seems funny for a 'forall' in a type signature to bring a type variable into scope in perhaps-distant function body, but it's just so convenient and "natural". Furthermore, as Martin Sulzmann points out, you might have type variables that are mentioned only in the context of the type: g :: Foo a b => [a] -> [a] g = ... GHC provides no way to bring 'b' into scope at the moment, and that seems bad design. If I do this, which I'm inclined to, it could break some programs, because (with -fglasgow-exts) all type signatures will bring scoped type variables into scope in their function body. Here's an example that will break f :: [a] -> [a] f x = my_id x where my_id :: a -> a my_id y = y The type signature for my_id will become monomorphic, since 'a' is now in scope, so the application (my_id x) will fail saying can't unify 'a' with '[a]'. In some ways that makes sense. If you used 'b' instead in the defn of my_id, it'd be fine, because my_id would get the type (forall b. b->b). Fixing such breakages is easy. So there it is. Any one have strong opinions? (This is in addition to the existing mechanism for bringing scoped type variables into scope via pattern type signatures, of course.) Simon

7 6

Porting to NetBSD Alpha (alpha-unknown-netbsd)
by Svend Sorensen 20 Dec '04

20 Dec '04

I am working on porting ghc-6.2.2 to NetBSD Alpha according to the porting instructions (10.2. Porting GHC to a new architecture) in the Building Guide. The target system is NetBSD 1.6.2 (STABLE) alpha, and the host system is a Red Hat 9.0 i386 system with the ghc-6.2.2 base and profiling RPMs installed. All example diff files, hc tarball, etc. (see ...) are at http://sorensen.freeshell.org/ghc/ for now. Target System I added alpha-unknown-netbsd to T/configure.ac (see configure.ac.diff) and ran autoreconf. The instructions 'make config.h' didn't work with NetBSD's make; gmake was required. I then copied the config.h (see config.h) to the host system. Host System While running make in H/libraries, I ran into the "cc1: Invalid option `ieee'" discussed on the mailing list: http://www.haskell.org//pipermail/glasgow-haskell-users/2003-September/0056… I used Ian's suggested mk/boilerplate.mk fix: http://www.haskell.org//pipermail/glasgow-haskell-users/2003-September/0056… This fixed most of the errors, but 'ar' still ran a few times, causing an error. Running 'make AR=/bin/true LD=/bin/true' fixed these (I was unable to track down where these problematic make lines were). I then build the hc file tarball (see ghc-6.2.2-alpha-unknown-netbsd-hc.tar.gz). This tarball contains 501 files, including 450 .hc files. Target System 2 I unpacked the tarball on the target system, and ran the hc-build script. The first problem I ran into was the readline headers not being found. Setting 'ReadlineIncludePath=/usr/pkg/include' in the mk/config.mk.in (see config.mk.in.diff) fixed this error. The second problem I ran into was with the ieee_set_fp_control() function in ghc/rts/Signals.c. This function isn't available in NetBSD alpha (or FreeBSD alpha I believe, not sure about OSF), only Linux alpha. I simply commented out the reference to the function (see Signals.c.diff), but the file should be modified to check the OS. The hc-build script then sucessfully went through the first "building compiler" stage. After that, in the "building libraries" stage, when it reruns configure, it stalls when detecting the ghc version. The ghc-inplace compiler freezes when run. That is where I am at now. Does anyone have any clue why the inplace compiler freezes, even when run with --version, and must be killed?

2 1

RE: Scoped type variables
by Simon Peyton-Jones 20 Dec '04

20 Dec '04

| Some design choices are unclear, at least to me. First, the | separation of body and signature. I am used to locally introduced | identifiers being visible locally too (i.e. requiring minimal | scrolling through a file). This would break, meaning that I have to | know which identifier was used in the signature. Related to this, how | does this work out for signatures of class members and their | instances, often separated over different files? A change in a type | variable in a signature in a class inside a library might then break | my instance of that class. Or is this mechanism only meant for let | bound values? My intention was that in an instance declaration, only the type variables introduced in the head of the declaration (instance Eq a => Eq [a] where...) would scope over the bodies. The class declaration would be irrelevant. | The following then also might be admitted: | | f :: (forall a . a -> a) -> ... | v = f (\x -> x::a) I'm suggesting *only* the outermost forall'd variables of the definition. That's bad enough! Nesting is overkill, and the scoping rules would be complex to describe. | Second, for a duplicate introduction of 'a' in: | | f :: [a] -> [a] | f (x::a) = <body> | | Is the 'a' introduced in 'f (x::a)' shadowing the 'a' introduced in | 'f :: [a] -> [a]'? If so, the separation of body and signature is | slightly less of a problem because the 'a' introduced in the pattern | will not create a 'duplicate identifier introduction' error message | or a type mismatch (here between [a] and a). The rule today in GHC is that a second use of a scoped type variable is an *occurrence*. Thus f = \(x::a) -> \(y::a) -> .. the first 'a' binds the a, the second is an occurrence of it. Yes, it's a hack. One could imagine requiring different syntax for the binding occurrences, for example, but it's a really convenient one, and hasn't given rise to difficulties that I know of. So I'm proposing to stick with it. Simon

1 0

RE: Error building GHC: can't locate import `Package'
by Simon Peyton-Jones 20 Dec '04

20 Dec '04

I think it's just that you have an old file ParsePkgConfLite.hs in your directory. The make system finds it and tries to compile it. Easiest fix: remove the whole of ghc/utils/ghc-pkg, and do cvs update. S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Peter Simons | Sent: 18 December 2004 16:10 | To: glasgow-haskell-users(a)haskell.org | Subject: Error building GHC: can't locate import `Package' | | When building the current CVS HEAD with ghc-6.2.2 on | Linux/x86, I get this error: | | [...] | ==fptools== make boot - --no-print-directory -r; | in /usr/local/src/ghc-current/ghc/utils/ghc-pkg | -------------------------------------------------------------------- | Creating Version.hs ... | ghc-6.2.2 -M -optdep-f -optdep.depend -osuf o | -optdep--exclude-module=Compat.RawSystem | -optdep--exclude-module=Compat.Directory | -optdep--exclude-module=Distribution.Compat.Error | -optdep--exclude-module=Distribution.Compat.ReadP | -optdep--exclude-module=Distribution.Extension | -optdep--exclude-module=Distribution.InstalledPackageInfo | -optdep--exclude-module=Distribution.License | -optdep--exclude-module=Distribution.Package | -optdep--exclude-module=Distribution.ParseUtils | -optdep--exclude-module=Distribution.Setup | -optdep--exclude-module=Distribution.Version | -optdep--exclude-module=System.FilePath -H16m -O | -optc-nopie -optc-fno-stack-protector-all | -optc-fno-stack-protector -cpp -Wall | -fno-warn-name-shadowing -fno-warn-unused-matches | -i../../lib/compat Main.hs ParsePkgConfLite.hs Version.hs | ParsePkgConfLite.hs: can't locate import `Package' | | It seems that ParsePkgConfLite.hs omits the "Distribution" | part when importing Distribution.Package. | | Peter | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Scoped type variables
by Simon Peyton-Jones 20 Dec '04

20 Dec '04

| Would it help to stick the quantifier at the beginning of | the type declaration? | | > forall a b . g :: Foo a b => [a] -> [a] | > g = ... Since GHC already allows explicit quantifiers, I had indeed wondered about saying that a type sig only brings type variables into scope if it has an explicit quantifier. Thus g :: forall a b. Foo a b => [a] -> [a] g = ... would bring a & b into scope in the "...", but g :: Foo a b => [a] -> [a] g = ... would not. I guess that has the merit that adding the feature would break fewer programs. I'm not keen on putting the foralls before the function name. Simon

1 0

DoCon-2.08 announcement
by Serge D. Mechveliani 20 Dec '04

20 Dec '04

Announcement ------------ A Computer Algebra program DoCon-2.08 is released: http://www.botik.ru/~mechvel/ click at docon-2.08 (Russian site), ftp.botik.ru/pub/local/Mechveliani/docon/ (same), http://www.haskell.org/docon/distrib/ (USA site) DoCon-2.08 is a library of Haskell functions and data structures. It is written in an extension of Haskell-98 including multiparametric classes, overlapping instances and `undecidable' instances. It was tested under the Glasgow Haskell system of 6.2.2, under Linux. The main differences to the previous release of 2.06 are: * it is ported to a more recent system ghc-6.2.2, the Manual is revised slightly, * it includes some support for non-commutative polynomials over a commutative ring, * several bugs are fixed. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Loading package ghc within GHCi
by Sean Seefried 19 Dec '04

19 Dec '04

Hi Simon (and others), I've just managed to build package ghc and have managed to successfully use it in a test program of mine. However, I can't seem to load it into GHCi. The error I'm obtaining is: GHCi runtime linker: fatal error: I found a duplicate definition for symbol _OutOfHeapHook whilst processing object file /usr/local/lib/ghc-6.3/HSghc.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. I see that these symbol is exported by HSrts.o and HSghc.o so it makes sense that this error should occur. But since the symbol in HSghc.o originally comes from ghc/parser/hschooks.c and its purpose is to override the hooks in the RTS it seems strange that this should be an error. Is there any way that I can suppress this error through use of flags in the package.conf for package ghc? I've been told that their may be other good reasons why package ghc doesn't load into GHCi by Don Stewart. What are these reasons exactly? My final question is, if GHCi can't load package ghc just yet then what are the major issues that would need to be solved before it could? Cheers, Sean

1 0

Re: Scoped type variables
by Atze Dijkstra 19 Dec '04

19 Dec '04

At 17:51 +0000 17/12/2004, Simon Peyton-Jones wrote: >OK, OK, I yield! > >This message is about lexically scoped type variables. I've gradually >become convinced that if you write > > f :: [a] -> [a] > f x = <body> > >then the type variable 'a' should be in scope in <body>. At present in >GHC you have to write > f (x :: [a]) = <body> >to bring 'a' into scope. > >I've fought against this because it seems funny for a 'forall' in a type >signature to bring a type variable into scope in perhaps-distant >function body, but it's just so convenient and "natural". Furthermore, >as Martin Sulzmann points out, you might have type variables that are >mentioned only in the context of the type: > g :: Foo a b => [a] -> [a] > g = ... >GHC provides no way to bring 'b' into scope at the moment, and that >seems bad design. Some design choices are unclear, at least to me. First, the separation of body and signature. I am used to locally introduced identifiers being visible locally too (i.e. requiring minimal scrolling through a file). This would break, meaning that I have to know which identifier was used in the signature. Related to this, how does this work out for signatures of class members and their instances, often separated over different files? A change in a type variable in a signature in a class inside a library might then break my instance of that class. Or is this mechanism only meant for let bound values? If not, and if taken to the other extreme, a type variable identifier may well become part of the type itself and its 'meaning'. That is, given a type signature and a value definition complying with the signature always has the type variables available. The following then also might be admitted: f :: (forall a . a -> a) -> ... v = f (\x -> x::a) Second, for a duplicate introduction of 'a' in: f :: [a] -> [a] f (x::a) = <body> Is the 'a' introduced in 'f (x::a)' shadowing the 'a' introduced in 'f :: [a] -> [a]'? If so, the separation of body and signature is slightly less of a problem because the 'a' introduced in the pattern will not create a 'duplicate identifier introduction' error message or a type mismatch (here between [a] and a). From a purist point of view I prefer to avoid spreading local information globally because we humans can cater with large programs only because we keep things local. From a pragmatic point of view as a Haskell user the feature seems to be a convenient one indeed. From a pragmatic point of view as a Haskell implementor I obviously still have questions. cheers, -- - Atze - Atze Dijkstra, Institute of Information & Computing Sciences, /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands / | \ Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze /--| \ Fax : +31-30-2513971 | Email: atze(a)cs.uu.nl / |___\

1 0

internal error: weird activation record found on stack: 9
by Peter Simons 16 Dec '04

16 Dec '04

Hi, I'm getting this error in my software every now and then: postmaster: internal error: scavenge_stack: weird activation record found on stack: 9 Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ The process runs just fine for several days, and then it crashes with this message out of the sudden. There is no apparent cause. I'm using a fairly recent CVS ghc to compile the program on Linux/x86. Any idea what I can do to help tracking this bug down? Peter

1 0

RE: debian ghci on sparc64
by Simon Marlow 16 Dec '04

16 Dec '04

On 15 December 2004 14:46, William Lee Irwin III wrote: > There seems to be some trouble with the debian ghci on sparc64. I can > dredge up more information if given an idea of what to look for. > > $ ghci > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for > Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package base ... linking ... done. > zsh: 7796 segmentation fault ghci Urk. We need to get a ghci binary linked with -debug and run it under gdb to make progress on this one. Anyone? Cheers, Simon

2 1