January 2006 - Glasgow-haskell-users

RE: Lexically scoped type variables
by Simon Peyton-Jones 23 Jan '06

23 Jan '06

good idea. This'll be in when I commit S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Johannes Waldmann | Sent: 17 January 2006 14:36 | To: Simon Peyton-Jones | Cc: GHC users | Subject: Re: Lexically scoped type variables | | On the syntax of type signatures: I'd like to be able to write e. g. | | do | x :: Int <- randomRIO ( 0, 10 ) | print x | | Currently I have to put ( x :: Int ) in parentheses. Is this necessary? | -- | -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- | ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

New bug tracker: Trac
by Simon Marlow 22 Jan '06

22 Jan '06

Hi Folks, We've been meaning to switch bug trackers for some time, and yesterday I finally got annoyed enough with SourceForge to do something about it. I've imported all our SourceForge tracker data into a new Trac installation: http://cvs.haskell.org/trac/ghc Not only do we get a faster and more flexible bug tracker, but we also get online browsing of the darcs repository (well, for some reason it isn't working right now, but I hope to get it fixed). Also the Trac wiki will be a good place to put the User Guide annotations that we've been talking about. The bug tracker is set up to mail glasgow-haskell-bugs(a)haskell.org with any and all ticket modifications at the moment; if you're on that list, there will probably be an increased volume of mail as we'll be making more use of the bug tracker than before. My feeling is that we don't need to create a new mailing list for this, but by all means speak up if you disagree. The wiki is currently closed because I don't want to have to deal with spam. Use HaWiki for now. Developers with an account on cvs.haskell.org: please add yourselves as users on the Trac, so I can give out permissions to edit tickets. You create a user like this: - log in to cvs.haskell.org - htpasswd /srv/trac/ghc/trac.htpasswd <username> - type your password when prompted - let me know when you've done this Cheers, Simon

8 7

RE: darcs switchover
by Simon Marlow 20 Jan '06

20 Jan '06

On 20 December 2005 16:19, Ross Paterson wrote: > On Tue, Dec 20, 2005 at 03:50:02PM +0000, John Goerzen wrote: >> On 2005-12-19, Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> wrote: >>> Ross Paterson <ross(a)soi.city.ac.uk> writes: >>>> But how about having a separate repository for each library >>>> package? >>> >>> Seconded. >> >> Simon, any thoughts? > > Also, if the library packages are separate, the rest of the stuff in > the libraries directory would be part of GHC's build system (nhc98 > too at the moment, but it sounds like Malcolm will be changing that) > so might as well be part of the ghc repository. The time to mention this would have been a few weeks ago when I proposed the current scheme :-) I think it /would/ actually be nicer to split up the repository into separate packages. However, of the two ways to do this that John mentioned, only the second is practical IMO - that is, generate the repositories from CVS. So it's entirely up to John whether he wants to put the effort in or not. I don't think the current situation is bad - we had planned to split the packages into separate repositories eventually anyway, but we would lose the history at that point. Splitting them now means we keep the history, which is good. Cheers, Simon

7 16

Error in GHC
by Tays Soares 19 Jan '06

19 Jan '06

I'm trying to run the following sequence on ghc 6.4: > ghc -fglasgow-exts --make Main > ghc -o exec Main.o Exemplo1.o But I always get this error message after the second command: /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main': : undefined reference to `__stginit_ZCMain' /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In function `main': : undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status Please, does anybody know what can I do to fix it? Thanks Tays Cristina do Amaral Pales Soares --------------------------------- Yahoo! doce lar. Faça do Yahoo! sua homepage.

2 2

GHC vs. GCC on raw vector addition
by Sven Moritz Hallberg 19 Jan '06

19 Jan '06

Hi List, I'm running GHC and GCC head-to-head on the task of adding a bunch of long IOUArray-Vectors really fast. My machine is a Linux-ppc PowerBook and gets a runtime for the GHC-compiled binary that's about 10x as long as for GCC. Simon M. tells me this should be much better. Here are the precise command lines: $ gcc -O3 -o b-addvec-gcc b-addvec-c.c $ ghc -O2 -fasm --make -o b-addvec-ghc b-addvec-hs.hs $ time ./b-addvec-gcc 100000 elements 1000 real 0m5.130s user 0m4.466s sys 0m0.061s $ time ./b-addvec-ghc 100000 elements 1000 real 0m49.701s user 0m43.466s sys 0m0.586s (compiling with -fvia-C -optc-O3 runs only about 1 second longer) Can somebody shed some light on this? Regards, Sven Moritz

