1. 20 Jun, 2007 1 commit
  2. 06 Jun, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Remove unnecessary free-variables from renamer · 3c4a732b
      simonpj@microsoft.com authored
      The renamer used to be responsible for making sure that all interfaces
      with instance decls (other than orphans) were loaded.  But TH makes that
      impossible, so the typechecker does it, via checkWiredInTyCon.
      
      This patch simply removes redundant additions to the free-variable set
      in the renamer, which were there, I believe, solely to ensure that the 
      instances came in.  Removing them should change nothing, but it's a 
      useful clean up.
      3c4a732b
  3. 02 May, 2007 1 commit
  4. 23 Mar, 2007 1 commit
  5. 04 Feb, 2007 1 commit
  6. 21 Dec, 2006 1 commit
    • lennart@augustsson.net's avatar
      Add support for overloaded string literals. · 90dc9026
      lennart@augustsson.net authored
      The class is named IsString with the single method fromString.
      Overloaded strings work the same way as overloaded numeric literals.
      In expressions a string literals gets a fromString applied to it.
      In a pattern there will be an equality comparison with the fromString:ed literal.
      
      Use -foverloaded-strings to enable this extension.
       
      90dc9026
  7. 29 Dec, 2006 1 commit
    • andy@galois.com's avatar
      Adding a GENERATED pragma · d386e0d2
      andy@galois.com authored
      Adding a {-# GENERATED "SourceFile" SourceSpan #-} <expr> pragma.
      This will be used to generate coverage for tool generated (or quoted) code.
      The pragma states the the expression was generated/quoted from the stated
      source file and source span.
      d386e0d2
  8. 10 Dec, 2006 1 commit
  9. 13 Oct, 2006 1 commit
    • simonpj@microsoft.com's avatar
      More refactoring in RnNames · 5ad61e14
      simonpj@microsoft.com authored
      I rather self-indulgently spent a chunk of yesterday working on 
      refactoring RnNames further.  The result is significantly simpler:
      
      * A GlobalRdrElt gets an extra field, gre_par, which records
        the parent (if any) of the name
      
      * ImportAvails has two fields deleted: imp_env and imp_parent.
        The information provided by these fields was only used when
        processing the export list; and the same information is now readily
        generated from the GlobalRdrElts in the GlobalRdrEnv
      
      I also did some tidying up; notably moving AvailEnv stuff from
      TcRnTypes to RnNames.
      
      The result is tha the compiler is some 130 lines shorter than before
      5ad61e14
  10. 11 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Interface file optimisation and removal of nameParent · b00b5bc0
      Simon Marlow authored
      This large commit combines several interrelated changes:
      
        - IfaceSyn now contains actual Names rather than the special
          IfaceExtName type.  The binary interface file contains
          a symbol table of Names, where each entry is a (package,
          ModuleName, OccName) triple.  Names in the IfaceSyn point
          to entries in the symbol table.
      
          This reduces the size of interface files, which should
          hopefully improve performance (not measured yet).
      
          The toIfaceXXX functions now do not need to pass around
          a function from Name -> IfaceExtName, which makes that
          code simpler.
      
        - Names now do not point directly to their parents, and the
          nameParent operation has gone away.  It turned out to be hard to
          keep this information consistent in practice, and the parent info
          was only valid in some Names.  Instead we made the following
          changes:
      
          * ImportAvails contains a new field 
                imp_parent :: NameEnv AvailInfo
            which gives the family info for any Name in scope, and
            is used by the renamer when renaming export lists, amongst
            other things.  This info is thrown away after renaming.
      
          * The mi_ver_fn field of ModIface now maps to
            (OccName,Version) instead of just Version, where the
            OccName is the parent name.  This mapping is used when
            constructing the usage info for dependent modules.
            There may be entries in mi_ver_fn for things that are not in
            scope, whereas imp_parent only deals with in-scope things.
      
          * The md_exports field of ModDetails now contains
            [AvailInfo] rather than NameSet.  This gives us
            family info for the exported names of a module.
      
      Also:
      
         - ifaceDeclSubBinders moved to IfaceSyn (seems like the
           right place for it).
      
         - heavily refactored renaming of import/export lists.
      
         - Unfortunately external core is now broken, as it relied on
           IfaceSyn.  It requires some attention.
      b00b5bc0
  11. 03 Oct, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Fix scoped type variables for expression type signatures · 9da46390
      simonpj@microsoft.com authored
      I had forgotten to bring scoped type variables into scope at an expression
      type signature, such as
      	e :: forall s. <type>
      where 's' should scope over the expression e.
      
      Like everything to do with scoped type variables, fixing this took an 
      unreasonable amount of work.  I'm sure there must be a better way to 
      achitect this!
      
      I updated the user manual too.
      
      A test is tc213.
      
      It would be good to push this into 6.6.1
      9da46390
  12. 29 Sep, 2006 1 commit
  13. 23 Sep, 2006 1 commit
  14. 04 Aug, 2006 1 commit
  15. 07 Sep, 2006 1 commit
  16. 25 Aug, 2006 1 commit
  17. 08 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Remove srcSpanStartLine/srcSpanEndLine crash · e944b32b
      simonpj@microsoft.com authored
      srcSpanStartLine/srcSpanEndLine panic on UnhelpfulLoc. They should not
      really be exported by SrcLoc at all, but unfortunately they are used in
      Lexer.x, which knows enough to avoid the panic.
      
      However the call in RnEnv didn't know, and the panic was triggered 
      by Template Haskell spliced code.  This patch fixes it by exporting
      the predicate RnEnv wanted, namely isOneLineSpan.
      e944b32b
  18. 04 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Do pre-subsumption in the main subsumption check · af20907a
      simonpj@microsoft.com authored
      This patch improves the subsumption check (in TcUnify.tc_sub) so that
      it does pre-subsumption first.  The key code is in the case with
      guard (isSigmaTy actual_ty); note the new call to preSubType.
      
      Shorn of details, the question is this.  Should this hold?
      
      	forall a. a->a   <=   Int -> (forall b. Int)
      
      Really, it should; just instantiate 'a' to Int.  This is just what
      the pre-subsumption phase (which used in function applications),
      will do.
      
      I did a bit of refactoring to achieve this.
      
      Fixes Trac #821.  Test tc205 tests.
      af20907a
  19. 25 Jul, 2006 1 commit
    • Simon Marlow's avatar
      Generalise Package Support · 61d2625a
      Simon Marlow authored
      This patch pushes through one fundamental change: a module is now
      identified by the pair of its package and module name, whereas
      previously it was identified by its module name alone.  This means
      that now a program can contain multiple modules with the same name, as
      long as they belong to different packages.
      
      This is a language change - the Haskell report says nothing about
      packages, but it is now necessary to understand packages in order to
      understand GHC's module system.  For example, a type T from module M
      in package P is different from a type T from module M in package Q.
      Previously this wasn't an issue because there could only be a single
      module M in the program.
      
      The "module restriction" on combining packages has therefore been
      lifted, and a program can contain multiple versions of the same
      package.
      
      Note that none of the proposed syntax changes have yet been
      implemented, but the architecture is geared towards supporting import
      declarations qualified by package name, and that is probably the next
      step.
      
      It is now necessary to specify the package name when compiling a
      package, using the -package-name flag (which has been un-deprecated).
      Fortunately Cabal still uses -package-name.
      
      Certain packages are "wired in".  Currently the wired-in packages are:
      base, haskell98, template-haskell and rts, and are always referred to
      by these versionless names.  Other packages are referred to with full
      package IDs (eg. "network-1.0").  This is because the compiler needs
      to refer to entities in the wired-in packages, and we didn't want to
      bake the version of these packages into the comiler.  It's conceivable
      that someone might want to upgrade the base package independently of
      GHC.
      
      Internal changes:
      
        - There are two module-related types:
      
              ModuleName      just a FastString, the name of a module
              Module          a pair of a PackageId and ModuleName
      
          A mapping from ModuleName can be a UniqFM, but a mapping from Module
          must be a FiniteMap (we provide it as ModuleEnv).
      
        - The "HomeModules" type that was passed around the compiler is now
          gone, replaced in most cases by the current package name which is
          contained in DynFlags.  We can tell whether a Module comes from the
          current package by comparing its package name against the current
          package.
      
        - While I was here, I changed PrintUnqual to be a little more useful:
          it now returns the ModuleName that the identifier should be qualified
          with according to the current scope, rather than its original
          module.  Also, PrintUnqual tells whether to qualify module names with
          package names (currently unused).
      
      Docs to follow.
      61d2625a
  20. 02 May, 2006 1 commit
  21. 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
  22. 06 Apr, 2006 1 commit
  23. 02 Mar, 2006 1 commit
  24. 03 Feb, 2006 1 commit
  25. 06 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-06 16:30:17 by simonmar] · 9d7da331
      simonmar authored
      Add support for UTF-8 source files
      
      GHC finally has support for full Unicode in source files.  Source
      files are now assumed to be UTF-8 encoded, and the full range of
      Unicode characters can be used, with classifications recognised using
      the implementation from Data.Char.  This incedentally means that only
      the stage2 compiler will recognise Unicode in source files, because I
      was too lazy to port the unicode classifier code into libcompat.
      
      Additionally, the following synonyms for keywords are now recognised:
      
        forall symbol 	(U+2200)	forall
        right arrow   	(U+2192)	->
        left arrow   		(U+2190)	<-
        horizontal ellipsis 	(U+22EF)	..
      
      there are probably more things we could add here.
      
      This will break some source files if Latin-1 characters are being used.
      In most cases this should result in a UTF-8 decoding error.  Later on
      if we want to support more encodings (perhaps with a pragma to specify
      the encoding), I plan to do it by recoding into UTF-8 before parsing.
      
      Internally, there were some pretty big changes:
      
        - FastStrings are now stored in UTF-8
      
        - Z-encoding has been moved right to the back end.  Previously we
          used to Z-encode every identifier on the way in for simplicity,
          and only decode when we needed to show something to the user.
          Instead, we now keep every string in its UTF-8 encoding, and
          Z-encode right before printing it out.  To avoid Z-encoding the
          same string multiple times, the Z-encoding is cached inside the
          FastString the first time it is requested.
      
          This speeds up the compiler - I've measured some definite
          improvement in parsing at least, and I expect compilations overall
          to be faster too.  It also cleans up a lot of cruft from the
          OccName interface.  Z-encoding is nicely hidden inside the
          Outputable instance for Names & OccNames now.
      
        - StringBuffers are UTF-8 too, and are now represented as
          ForeignPtrs.
      
        - I've put together some test cases, not by any means exhaustive,
          but there are some interesting UTF-8 decoding error cases that
          aren't obvious.  Also, take a look at unicode001.hs for a demo.
      9d7da331
  26. 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
  27. 26 Oct, 2005 2 commits
    • simonpj's avatar
      [project @ 2005-10-26 12:35:12 by simonpj] · 07806d2b
      simonpj authored
      Simplify Provenance (the LocalDef constructor) a little
      07806d2b
    • simonpj's avatar
      [project @ 2005-10-26 12:05:03 by simonpj] · 015aa972
      simonpj authored
      MERGE TO STABLE
      
      Fix two small Template Haskell bugs.
      
      (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.
      
      TH_spliceDecl4 is the test.
      
      (2) An expression splice can in principle mention *any* variable,
      so the renamer really has to assume that it does when doing depdendency
      analysis.  For example
      	f = ...
      	h = ...$(thing "f")...
      The renamer had better not put 'h' before 'f', else the type checker
      won't find a defn for 'f' in the type envt.
      
      TH_spliceE5 is the test
      015aa972
  28. 09 Aug, 2005 1 commit
  29. 28 Jul, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-07-28 13:51:28 by simonpj] · a32d3e4d
      simonpj authored
      MERGE to STABLE
      
      Fix a TH name-reification bug. The problem is that when you say
      
      	'name
      
      in TH, you'd better load the home interface for "name", so that
      deprecations are reported properly.
      
      Fixes SourceForge
      	[ghc-Bugs-1246483 ] Template Haskell panic with class names
      
      TH_reifyType2 is a test for it.
      a32d3e4d
  30. 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
  31. 11 Jul, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-07-11 09:48:57 by simonpj] · a6f3a1f8
      simonpj authored
      Fix a bug in the renamer for parallel list comprehensions
      	MERGE TO STABLE
      
      It's surprinsingly tricky to combine 
        a) The parallel scopes for par-list-comps
      with
        b) The general form of the renamer types, whereby
           scoped constructs work like
      	 rnPat :: Pat -> RnM (thing,FreeVars)
      	       -> RnM ((Pat,thing), FreeVars)
           This general shape neatly allows rnPat to
           extend the envt, report unused variables from
           the 'thing' inside, and return the correct set
           of free variables
      
      But combining (a) and (b) is tricky, and was plain wrong before.
      a6f3a1f8
  32. 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
  33. 03 May, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-05-03 10:53:00 by simonpj] · b95b036f
      simonpj authored
      Fix the test for duplicate local bindings, so that it works with
      Template Haskell.  Pre-TH, all the local bindings came into scope
      at once, but with TH they come into scope in groups, and we must
      check for conflict with existing local bindings.
      
      	MERGE TO STABLE
      b95b036f
  34. 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
  35. 04 Apr, 2005 2 commits
    • simonpj's avatar
      [project @ 2005-04-04 16:15:04 by simonpj] · 5f38e9ba
      simonpj authored
      More stage2 wibbles
      5f38e9ba
    • simonpj's avatar
      [project @ 2005-04-04 11:55:11 by simonpj] · d551dbfe
      simonpj authored
      This commit combines three overlapping things:
      
      1.  Make rebindable syntax work for do-notation. The idea
          here is that, in particular, (>>=) can have a type that
          has class constraints on its argument types, e.g.
             (>>=) :: (Foo m, Baz a) => m a -> (a -> m b) -> m b
          The consequence is that a BindStmt and ExprStmt must have
          individual evidence attached -- previously it was one
          batch of evidence for the entire Do
          
          Sadly, we can't do this for MDo, because we use bind at
          a polymorphic type (to tie the knot), so we still use one
          blob of evidence (now in the HsStmtContext) for MDo.
          
          For arrow syntax, the evidence is in the HsCmd.
          
          For list comprehensions, it's all built-in anyway.
          
          So the evidence on a BindStmt is only used for ordinary
          do-notation.
      
      2.  Tidy up HsSyn.  In particular:
      
      	- Eliminate a few "Out" forms, which we can manage
      	without (e.g. 
      
      	- It ought to be the case that the type checker only
      	decorates the syntax tree, but doesn't change one
      	construct into another.  That wasn't true for NPat,
      	LitPat, NPlusKPat, so I've fixed that.
      
      	- Eliminate ResultStmts from Stmt.  They always had
      	to be the last Stmt, which led to awkward pattern
      	matching in some places; and the benefits didn't seem
      	to outweigh the costs.  Now each construct that uses
      	[Stmt] has a result expression too (e.g. GRHS).
      
      
      3.  Make 'deriving( Ix )' generate a binding for unsafeIndex,
          rather than for index.  This is loads more efficient.
      
          (This item only affects TcGenDeriv, but some of point (2)
          also affects TcGenDeriv, so it has to be in one commit.)
      d551dbfe
  36. 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
  37. 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
  38. 04 Oct, 2004 1 commit