1. 18 Apr, 2006 1 commit
  2. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  3. 06 Apr, 2006 1 commit
  4. 04 Mar, 2006 1 commit
  5. 24 Feb, 2006 1 commit
  6. 25 Jan, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Simon's big boxy-type commit · ac10f840
      simonpj@microsoft.com authored
      This very large commit adds impredicativity to GHC, plus
      numerous other small things.
        
      *** WARNING: I have compiled all the libraries, and
      ***	     a stage-2 compiler, and everything seems
      ***	     fine.  But don't grab this patch if you 
      ***	     can't tolerate a hiccup if something is
      ***	     broken.
        
      The big picture is this:
      
      a) GHC handles impredicative polymorphism, as described in the
         "Boxy types: type inference for higher-rank types and
         impredicativity" paper
      
      b) GHC handles GADTs in the new simplified (and very sligtly less
         epxrssive) way described in the
         "Simple unification-based type inference for GADTs" paper
      
        
      But there are lots of smaller changes, and since it was pre-Darcs
      they are not individually recorded.
        
      Some things to watch out for:
        
      c)   The story on lexically-scoped type variables has changed, as per
           my email.  I append the story below for completeness, but I 
           am still not happy with it, and it may change again.  In particular,
           the new story does not allow a pattern-bound scoped type variable
           to be wobbly, so (\(x::[a]) -> ...) is usually rejected.  This is
           more restrictive than before, and we might loosen up again.
        
      d)   A consequence of adding impredicativity is that GHC is a bit less
           gung ho about converting automatically between
        	(ty1 -> forall a. ty2)    and    (forall a. ty1 -> ty2)
           In particular, you may need to eta-expand some functions to make
           typechecking work again.
         
           Furthermore, functions are now invariant in their argument types,
           rather than being contravariant.  Again, the main consequence is
           that you may occasionally need to eta-expand function arguments when
           using higher-rank polymorphism.
        
      
      Please test, and let me know of any hiccups
      
      
      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 an arbitrary 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; 
      
      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 
         big change from the current situation.
      
      	f (x::a) = x	-- NO; pattern type is wobbly
      	
      	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 cannot give different names for the same type variable in the same scope
          (Invariant (C)):
      
      	f1 :: p -> p -> p		-- NO; because 'a' and 'b' would be
      	f1 (x::a) (y::b) = (x::a)	--     bound to the same type variable
      
      	f2 :: p -> p -> p		-- OK; 'a' is bound to the type variable
      	f2 (x::a) (y::a) = (x::a)	--     over which f2 is quantified
      					-- NB: 'p' is not lexically scoped
      
      	f3 :: forall p. p -> p -> p	-- NO: 'p' is now scoped, and is bound to
      	f3 (x::a) (y::a) = (x::a)	--     to the same type varialble as 'a'
      
      	f4 :: forall p. p -> p -> p	-- OK: 'p' is now scoped, and its occurences
      	f4 (x::p) (y::p) = (x::p)	--     in the patterns are bound by the forall
      
      
      3b) 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
      
      	g :: a -> Bool -> Maybe a
      	g (x::p) True  = Just x  :: Maybe p
      	g (y::q) False = Nothing :: Maybe q
      
      3c) Scoped type variables respect alpha renaming. For example, 
          function f2 from (3a) above could also be written:
      	f2' :: p -> p -> p
      	f2' (x::b) (y::b) = x::b
         where the scoped type variable is called 'b' instead of 'a'.
      
      
      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.
      
      7) 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.
      ac10f840
  7. 02 Nov, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-11-02 09:57:45 by simonpj] · f7e8044f
      simonpj authored
      Correct the TH fix of Oct 26, involving thFAKE
      		MERGE TO STABLE
      
      Original message
        1) A bug in the renaming of [d| brackets |]. The problem was
        that when we renamed the bracket we messed up the name cache, because
        the module was still that of the parent module. Now we set a fake
        module before renaming it.
      
      But we have to tell the *typechecker* too, not just the renamer.
      See comments with TcSplice.tc_bracket (DecBr case).
      
      Should fix TH failures in the STABLE branch
      f7e8044f
  8. 27 Oct, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-10-27 14:35:20 by simonpj] · 958924a2
      simonpj authored
      Add a new pragma: SPECIALISE INLINE
      
      This amounts to adding an INLINE pragma to the specialised version
      of the function.  You can add phase stuff too (SPECIALISE INLINE [2]),
      and NOINLINE instead of INLINE.
      
      The reason for doing this is to support inlining of type-directed
      recursive functions.  The main example is this:
      
        -- non-uniform array type
        data Arr e where
          ArrInt  :: !Int -> ByteArray#       -> Arr Int
          ArrPair :: !Int -> Arr e1 -> Arr e2 -> Arr (e1, e2)
      
        (!:) :: Arr e -> Int -> e
        {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-}
        {-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-}
        ArrInt  _ ba    !: (I# i) = I# (indexIntArray# ba i)
        ArrPair _ a1 a2 !: i      = (a1 !: i, a2 !: i)
      
      If we use (!:) at a particular array type, we want to inline (:!),
      which is recursive, until all the type specialisation is done.
      
      
      On the way I did a bit of renaming and tidying of the way that
      pragmas are carried, so quite a lot of files are touched in a
      fairly trivial way.
      958924a2
  9. 25 Oct, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-10-25 12:48:35 by simonmar] · 78b72ed1
      simonmar authored
      Two changes from Krasimir Angelov, which were required for Visual
      Haskell:
      
        - messaging cleanup throughout the compiler.  DynFlags has a new
          field:
      
          log_action :: Severity -> SrcSpan -> PprStyle -> Message -> IO ()
      
          this action is invoked for every message generated by the
          compiler.  This means a client of the GHC API can direct messages to
          any destination, or collect them up in an IORef for later
          perusal.
      
          This replaces previous hacks to redirect messages in the GHC API
          (hence some changes to function types in GHC.hs).
      
        - The JustTypecheck mode of GHC now does what it says.  It doesn't
          run any of the compiler passes beyond the typechecker for each module,
          but does generate the ModIface in order that further modules can be
          typechecked.
      
      And one change from me:
      
        - implement the LANGUAGE pragma, finally
      78b72ed1
  10. 18 Aug, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-08-18 10:02:54 by simonpj] · 67e7de3d
      simonpj authored
      Make the forkM failure fail more tidily.  Interface-file inconsistencies
      give rise to failures in the IfM monad.  An error message is printed, but
      up to now we've also said "The impossible happened, must be a GHC bug".
      That's not true, though, it could just be messed up interface files.
      
      So this commit still makes the compiler halt, but in a tidier, less
      self-accusatory way.
      
      Still to come: when original names in interface files mention the
      package Id too, the error will become clearer still.
      
      	MERGE to STABLE
      67e7de3d
  11. 19 Jul, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-07-19 16:44:50 by simonpj] · a7ecdf96
      simonpj authored
      WARNING: this is a big commit.  You might want 
      	to wait a few days before updating, in case I've 
      	broken something.
      
      	However, if any of the changes are what you wanted,
      	please check it out and test!
      
      This commit does three main things:
      
      1. A re-organisation of the way that GHC handles bindings in HsSyn.
         This has been a bit of a mess for quite a while.  The key new
         types are
      
      	-- Bindings for a let or where clause
      	data HsLocalBinds id
      	  = HsValBinds (HsValBinds id)
      	  | HsIPBinds  (HsIPBinds id)
      	  | EmptyLocalBinds
      
      	-- Value bindings (not implicit parameters)
      	data HsValBinds id
      	  = ValBindsIn  -- Before typechecking
      		(LHsBinds id) [LSig id]	-- Not dependency analysed
      					-- Recursive by default
      
      	  | ValBindsOut	-- After typechecking
      		[(RecFlag, LHsBinds id)]-- Dependency analysed
      
      2. Implement Mark Jones's idea of increasing polymoprhism
         by using type signatures to cut the strongly-connected components
         of a recursive group.  As a consequence, GHC no longer insists
         on the contexts of the type signatures of a recursive group
         being identical.
      
         This drove a significant change: the renamer no longer does dependency
         analysis.  Instead, it attaches a free-variable set to each binding,
         so that the type checker can do the dep anal.  Reason: the typechecker
         needs to do *two* analyses:
      	one to find the true mutually-recursive groups
      		(which we need so we can build the right CoreSyn)
      	one to find the groups in which to typecheck, taking
      		account of type signatures
      
      3. Implement non-ground SPECIALISE pragmas, as promised, and as
         requested by Remi and Ross.  Certainly, this should fix the 
         current problem with GHC, namely that if you have
      	g :: Eq a => a -> b -> b
         then you can now specialise thus
      	SPECIALISE g :: Int -> b -> b
          (This didn't use to work.)
      
         However, it goes further than that.  For example:
      	f :: (Eq a, Ix b) => a -> b -> b
         then you can make a partial specialisation
      	SPECIALISE f :: (Eq a) => a -> Int -> Int
      
          In principle, you can specialise f to *any* type that is
          "less polymorphic" (in the sense of subsumption) than f's 
          actual type.  Such as
      	SPECIALISE f :: Eq a => [a] -> Int -> Int
          But I haven't tested that.
      
          I implemented this by doing the specialisation in the typechecker
          and desugarer, rather than leaving around the strange SpecPragmaIds,
          for the specialiser to find.  Indeed, SpecPragmaIds have vanished 
          altogether (hooray).
      
          Pragmas in general are handled more tidily.  There's a new
          data type HsBinds.Prag, which lives in an AbsBinds, and carries
          pragma info from the typechecker to the desugarer.
      
      
      Smaller things
      
      - The loop in the renamer goes via RnExpr, instead of RnSource.
        (That makes it more like the type checker.)
      
      - I fixed the thing that was causing 'check_tc' warnings to be 
        emitted.
      a7ecdf96
  12. 21 Jun, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-06-21 10:44:37 by simonmar] · 0c53bd0e
      simonmar authored
      Relax the restrictions on conflicting packages.  This should address
      many of the traps that people have been falling into with the current
      package story.
      
      Now, a local module can shadow a module in an exposed package, as long
      as the package is not otherwise required by the program.  GHC checks
      for conflicts when it knows the dependencies of the module being
      compiled.
      
      Also, we now check for module conflicts in exposed packages only when
      importing a module: if an import can be satisfied from multiple
      packages, that's an error.  It's not possible to prevent GHC from
      starting by installing packages now (unless you install another base
      package).
      
      It seems to be possible to confuse GHCi by having a local module
      shadowing a package module that goes away and comes back again.  I
      think it's nearly right, but strange happenings have been observed.
      
      I'll try to merge this into the STABLE branch.
      0c53bd0e
  13. 15 Jun, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-06-15 12:03:19 by simonmar] · e6de0678
      simonmar authored
      Re-implement GHCi's :info and :browse commands in terms of TyThings
      rather than IfaceSyn.
      
      The GHC API now exposes its internal types for Haskell entities:
      TyCons, Classes, DataCons, Ids and Instances (collectively known as
      TyThings), so we can inspect these directly to pretty-print
      information about an entity.  Previously the internal representations
      were converted to IfaceSyn for passing to InteractiveUI, but we can
      now remove that code.
      
      Some of the new code comes via Visual Haskell, but I've changed it
      around a lot to fix various dark corners and properly print things
      like GADTs.
      
      The pretty-printing interfaces for TyThings are exposed by a new
      module PprTyThing, which is implemented purely in terms of the GHC API
      (and is probably a good source of sample code).  Visual Haskell should
      be able to use the functions exported by this module directly.
      
      Lots of new goodies are exported by the GHC module, mainly for
      inspecting TyThings.
      e6de0678
  14. 10 Jun, 2005 1 commit
  15. 20 May, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-05-20 11:42:57 by simonpj] · 02a06a56
      simonpj authored
      Improve the GHCi interaction
      
      		Merge to STABLE?
      
      This fix addresses Sourceforge #1156554 "GHCi: No instance for (Show (IO ()))",
      and simultaneously improves the top-level interaction in two other ways:
      
      - Only one error can show up (previously there could be two)
      
      - If an I/O action gives a Showable result, the result is printed
        (provided it isn't ()).  So
      	prompt> return 4
        prints 4, rather than nothing
      
      - For command-line 'let' and 'x<-e' forms, if exactly one variable
        is bound, we print its value if it is Showable and not ()
      	prompt> let x = 4
      	4
      	prompt> x <- return 5
      	5
      02a06a56
  16. 05 May, 2005 1 commit
  17. 04 May, 2005 1 commit
    • ross's avatar
      [project @ 2005-05-04 10:28:07 by ross] · 00007e64
      ross authored
      Another go at the handling of -< in arrow notation, continuing and
      fixing the changes in
      
      	http://www.haskell.org/pipermail/cvs-all/2005-April/040391.html
      
      Now do the same thing in the renamer as we do in the type checker,
      i.e. return to the environment of the proc when considering the left
      argument of -<.
      
      This is much simpler than the old proc_level stuff, and matches the
      type rules more clearly.  But there is a change in error messages.
      For the input
      
      	f :: Int -> Int
      	f = proc x -> (+x) -< 1
      
      GHC 6.4 says
      
      	test.hs:6:
      	    Command-bound variable `x' is not in scope here
      		Reason: it is used in the left argument of (-<)
      	    In the second argument of `(+)', namely `x'
      	    In the command: (+ x) -< 1
      	    In the definition of `f': f = proc x -> (+ x) -< 1
      
      but now we just get the blunt
      
      	test.hs:6:16: Not in scope: `x'
      
      The beauty is all on the inside.
      
      Similarly leakage of existential type variables (arrow1) is detected,
      but the error message isn't very helpful.
      00007e64
  18. 28 Apr, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-04-28 10:09:41 by simonpj] · dd313897
      simonpj authored
      This big commit does several things at once (aeroplane hacking)
      which change the format of interface files.  
      
      	So you'll need to recompile your libraries!
      
      1. The "stupid theta" of a newtype declaration
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Retain the "stupid theta" in a newtype declaration.
      For some reason this was being discarded, and putting it
      back in meant changing TyCon and IfaceSyn slightly.
         
      
      2. Overlap flags travel with the instance
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Arrange that the ability to support overlap and incoherence
      is a property of the *instance declaration* rather than the
      module that imports the instance decl.  This allows a library
      writer to define overlapping instance decls without the
      library client having to know.  
      
      The implementation is that in an Instance we store the
      overlap flag, and preseve that across interface files
      
      
      3. Nuke the "instnce pool" and "rule pool"
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      A major tidy-up and simplification of the way that instances
      and rules are sucked in from interface files.  Up till now
      an instance decl has been held in a "pool" until its "gates" 
      (a set of Names) are in play, when the instance is typechecked
      and added to the InstEnv in the ExternalPackageState.  
      This is complicated and error-prone; it's easy to suck in 
      too few (and miss an instance) or too many (and thereby be
      forced to suck in its type constructors, etc).
      
      Now, as we load an instance from an interface files, we 
      put it straight in the InstEnv... but the Instance we put in
      the InstEnv has some Names (the "rough-match" names) that 
      can be used on lookup to say "this Instance can't match".
      The detailed dfun is only read lazily, and the rough-match
      thing meansn it is'nt poked on until it has a chance of
      being needed.
      
      This simply continues the successful idea for Ids, whereby
      they are loaded straightaway into the TypeEnv, but their
      TyThing is a lazy thunk, not poked on until the thing is looked
      up.
      
      Just the same idea applies to Rules.
      
      On the way, I made CoreRule and Instance into full-blown records
      with lots of info, with the same kind of key status as TyCon or 
      DataCon or Class.  And got rid of IdCoreRule altogether.   
      It's all much more solid and uniform, but it meant touching
      a *lot* of modules.
      
      
      4. Allow instance decls in hs-boot files
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Allowing instance decls in hs-boot files is jolly useful, becuase
      in a big mutually-recursive bunch of data types, you want to give
      the instances with the data type declarations.  To achieve this
      
      * The hs-boot file makes a provisional name for the dict-fun, something
        like $fx9.
      
      * When checking the "mother module", we check that the instance
        declarations line up (by type) and generate bindings for the 
        boot dfuns, such as
      	$fx9 = $f2
        where $f2 is the dfun generated by the mother module
      
      * In doing this I decided that it's cleaner to have DFunIds get their
        final External Name at birth.  To do that they need a stable OccName,
        so I have an integer-valued dfun-name-supply in the TcM monad.
        That keeps it simple.
      
      This feature is hardly tested yet.
      
      
      5. Tidy up tidying, and Iface file generation
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      main/TidyPgm now has two entry points:
      
        simpleTidyPgm is for hi-boot files, when typechecking only
        (not yet implemented), and potentially when compiling without -O.
        It ignores the bindings, and generates a nice small TypeEnv.
      
        optTidyPgm is the normal case: compiling with -O.  It generates a
        TypeEnv rich in IdInfo
      
      MkIface.mkIface now only generates a ModIface.  A separate
      procedure, MkIface.writeIfaceFile, writes the file out to disk.
      dd313897
  19. 27 Apr, 2005 1 commit
  20. 16 Apr, 2005 2 commits
    • simonpj's avatar
      [project @ 2005-04-16 22:47:23 by simonpj] · 9d2575d7
      simonpj authored
      Significant clean-up of the handling of hi-boot files. 
      Previously, when compling A.hs, we loaded A.hi-boot, and
      it went into the External Package Table.  It was strange
      but it worked.  This tidy up stops it going anywhere;
      it's just read in, and typechecked into a ModDetails.
      
      All this was on the way to improving the handling of
      instances in hs-boot files, something Chris Ryder wanted.
      I think they work quite sensibly now.  
      
      If I've got all this right (have not had a chance to
      fully test it) we can merge it into STABLE.
      9d2575d7
    • ross's avatar
      [project @ 2005-04-16 16:05:52 by ross] · 872f7e82
      ross authored
      Rejig handling of environments in arrow notation: instead of the
      proc_level stuff, we just record the environment of the proc, and
      use that on the left side of -< and the head of (|...|).
      
      This also makes the arrow1 test yield a compile error, as it should,
      but the error message is uninformative.
      872f7e82
  21. 31 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-31 10:16:33 by simonmar] · 853e20a3
      simonmar authored
      Tweaks to get the GHC sources through Haddock.  Doesn't quite work
      yet, because Haddock complains about the recursive modules.  Haddock
      needs to understand SOURCE imports (it can probably just ignore them
      as a first attempt).
      853e20a3
  22. 18 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-18 13:37:27 by simonmar] · d1c1b7d0
      simonmar authored
      Flags cleanup.
      
      Basically the purpose of this commit is to move more of the compiler's
      global state into DynFlags, which is moving in the direction we need
      to go for the GHC API which can have multiple active sessions
      supported by a single GHC instance.
      
      Before:
      
      $ grep 'global_var' */*hs | wc -l
           78
      
      After:
      
      $ grep 'global_var' */*hs | wc -l
           27
      
      Well, it's an improvement.  Most of what's left won't really affect
      our ability to host multiple sessions.
      
      Lots of static flags have become dynamic flags (yay!).  Notably lots
      of flags that we used to think of as "driver" flags, like -I and -L,
      are now dynamic.  The most notable static flags left behind are the
      "way" flags, eg. -prof.  It would be nice to fix this, but it isn't
      urgent.
      
      On the way, lots of cleanup has happened.  Everything related to
      static and dynamic flags lives in StaticFlags and DynFlags
      respectively, and they share a common command-line parser library in
      CmdLineParser.  The flags related to modes (--makde, --interactive
      etc.) are now private to the front end: in fact private to Main
      itself, for now.
      d1c1b7d0
  23. 15 Mar, 2005 1 commit
    • ross's avatar
      [project @ 2005-03-15 11:59:32 by ross] · 1dfb756e
      ross authored
      Fix (and test) for SourceForge bug 1161624: erroneous rejection of
      
      	foo = proc x -> arr (\y -> y-1) -< x
      
      Now open a new level for the left side of -<, so that variables bound
      in the proc are illegal, but variables bound in the expression are OK.
      
      Note that the levels gimmick doesn't really implement holes in the
      scope: it rules out nasty obfuscations like
      
      	foo x = proc x -> arr (\y -> x-1) -< x
      
      Also added the same treatment to the head of a `form', where it was
      missing.
      
      (for STABLE)
      1dfb756e
  24. 27 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-27 10:44:00 by simonpj] · 508a505e
      simonpj authored
      --------------------------------------------
                Replace hi-boot files with hs-boot files
        	--------------------------------------------
      
      This major commit completely re-organises the way that recursive modules
      are dealt with.
      
        * It should have NO EFFECT if you do not use recursive modules
      
        * It is a BREAKING CHANGE if you do
      
      ====== Warning: .hi-file format has changed, so if you are
      ======		updating into an existing HEAD build, you'll
      ======		need to make clean and re-make
      
      
      The details:  [documentation still to be done]
      
      * Recursive loops are now broken with Foo.hs-boot (or Foo.lhs-boot),
        not Foo.hi-boot
      
      * An hs-boot files is a proper source file.  It is compiled just like
        a regular Haskell source file:
      	ghc Foo.hs		generates Foo.hi, Foo.o
      	ghc Foo.hs-boot		generates Foo.hi-boot, Foo.o-boot
      
      * hs-boot files are precisely a subset of Haskell. In particular:
      	- they have the same import, export, and scoping rules
      	- errors (such as kind errors) in hs-boot files are checked
        You do *not* need to mention the "original" name of something in
        an hs-boot file, any more than you do in any other Haskell module.
      
      * The Foo.hi-boot file generated by compiling Foo.hs-boot is a machine-
        generated interface file, in precisely the same format as Foo.hi
      
      * When compiling Foo.hs, its exports are checked for compatibility with
        Foo.hi-boot (previously generated by compiling Foo.hs-boot)
      
      * The dependency analyser (ghc -M) knows about Foo.hs-boot files, and
        generates appropriate dependencies.  For regular source files it
        generates
      	Foo.o : Foo.hs
      	Foo.o : Baz.hi		-- Foo.hs imports Baz
      	Foo.o : Bog.hi-boot	-- Foo.hs source-imports Bog
      
        For a hs-boot file it generates similar dependencies
      	Bog.o-boot : Bog.hs-boot
      	Bog.o-boot : Nib.hi	-- Bog.hs-boto imports Nib
      
      * ghc -M is also enhanced to use the compilation manager dependency
        chasing, so that
      	ghc -M Main
        will usually do the job.  No need to enumerate all the source files.
      
      * The -c flag is no longer a "compiler mode". It simply means "omit the
        link step", and synonymous with -no-link.
      508a505e
  25. 18 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-18 12:18:11 by simonpj] · ac80e0de
      simonpj authored
      ------------------------
          Reorganisation of hi-boot files
        	------------------------
      
      The main point of this commit is to arrange that in the Compilation
      Manager's dependendency graph, hi-boot files are proper nodes. This
      is important to make sure that we compile everything in the right
      order.  It's a step towards hs-boot files.
      
      * The fundamental change is that CompManager.ModSummary has a new
        field, ms_boot :: IsBootInterface
      
        I also tided up CompManager a bit.  No change to the Basic Plan.
      
        ModSummary is now exported abstractly from CompManager (was concrete)
      
      * Hi-boot files now have import declarations.  The idea is they are
        compulsory, so that the dependency analyser can find them
      
      * I changed an invariant: the Compilation Manager used to ensure that
        hscMain was given a HomePackageTable only for the modules 'below' the
        one being compiled.  This was really only important for instances and
        rules, and it was a bit inconvenient.  So I moved the filter to the
        compiler itself: see HscTypes.hptInstances and hptRules.
      
      * Module Packages.hs now defines
          data PackageIdH
          = HomePackage 		-- The "home" package is the package
       				-- curently being compiled
          | ExtPackage PackageId	-- An "external" package is any other package
      
         It was just a Maybe type before, so this makes it a bit clearer.
      
      * I tried to add a bit better location info to the IfM monad, so that
        errors in interfaces come with a slightly more helpful error message.
        See the if_loc field in TcRnTypes --- and follow-on consequences
      
      * Changed Either to Maybes.MaybeErr in a couple of places (more perspicuous)
      ac80e0de
  26. 22 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-22 16:58:34 by simonpj] · 20e39e0e
      simonpj authored
      ----------------------------------------
      	     Add more scoped type variables
      	----------------------------------------
      
      Now the top-level forall'd variables of a type signature scope
      over the right hand side of that function.
      
      	f :: a -> a
      	f x = ....
      
      The type variable 'a' is in scope in the RHS, and in f's patterns.
      
      It's implied by -fglasgow-exts, but can also be switched off independently
      using -fscoped-type-variables (and the -fno variant)
      20e39e0e
  27. 29 Nov, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-11-29 16:25:03 by simonpj] · b3fe66bb
      simonpj authored
      ---------------------
      	Simplify ImportAvails
      	---------------------
      
      Every Name has, for some while, contained its "parent";
      the type or class inside which it is defined.  But the rest
      of the renamer wasn't using this information as much as it 
      could do.  In particular, the ImportAvails type was more elaborate
      than necessary.
      
      This commit combines these two fields of ImportAvails:
      	imp_env :: AvailEnv
      	imp_qual :: ModuleEnv AvailEnv
      into one
      	imp_env :: ModuleEnv NameSet 
      
      This is quite a bit simpler.  Less redundancy and, I think, less
      code.
      b3fe66bb
  28. 26 Nov, 2004 1 commit
    • simonmar's avatar
      [project @ 2004-11-26 16:19:45 by simonmar] · ef5b4b14
      simonmar authored
      Further integration with the new package story.  GHC now supports
      pretty much everything in the package proposal.
      
        - GHC now works in terms of PackageIds (<pkg>-<version>) rather than
          just package names.  You can still specify package names without
          versions on the command line, as long as the name is unambiguous.
      
        - GHC understands hidden/exposed modules in a package, and will refuse
          to import a hidden module.  Also, the hidden/eposed status of packages
          is taken into account.
      
        - I had to remove the old package syntax from ghc-pkg, backwards
          compatibility isn't really practical.
      
        - All the package.conf.in files have been rewritten in the new syntax,
          and contain a complete list of modules in the package.  I've set all
          the versions to 1.0 for now - please check your package(s) and fix the
          version number & other info appropriately.
      
        - New options:
      
      	-hide-package P    sets the expose flag on package P to False
      	-ignore-package P  unregisters P for this compilation
      
      	For comparison, -package P sets the expose flag on package P
              to True, and also causes P to be linked in eagerly.
      
              -package-name is no longer officially supported.  Unofficially, it's
      	a synonym for -ignore-package, which has more or less the same effect
      	as -package-name used to.
      
      	Note that a package may be hidden and yet still be linked into
      	the program, by virtue of being a dependency of some other package.
      	To completely remove a package from the compiler's internal database,
              use -ignore-package.
      
      	The compiler will complain if any two packages in the
              transitive closure of exposed packages contain the same
              module.
      
      	You *must* use -ignore-package P when compiling modules for
              package P, if package P (or an older version of P) is already
              registered.  The compiler will helpfully complain if you don't.
      	The fptools build system does this.
      
         - Note: the Cabal library won't work yet.  It still thinks GHC uses
           the old package config syntax.
      
      Internal changes/cleanups:
      
         - The ModuleName type has gone away.  Modules are now just (a
           newtype of) FastStrings, and don't contain any package information.
           All the package-related knowledge is in DynFlags, which is passed
           down to where it is needed.
      
         - DynFlags manipulation has been cleaned up somewhat: there are no
           global variables holding DynFlags any more, instead the DynFlags
           are passed around properly.
      
         - There are a few less global variables in GHC.  Lots more are
           scheduled for removal.
      
         - -i is now a dynamic flag, as are all the package-related flags (but
           using them in {-# OPTIONS #-} is Officially Not Recommended).
      
         - make -j now appears to work under fptools/libraries/.  Probably
           wouldn't take much to get it working for a whole build.
      ef5b4b14
  29. 25 Nov, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-11-25 11:36:34 by simonpj] · 1f7da302
      simonpj authored
      ------------------------------------------
      	Keep-alive set and Template Haskell quotes
      	------------------------------------------
      
      a) Template Haskell quotes should be able to mention top-leve
         things without resorting to lifting.  Example
      
      	module Foo( foo ) where
      	  f x = x
      	  foo = [| f 4 |]
      
         Here the reference to 'f' is ok; no need to 'lift' it.
         The relevant changes are in TcExpr.tcId
      
      b) However, we must take care not to discard the binding for f,
         so we add it to the 'keep-alive' set for the module.  I've
         now made this into (another) mutable bucket, tcg_keep, 
         in the TcGblEnv
      
      c) That in turn led me to look at the handling of orphan rules;
         as a result I made IdCoreRule into its own data type, which
         has simle but non-local ramifications
      1f7da302
  30. 30 Sep, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-09-30 10:35:15 by simonpj] · 23f40f0e
      simonpj authored
      ------------------------------------
      	Add Generalised Algebraic Data Types
      	------------------------------------
      
      This rather big commit adds support for GADTs.  For example,
      
          data Term a where
       	  Lit :: Int -> Term Int
      	  App :: Term (a->b) -> Term a -> Term b
      	  If  :: Term Bool -> Term a -> Term a
      	  ..etc..
      
          eval :: Term a -> a
          eval (Lit i) = i
          eval (App a b) = eval a (eval b)
          eval (If p q r) | eval p    = eval q
          		    | otherwise = eval r
      
      
      Lots and lots of of related changes throughout the compiler to make
      this fit nicely.
      
      One important change, only loosely related to GADTs, is that skolem
      constants in the typechecker are genuinely immutable and constant, so
      we often get better error messages from the type checker.  See
      TcType.TcTyVarDetails.
      
      There's a new module types/Unify.lhs, which has purely-functional
      unification and matching for Type. This is used both in the typechecker
      (for type refinement of GADTs) and in Core Lint (also for type refinement).
      23f40f0e
  31. 16 Aug, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-08-16 09:53:47 by simonpj] · 4e325538
      simonpj authored
      -------------------------------
      	Add instance information to :i
       	Get rid of the DeclPool
      	-------------------------------
      
      
      1.  Add instance information to :info command.  GHCi now prints out
          which instances a type or class belongs to, when you use :i
      
      2.  Tidy up printing of unqualified names in user output.
          Previously Outputable.PrintUnqualified was
      	type PrintUnqualified = Name -> Bool
          but it's now
      	type PrintUnqualified = ModuleName -> OccName -> Bool
          This turns out to be tidier even for Names, and it's now also usable
          when printing IfaceSyn stuff in GHCi, eliminating a grevious hack.
      
      3.  On the way to doing this, Simon M had the great idea that we could
          get rid of the DeclPool holding pen, which held declarations read from
          interface files but not yet type-checked.   We do this by eagerly
          populating the TypeEnv with thunks what, when poked, do the type
          checking.   This is just a logical continuation of lazy import
          mechanism we've now had for some while.
      
      The InstPool and RulePool still exist, but I plan to get rid of them in
      the same way.  The new scheme does mean that more rules get sucked in than
      before, because previously the TypeEnv was used to mean "this thing was needed"
      and hence to control which rules were sucked in.  But now the TypeEnv is
      populated more eagerly => more rules get sucked in.  However this problem
      will go away when I get rid of the Inst and Rule pools.
      
      I should have kept these changes separate, but I didn't.  Change (1)
      affects mainly
      	TcRnDriver, HscMain, CompMan, InteractiveUI
      whereas change (3) is more wide ranging.
      4e325538
  32. 22 Jun, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-06-22 11:03:42 by simonpj] · 20410577
      simonpj authored
      -----------------------------------------------
             Improve reporting of TH reify out-of-scope errors
      	-----------------------------------------------
      
      No change to functionality, just better error reports.
      20410577
  33. 06 May, 2004 1 commit
  34. 24 Feb, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-02-24 15:57:52 by simonpj] · 53fe9413
      simonpj authored
      ---------------------------------------
        	 Record dependency on Template Haskell package
      	  ---------------------------------------
      
      An unforseen consequence of making the Template Haskell package separate
      is that we need to record dependency on the package, even if no TH module
      is imported.  So we carry round (another) mutable variable tcg_th_used in
      the tyepchecker monad, and zap it when $(...) and [| ... |] are used.
      
      I did a little tidy-up and documentation in ListSetOps too
      53fe9413
  35. 26 Jan, 2004 1 commit
  36. 23 Jan, 2004 1 commit
    • simonmar's avatar
      [project @ 2004-01-23 13:55:28 by simonmar] · 29da2cf3
      simonmar authored
      Some small steps in the direction of making GHC useable as a library:
      
        - The ErrMsg type is now richer: we keep the location info and the
          PrintUnqualified separate until the message is printed out, and
          messages have a short summary and "extra info", where the extra
          info is used for things like the context info in the typechecker
          (stuff that you don't normally want to see in a more visual setting,
          where the context is obvious because you're looking at the code).
      
        - hscMain now takes an extra argument of type (Messages -> IO ()),
          which says what to do with the error messages.  In normal usage,
          we just pass ErrUtils.printErrorsAndWarnings, but eg. a development
          environment will want to do something different.  The direction we
          need to head in is for hscMain to *never* do any output to
          stdout/stderr except via abstractions like this.
      29da2cf3
  37. 05 Jan, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-01-05 12:11:42 by simonpj] · 3721dd37
      simonpj authored
      ---------------------------------------
      	  Don't expose constructors as vigorously
      	  ---------------------------------------
      
      GHC used to expose the constructors of a data type in the interface file,
      even if (a) we were not optimising, and (b) the constructors are not exported.
      
      In practice this isn't really necessary, and it's bad because it forces too
      much recompilation.  I've been meaning to fix this for some while.
      
      Now the data cons are hidden, even in the interface file, if both (a) and (b)
      are true.  That means less interface file wobbling.
      
      Mind you, the interface file still changes, because the to/from functions for
      generic type classes change their types.  But provided you don't use them, you'll
      get "compilation not required".
      
      We could play the same game for classes (by hiding their class ops) but that'd
      mean we'd have to change the data type for IfaceClassDecl, and I can't be
      bothered to do that today.  It's unusual to have a class which exports none
      of its methods anyway.
      
      
      
      On the way, I changed the representation of tcg_exports and mg_exports (from
      Avails to NameSet), but that should be externally invisible.
      3721dd37
  38. 30 Dec, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-12-30 16:29:17 by simonpj] · f714e6b6
      simonpj authored
      ----------------------------
              Re-do kind inference (again)
      	----------------------------
      
         [WARNING: interface file binary representation has
         (as usual) changed slightly; recompile your libraries!]
      
      Inspired by the lambda-cube, for some time GHC has used
      	type Kind = Type
      That is, kinds were represented by the same data type as types.
      
      But GHC also supports unboxed types and unboxed tuples, and these
      complicate the kind system by requiring a sub-kind relationship.
      Notably, an unboxed tuple is acceptable as the *result* of a
      function but not as an *argument*.  So we have the following setup:
      
      		 ?
      		/ \
      	       /   \
      	      ??   (#)
      	     /  \
                  *   #
      
      where	*    [LiftedTypeKind]   means a lifted type
      	#    [UnliftedTypeKind] means an unlifted type
      	(#)  [UbxTupleKind]     means unboxed tuple
      	??   [ArgTypeKind]      is the lub of *,#
      	?    [OpenTypeKind]	means any type at all
      
      In particular:
      
        error :: forall a:?. String -> a
        (->)  :: ?? -> ? -> *
        (\(x::t) -> ...)	Here t::?? (i.e. not unboxed tuple)
      
      All this has beome rather difficult to accommodate with Kind=Type, so this
      commit splits the two.
      
        * Kind is a distinct type, defined in types/Kind.lhs
      
        * IfaceType.IfaceKind disappears: we just re-use Kind.Kind
      
        * TcUnify.unifyKind is a distinct unifier for kinds
      
        * TyCon no longer needs KindCon and SuperKindCon variants
      
        * TcUnify.zapExpectedType takes an expected Kind now, so that
          in TcPat.tcMonoPatBndr we can express that the bound variable
          must have an argTypeKind (??).
      
      The big change is really that kind inference is much more systematic and
      well behaved.  In particular, a kind variable can unify only with a
      "simple kind", which is built from * and (->).  This deals neatly
      with awkward questions about how we can combine sub-kinding with type
      inference.
      
      Lots of small consequential changes, especially to the kind-checking
      plumbing in TcTyClsDecls.  (We played a bit fast and loose before, and
      now we have to be more honest, in particular about how kind inference
      works for type synonyms.  They can have kinds like (* -> #), so
      
      This cures two long-standing SourceForge bugs
      
      * 753777 (tcfail115.hs), which used erroneously to pass,
        but crashed in the code generator
            type T a = Int -> (# Int, Int #)
            f :: T a -> T a
            f t = \x -> case t x of r -> r
      
      * 753780 (tc167.hs), which used erroneously to fail
            f :: (->) Int# Int#
      
      
      Still, the result is not entirely satisfactory.  In particular
      
      * The error message from tcfail115 is pretty obscure
      
      * SourceForge bug 807249 (Instance match failure on openTypeKind)
        is not fixed.  Alas.
      f714e6b6
  39. 10 Dec, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-12-10 14:15:16 by simonmar] · 55042138
      simonmar authored
      Add accurate source location annotations to HsSyn
      -------------------------------------------------
      
      Every syntactic entity in HsSyn is now annotated with a SrcSpan, which
      details the exact beginning and end points of that entity in the
      original source file.  All honest compilers should do this, and it was
      about time GHC did the right thing.
      
      The most obvious benefit is that we now have much more accurate error
      messages; when running GHC inside emacs for example, the cursor will
      jump to the exact location of an error, not just a line somewhere
      nearby.  We haven't put a huge amount of effort into making sure all
      the error messages are accurate yet, so there could be some tweaking
      still needed, although the majority of messages I've seen have been
      spot-on.
      
      Error messages now contain a column number in addition to the line
      number, eg.
      
         read001.hs:25:10: Variable not in scope: `+#'
      
      To get the full text span info, use the new option -ferror-spans.  eg.
      
         read001.hs:25:10-11: Variable not in scope: `+#'
      
      I'm not sure whether we should do this by default.  Emacs won't
      understand the new error format, for one thing.
      
      In a more elaborate editor setting (eg. Visual Studio), we can arrange
      to actually highlight the subexpression containing an error.  Eventually
      this information will be used so we can find elements in the abstract
      syntax corresponding to text locations, for performing high-level editor
      functions (eg. "tell me the type of this expression I just highlighted").
      
      Performance of the compiler doesn't seem to be adversely affected.
      Parsing is still quicker than in 6.0.1, for example.
      
      Implementation:
      
      This was an excrutiatingly painful change to make: both Simon P.J. and
      myself have been working on it for the last three weeks or so.  The
      basic changes are:
      
       - a new datatype SrcSpan, which represents a beginning and end position
         in a source file.
      
       - To reduce the pain as much as possible, we also defined:
      
            data Located e = L SrcSpan e
      
       - Every datatype in HsSyn has an equivalent Located version.  eg.
      
            type LHsExpr id = Located (HsExpr id)
      
         and pretty much everywhere we used to use HsExpr we now use
         LHsExpr.  Believe me, we thought about this long and hard, and
         all the other options were worse :-)
      
      
      Additional changes/cleanups we made at the same time:
      
        - The abstract syntax for bindings is now less arcane.  MonoBinds
          and HsBinds with their built-in list constructors have gone away,
          replaced by HsBindGroup and HsBind (see HsSyn/HsBinds.lhs).
      
        - The various HsSyn type synonyms have now gone away (eg. RdrNameHsExpr,
          RenamedHsExpr, and TypecheckedHsExpr are now HsExpr RdrName,
          HsExpr Name, and HsExpr Id respectively).
      
        - Utilities over HsSyn are now collected in a new module HsUtils.
          More stuff still needs to be moved in here.
      
        - MachChar now has a real Char instead of an Int.  All GHC versions that
          can compile GHC now support 32-bit Chars, so this was a simplification.
      55042138