5 11

Lexically scoped type variables
by Simon Peyton-Jones 18 Jan '06

18 Jan '06

Dear GHC users As part of a revision of GHC to make type inference for GADTs simpler and more uniform, I propose to change the way in which lexically- scoped type variables work in GHC. (Indeed, I have done so, and will commit it shortly.) This message explains the new system, highlighting the differences. I'm very interested to know whether you like it or hate it. In the latter case, I'd also like to know whether you also have programs that will be broken by the change. Simon Scoped type variables in GHC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ January 2006 0) Terminology. A *pattern binding* is of the form pat = rhs A *function binding* is of the form f pat1 .. patn = rhs A binding of the formm var = rhs is treated as a (degenerate) *function binding*. A *declaration type signature* is a separate type signature for a let-bound or where-bound variable: f :: Int -> Int A *pattern type signature* is a signature in a pattern: \(x::a) -> x f (x::a) = x A *result type signature* is a signature on the result of a function definition: f :: forall a. [a] -> a head (x:xs) :: a = x The form x :: a = rhs is treated as a (degnerate) function binding with a result type signature, not as a pattern binding. 1) The main invariants: A) A lexically-scoped type variable always names a rigid type variable (not a wobbly one, and not a non-type-variable type). THIS IS A CHANGE. Previously, a scoped type variable named an arbitrary *type*. B) A type signature always describes a rigid type (since its free (scoped) type variables name rigid type variables). This is also a change, a consequence of (A). C) Distinct lexically-scoped type variables name distinct rigid type variables. This choice is open; This means that you cannot say \(x:: [a]) -> <expr> (where 'a' is not yet in scope) to enforce that x is a list without saying anything about 'a'. (Well, not unless the type of this lambda is known from the "outside".) 1a) Possible extension. We might consider allowing \(x :: [ _ ]) -> <expr> where "_" is a wild card, to mean "x has type list of something", without naming the something. 2) Scoping 2(a) If a declaration type signature has an explicit forall, those type variables are brought into scope in the right hand side of the corresponding binding (plus, for function bindings, the patterns on the LHS). f :: forall a. a -> [a] f (x::a) = [x :: a, x] Both occurences of 'a' in the second line are bound by the 'forall a' in the first line A declaration type signature *without* an explicit top-level forall is implicitly quantified over all the type variables that are mentioned in the type but not already in scope. GHC's current rule is that this implicit quantification does *not* bring into scope any new scoped type variables. f :: a -> a f x = ...('a' is not in scope here)... This gives compatibility with Haskell 98 2(b) A pattern type signature implicitly brings into scope any type variables mentioned in the type that are not already into scope. These are called *pattern-bound type variables*. g :: a -> a -> [a] g (x::a) (y::a) = [y :: a, x] The pattern type signature (x::a) brings 'a' into scope. The 'a' in the pattern (y::a) is bound, as is the occurrence on the RHS. A pattern type siganture is the only way you can bring existentials into scope. data T where MkT :: forall a. a -> (a->Int) -> T f x = case x of MkT (x::a) f -> f (x::a) 2a) QUESTION class C a where op :: forall b. b->a->a instance C (T p q) where op = <rhs> Clearly p,q are in scope in <rhs>, but is 'b'? Not at the moment. Nor can you add a type signature for op in the instance decl. You'd have to say this: instance C (T p q) where op = let op' :: forall b. ... op' = <rhs> in op' 3) A pattern-bound type variable is allowed only if the pattern's expected type is rigid. Otherwise we don't know exactly *which* skolem the scoped type variable should be bound to, and that means we can't do GADT refinement. This is invariant (A), and it is a change from the current situation. f (x::a) = x -- NO g1 :: b -> b g1 (x::b) = x -- YES, because the pattern type is rigid g2 :: b -> b g2 (x::c) = x -- YES, same reason h :: forall b. b -> b h (x::b) = x -- YES, but the inner b is bound k :: forall b. b -> b k (x::c) = x -- NO, it can't be both b and c 3a) You *can* give a different name to the same type variable in different disjoint scopes, just as you can (if you want) give diferent names to the same value parameter f :: a -> Bool -> Maybe a f (x::p) True = Just x :: Maybe p f (y::q) False = Nothing :: Maybe q 3b) Scoped type variables respect alpha renaming. For example, function g from 2(b) above could also be written: g2 :: a -> a -> [a] g2 (x::b) (y::b) = [y :: b, x] where the scoped type variable is called 'b' instead of 'a'. However, you cannot write f :: a -> a -> [a] f (x::b) (y::c) = [y :: b, x] because then two scoped type variables ('b' and 'c') would be bound to the same underlying type variable. (Invariant (C) above.) 4) Result type signatures obey the same rules as pattern types signatures. In particular, they can bind a type variable only if the result type is rigid f x :: a = x -- NO g :: b -> b g x :: b = x -- YES; binds b in rhs 5) A *pattern type signature* in a *pattern binding* cannot bind a scoped type variable (x::a, y) = ... -- Legal only if 'a' is already in scope Reason: in type checking, the "expected type" of the LHS pattern is always wobbly, so we can't bind a rigid type variable. (The exception would be for an existential type variable, but existentials are not allowed in pattern bindings either.) Even this is illegal f :: forall a. a -> a f x = let ((y::b)::a, z) = ... in Here it looks as if 'b' might get a rigid binding; but you can't bind it to the same skolem as a. 6) Explicitly-forall'd type variables in the *declaration type signature(s)* for a *pattern binding* do not scope AT ALL. x :: forall a. a->a -- NO; the forall a does Just (x::a->a) = Just id -- not scope at all y :: forall a. a->a Just y = Just (id :: a->a) -- NO; same reason THIS IS A CHANGE, but one I bet that very few people will notice. Here's why: strange :: forall b. (b->b,b->b) strange = (id,id) x1 :: forall a. a->a y1 :: forall b. b->b (x1,y1) = strange This is legal Haskell 98 (modulo the forall). If both 'a' and 'b' both scoped over the RHS, they'd get unified and so cannot stand for distinct type variables. One could *imagine* allowing this: x2 :: forall a. a->a y2 :: forall a. a->a (x2,y2) = strange using the very same type variable 'a' in both signatures, so that a single 'a' scopes over the RHS. That seems defensible, but odd, because though there are two type signatures, they introduce just *one* scoped type variable, a. Implementation notes ~~~~~~~~~~~~~~~~~~~~ 1) This means that dealing with pattern/result type signatures is simple: - if the signature binds one or more variables, and the pattern type is rigid, *match* the signature against the pattern type to bind the variables - if the signature binds no type variables, *unify* the pattern type against the (necessarily rigid) type signature 2) Skolem constants get introduced by a) Declaration type signatures with explicit foralls b) *Function* declaration type signatures on bindings where there is no explicit forall c) Existential pattern matches d) SKOL rule in subsumption checking A *declaration type signature* for a *pattern-bound* variable does not introduce a skolem, and is never the basis for refinement. Instead we use an ordinary meta type variable, and check after the event that everything is still distinct. That is how the x4/y4 example type-checks.

