1. 31 Jan, 2005 2 commits
  2. 28 Jan, 2005 2 commits
    • simonpj's avatar
      [project @ 2005-01-28 17:44:55 by simonpj] · c51fdf44
      simonpj authored
      Arrange that when seeking instance decls in GHCi, in response
      to a :info command, we only print ones whose types are in scope
      unqualified.  This eliminates an alarmingly long list when
      simply typing ':info Show', say.
      
      On the way, I reorganised a bit.  GHCi printing happens by
      converting a TyThing to an IfaceDecl, and printing that.
      I now arrange to generate unqualifed IfaceExtNames directly
      during this conversion, based on what is in scope.  Previously
      it was done during the pretty-printing part via the UserStyle.
      But this is nicer.
      c51fdf44
    • simonmar's avatar
      [project @ 2005-01-28 12:55:17 by simonmar] · 153b9cb9
      simonmar authored
      Rationalise the BUILD,HOST,TARGET defines.
      
      Recall that:
      
        - build is the platform we're building on
        - host is the platform we're running on
        - target is the platform we're generating code for
      
      The change is that now we take these definitions as applying from the
      point of view of the particular source code being built, rather than
      the point of view of the whole build tree.
      
      For example, in RTS and library code, we were previously testing the
      TARGET platform.  But under the new rule, the platform on which this
      code is going to run is the HOST platform.  TARGET only makes sense in
      the compiler sources.
      
      In practical terms, this means that the values of BUILD, HOST & TARGET
      may vary depending on which part of the build tree we are in.
      
      Actual changes:
      
       - new file: includes/ghcplatform.h contains platform defines for
         the RTS and library code.
      
       - new file: includes/ghcautoconf.h contains the autoconf settings
         only (HAVE_BLAH).  This is so that we can get hold of these
         settings independently of the platform defines when necessary
         (eg. in GHC).
      
       - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.
      
       - MachRegs.h, which is included into both the compiler and the RTS,
         now has to cope with the fact that it might need to test either
         _TARGET_ or _HOST_ depending on the context.
      
       - the compiler's Makefile now generates
           stage{1,2,3}/ghc_boot_platform.h
         which contains platform defines for the compiler.  These differ
         depending on the stage, of course: in stage2, the HOST is the
         TARGET of stage1.  This was wrong before.
      
       - The compiler doesn't get platform info from Config.hs any more.
         Previously it did (sometimes), but unless we want to generate
         a new Config.hs for each stage we can't do this.
      
       - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
         in CPP'd Haskell source.
      
       - ghcplatform.h defines *_TARGET_* for backwards compatibility
         (ghcplatform.h is included by ghcconfig.h, which is included by
         config.h, so code which still #includes config.h will get the TARGET
         settings as before).
      
       - The Users's Guide is updated to mention *_HOST_* rather than
         *_TARGET_*.
      
       - coding-style.html in the commentary now contains a section on
         platform defines.  There are further doc updates to come.
      
      Thanks to Wolfgang Thaller for pointing me in the right direction.
      153b9cb9
  3. 27 Jan, 2005 4 commits
    • simonpj's avatar
      [project @ 2005-01-27 11:51:56 by simonpj] · 56f5bc18
      simonpj authored
      Import trimming
      56f5bc18
    • simonpj's avatar
      [project @ 2005-01-27 11:50:58 by simonpj] · 281bcf70
      simonpj authored
      Make sure that the interactive context can see home-package instances;
      I forgot to do this when making tcRnModule find the appropriate intances
      (TcRnDriver rev 1.91)
      
      This was causing SourceForge [ghc-Bugs-1106171].
      281bcf70
    • simonpj's avatar
      [project @ 2005-01-27 11:12:52 by simonpj] · 04864fb7
      simonpj authored
      Remove redundant .hi-boot files.  The earliest compiler we claim to be able
      to compile GHC with is GHC 5, and that needs hi-boot-5 boot files.  So the
      plain hi-boot files are dead.
      
      Reason for removing them now is that my big commit accidentally splatted
      them with binary data; so if you ever want to recover them, go back
      one revision beore the one I'm deleting.
      04864fb7
    • 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
  4. 26 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-26 16:10:02 by simonpj] · 8254dcf1
      simonpj authored
      -----------------------
      	Fixup to hoistForAllTys
      	-----------------------
      
      * hoistForAllTys moves from TcHsType to TcType
      
      hoistForAllTys was being too vigorous and breaking up type synonyms,
      even when it was entirely unnecessary to do so.
      
      Not only does this make error messsages less good, but it's actually
      wrong for Haskell 98, because we are meant to report under-applied
      type synonyms, and that check doesn't happen until after hoistForAllTys.
      This led to a very obscure bug, immortalised as tcfail129.
      8254dcf1
  5. 21 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-21 16:02:47 by simonmar] · 3f205c43
      simonmar authored
      Don't try to run finalizers at program exit.  This turned out to be
      hard if not impossible to do in general, so now we don't attempt it at
      all.
      
      The Main.main wrapper, previously called runIO and now called
      runMainIO, flushes stdout and stderr before exiting.  This should
      catch most cases where programs rely on Handles being flushed at
      program exit, but note that now if you simply drop a Handle in your
      program, there's no guarantee it'll be flushed on exit.  If the
      punters complain enough, I suppose we could implement a global
      Handle table and flush them all at exit... I'd rather not do this if
      possible, though.  Better to teach people to close their Handles
      properly.
      3f205c43
  6. 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
  7. 12 Jan, 2005 1 commit
  8. 06 Jan, 2005 3 commits
  9. 05 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-05 15:28:39 by simonpj] · 19da321b
      simonpj authored
      ------------------------
                GADTs and unification
        	------------------------
      
      1. Adjustment to typechecking of pattern matching the call to
         gadtRefineTys in TcPat.  Now wobbly types are treated as wild
         cards in the unification process.
      
      2. Add the WildCard possibility to the BindFlag in types/Unify.lhs
      
      3. Some related refactoring of tcMatchTys etc.
      19da321b
  10. 04 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-04 16:26:55 by simonpj] · a27f7c87
      simonpj authored
      ------------------
                Fix an mdo bug
        	------------------
      
      Embarassingly, this bug makes GHC either panic (for some programs) or
      go into a loop (on others) in a recursive mdo that involves a
      polymorphic function.  Urk!
      
      The fix is twofold:
        a) add a missing bindInstsOfLocalFuns to tcStmtAndThen (RecStmt case)
        b) bind the correct set of variables in dsRecStmt
      
      I added some explanatory comments about RecStmt in HsExpr too.
      
      The tests is mdo/should_compile/mdo006
      a27f7c87
  11. 24 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-24 11:02:39 by simonpj] · 0ee11df0
      simonpj authored
      Further wibbles to the scoped-tyvar story.
      
      This commit tidies up the ATyVar in TcTyThing, making it
      	ATyVar Name Type
      instead of the previous misleading
      	ATyVar TyVar Type
      
      But the main thing is that we must take care with definitions
      like this:
      
      	type T a = forall b. b -> (a,b)
      
      	f :: forall c. T c
      	f = ...
      
      Here, we want only 'c' to scope over the RHS of f.  The renamer ensures
      that... but we must also take care that we freshly instantiate the 
      expanded type signature (forall c b. b -> (c,b)) before checking f's RHS,
      so that we don't get false sharing between uses of T.
      0ee11df0
  12. 23 Dec, 2004 2 commits
    • simonpj's avatar
      [project @ 2004-12-23 13:44:06 by simonpj] · af3dc1ff
      simonpj authored
      minor nomenclature wibble
      af3dc1ff
    • simonpj's avatar
      [project @ 2004-12-23 09:07:30 by simonpj] · e12e0bb7
      simonpj authored
      ---------------------------------
                Template Haskell: names again
        	---------------------------------
      
      On 2 Dec 04 I made this commit (1.58 in Convert.lhs)
      
          Fix a Template Haskell bug that meant that top-level names created
          with newName were not made properly unique.
      
      But that just introduced a new bug!  THe trouble is that names created by
      newName are NameUs; but I was *also* using NameU for names of free varaibles,
      such as the 'x' in the quoted code here
      	f x = $( g [| \y -> (x,y) |])
      
      But when converting to HsSyn, the x and y must be treated diffferently.
      The 'x' must convert to an Exact RdrName, so that it binds to the 'x' that's
      in the type environment; but the 'y' must generate a nice unique RdrName.
      
      So this commit adds NameL for the lexically-scoped bindings like 'x'.
      e12e0bb7
  13. 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
  14. 21 Dec, 2004 4 commits
    • simonpj's avatar
      [project @ 2004-12-21 17:08:59 by simonpj] · 893d7df5
      simonpj authored
      ---------------------------------
           Template Haskell: dynamically scoped qualified names
      	---------------------------------
      
      This commit adds a constructor to TH.Name, so that
      
      	nameBase (mkName "Foo.baz")    == "baz"
      	nameModule (MkName "Foo.baz") == "Foo"
      
      We always did parse the module name off the front, but it used to
      be done in hsSyn/Convert, but now it's done in TH.Syntax, which is
      a better place.
      893d7df5
    • simonpj's avatar
      [project @ 2004-12-21 12:22:22 by simonpj] · 79a8b87c
      simonpj authored
      ---------------------------------
           Improve handling of lexically scoped type variables
      	---------------------------------
      
      If we have
      
      	f :: T a -> a
      	f (x :: T b) = ...
      
      then the lexically scoped variable 'b' should refer to the rigid
      type variable 'a', without any intervening wobbliness.  Previously
      the in-scope type variables were always mutable TyVars, which were
      instantatiated to point to the type they were bound to; but since
      the advent of GADTs the intervening mutable type variable is a bad
      thing.
      
      Hence
        * In the type environment, ATyVar now carries a type
        * The call to refineTyVars in tc_pat on SigPatIn
          finds the types by matching
        * Then tcExtendTyVarEnv3 extends the type envt appropriately
      
      Rater a lot of huff and puff, but it's quite natural for ATyVar
      to contain a type.
      
      Various other small nomenclature changes along the way.
      79a8b87c
    • simonpj's avatar
      [project @ 2004-12-21 12:14:31 by simonpj] · d2655be3
      simonpj authored
      Remove debug output
      d2655be3
    • simonpj's avatar
      [project @ 2004-12-21 12:09:14 by simonpj] · 6a120067
      simonpj authored
      Comments only
      6a120067
  15. 20 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-20 17:16:24 by simonpj] · c45a0ac5
      simonpj authored
      --------------------------------
      	Deal properly with dual-renaming
      	--------------------------------
      
      When comparing types and terms, and during matching, we are faced
      with 
      	\x.e1	~   \y.e2
      
      There are many pitfalls here, and GHC has never done the job properly.
      Now, at last it does, using a new abstraction VarEnv.RnEnv2.  See
      comments there for how it works.
      
      There are lots of consequential changes to use the new stuff, especially
      in 
      	types/Type (type comparison), 
      	types/Unify (matching on types)
      	coreSyn/CoreUtils (equality on expressions), 
      	specialise/Rules (matching).
      
      I'm not 100% certain of that I've covered all the bases, so let me
      know if something unexpected happens after you update.  Maybe wait until
      a nightly build has worked ok first!
      c45a0ac5
  16. 16 Dec, 2004 1 commit
  17. 15 Dec, 2004 2 commits
  18. 06 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-06 10:51:36 by simonpj] · f6f3819f
      simonpj authored
      ------------------------------------
      	Bug in loop detection in TcSimplify
      	------------------------------------
      
      The type-class context simplifier has been able to 
      build recursive dictionaries for some time: co-induction.
      That is, you can build a proof for constraint C by assuming
      that C holds when proving the preconditions of C.
      
      You need to be in -fallow-undecidable-instances land to 
      make use of this: see comments with [RECURSIVE DICTIONARIES]
      in TcSimplify.lhs.
      
      Anyway, this is all fine, but I'd implemented it wrong!  You need
      to be very careful with superclasses, or you can make a bogus
      loop by mistake.  This commit fixes it; tests LoopOfTheDay{1,2,3}
      will test it (thanks Ralf Laemmel).
      f6f3819f
  19. 03 Dec, 2004 2 commits
  20. 02 Dec, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-12-02 17:18:15 by simonpj] · 759739c6
      simonpj authored
      Sorry for the fact that there are overlapping three commits in here...
      
      1.  Make -fno-monomorphism-restriction 
          and -fno-implicit-prelude reversible, like other flags
      
      2.  Fix a wibble in the new ImportAvails story, in RnNames.mkExportAvails
      
      3.  Fix a Template Haskell bug that meant that top-level names created
          with newName were not made properly unique.
      759739c6
  21. 30 Nov, 2004 2 commits
  22. 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
  23. 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
  24. 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
  25. 18 Nov, 2004 1 commit
  26. 11 Nov, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-11-11 16:44:33 by simonpj] · dfec17bf
      simonpj authored
      ---------------------------------
           Buglet in the handling of unlifted bindings
      	---------------------------------
      
      Unlifted bindings, like
      	let I# v = ... in ...
      can't be generalised.  In teh transition to GADTs I introduced a bug
      that accidentally discarded some necessary dictionary bindings.
      
      This commit fixes it by moving the test for unlifted bindings to a
      much earlier point in tcBindWithSigs, which seems a lot cleaner to me.
      dfec17bf