4 3

Linking with C++ produced by Visual Studio .NET on Windows XP?
by Brian Hulley 17 Jan '06

17 Jan '06

Hi - I'm wondering if anyone has a simple Visual Studio .NET C++ project that would demonstrate how to link C++ with Haskell (or vice versa). Ie a .sln, .vcproj, .cpp, and .h file containing one C++ function and a Haskell file main.hs that calls this function, so that if I click on the .sln file and hit F6 the VS project will build then on the command line if I type ghc --make main.hs the Haskell program will be built so that when I type "main" on the command line it will run and call the C++ function. Sorry if this all sounds too basic but I don't know how to compile C++ from the command line at all or how to use make files, and I need to use the Visual Studio compiler because my own C++ code relies on Microsoft extensions... Thanks, Brian.

1 0

RE: cvs commit: fptools/libraries/base/Data IntMap.hs Map.hs Sequence.hs Set.hs fptools/libraries/base/Data/Generics Instances.hs Twins.hs
by Simon Peyton-Jones 17 Jan '06

17 Jan '06

| > Eta-expand some higher-rank functions. GHC is about to | > move to *invariant* rather than *contra-variant* in function | > arguments, so far as type subsumption is concerned. These | > eta-expansions are simple, and allow type inference to | > go through with invariance. | | Why drop contra-variace? See the paper on "Boxy type inference" on my home page. Simon

1 0

GHC.Unicode
by Krasimir Angelov 17 Jan '06

17 Jan '06

Hello Guys, I saw that GHC already has complete support for Unicode character classification. I tend to use it but I saw that currently GHC.Unicode exports only few of all classification routines. Is it intentional? Cheers, Krasimir

2 5

RE: darcs switchover
by Mike Thomas 15 Jan '06

15 Jan '06

Hi Simon. Thanks for all the great work. | Please test, as we'd like to switch over as soon as possible. Have the nightly build scripts moved yet? Cheers Mike Thomas.

1 0