1. 15 Mar, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Make the type-defaulting in GHCi use () as the first default type · d4b95ea9
      simonpj@microsoft.com authored
      See Trac #1200
      This is a somewhat experimental fix.  I'm not sure we want it in 6.6.1
      The idea is explained in Note [Default unitTy] in TcSimplify.  In
      interative mode (or with -fextended-default-rules) we add () as the
      first type we try when defaulting.  This has very little real impact,
      except in the following case.  Consider:
      	Text.Printf.printf "hello"
      This has type (forall a. IO a); it prints "hello", and returns
      'undefined'.  We don't want the GHCi repl loop to try to print that
      'undefined'.  The neatest thing is to default the 'a' to (), rather
      than to Integer (which is what would otherwise happen; and then GHCi
      doesn't attempt to print the ().  So in interactive mode, we add () to
      the list of defaulting types.  
  2. 21 Feb, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Fix a deriving bug, arising from recent refactoring · 66f73ee4
      simonpj@microsoft.com authored
      This one is a hangover from something I did a month or two ago, but
      didn't get quite right.  tcSimplifyDefault should not check for no-instances;
      instead the checkValidInstance in TcDeriv does so.
      Conal's DeepArrow needs this fix.  Test is drv015.
    • simonpj@microsoft.com's avatar
      Fix defaulting for overloaded strings · 041c35e5
      simonpj@microsoft.com authored
      This patch fixes the typechecking of the default declaration itself,
      when overloaded strings are involved.  It also documents the behaviour
      in the user manual.
      nofib/spectral/power should work again now!
  3. 19 Feb, 2007 1 commit
  4. 02 Feb, 2007 1 commit
  5. 31 Jan, 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.
  7. 09 Jan, 2007 1 commit
  8. 03 Jan, 2007 1 commit
  9. 02 Jan, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Big tidy-up of deriving code · 84923cc7
      simonpj@microsoft.com authored
      This tidy-up, triggered by Trac #1068, re-factors the way that 'deriving' 
      happens.  It took me way longer than I had intended.  The main changes,
      by far are to TcDeriv; everyting else is a minor consequence.
      While I was at it, I changed the syntax for standalone deriving, so that
      it goes
      	derive instance Show (T a)
      (instead of "derive Show for T").  However, there's still an implicit
      context, generated by the deriving code, and I wonder if it shouldn't really
      	derive instance (..) => Show (T a)
      but I have left it simple for now.
      I also added a function Type.substTyVars, and used it here and there, which
      led to some one-line changes otherwise unrelated (sorry).
      Loose ends:
        * 'deriving Typeable' for indexed data types is still not right
        * standalone deriving should be documented
  10. 12 Dec, 2006 1 commit
  11. 11 Dec, 2006 2 commits
  12. 01 Dec, 2006 1 commit
  13. 24 Nov, 2006 2 commits
    • simonpj@microsoft.com's avatar
      Improve handling of implicit parameters · 2e9952b7
      simonpj@microsoft.com authored
      A message to Haskell Cafe from Grzegorz Chrupala made me realise that
      GHC was not handling implicit parameters correctly, when it comes to
      choosing the variables to quantify, and ambiguity tests.  Here's the 
      note I added to TcSimplify:
      Note [Implicit parameters and ambiguity] 
      What type should we infer for this?
      	f x = (show ?y, x::Int)
      Since we must quantify over the ?y, the most plausible type is
      	f :: (Show a, ?y::a) => Int -> (String, Int)
      But notice that the type of the RHS is (String,Int), with no type 
      varibables mentioned at all!  The type of f looks ambiguous.  But
      it isn't, because at a call site we might have
      	let ?y = 5::Int in f 7
      and all is well.  In effect, implicit parameters are, well, parameters,
      so we can take their type variables into account as part of the
      "tau-tvs" stuff.  This is done in the function 'FunDeps.grow'.
      The actual changes are in FunDeps.grow, and the tests are
      	tc219, tc219
    • simonpj@microsoft.com's avatar
      Gather constraints in program order · ecd655aa
      simonpj@microsoft.com authored
      Provoked by a suggestion of Simon's, this patch makes a half-hearted attempt
      to gather constraints in program order, so that we tend to report an error
      at its first occurrence, rather than its last.  Examples:
      	mdofail001, tcfail015
      It's "half-hearted" because generally-speaking the typechecker does not
      guaranteed to keep constraints in order; it treats them as a set.  Nevertheless
      this very small change seems to improve matters, so it seems a good one.
  14. 23 Nov, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Simplify TcSimplify, by removing Free · a3a15a64
      simonpj@microsoft.com authored
      For a long time TcSimplify used a three-way classification of constraints, 
      into 	Free
      (see the data type WhatToDo).  In the new world of implication constraints,
      the Free case does not make so much sense, and I managed to elminate it
      altogether, thus simplifying the story somewhat.  Now WhatToDo has constructors
      There should be no change in behaviour.
  15. 22 Nov, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Retain simplifications of implication constraints · 5adfdfb2
      simonpj@microsoft.com authored
      When simplifying an implication constraint (reduceImplication), if we make
      progress, make a new implication constraint for the result.  If we don't
      do this, we get a constraint that can be simplified in a unique way,
      and that in turn confuses reportNoInstance
  16. 10 Nov, 2006 1 commit
  17. 01 Nov, 2006 2 commits
  18. 11 Oct, 2006 1 commit
  19. 20 Sep, 2006 1 commit
  20. 19 Sep, 2006 1 commit
  21. 29 Sep, 2006 2 commits
  22. 23 Sep, 2006 1 commit
  23. 20 Sep, 2006 3 commits
    • chak@cse.unsw.edu.au.'s avatar
      Complete the evidence generation for GADTs · 15cb792d
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 14:43:22 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Complete the evidence generation for GADTs
        Sat Aug  5 21:39:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Complete the evidence generation for GADTs
          Thu Jul 13 17:18:07 EDT 2006  simonpj@microsoft.com
            This patch completes FC evidence generation for GADTs.
            It doesn't work properly yet, because part of the compiler thinks
            	(t1 :=: t2) => t3
            is represented with FunTy/PredTy, while the rest thinks it's represented
            using ForAllTy.  Once that's done things should start to work.
    • chak@cse.unsw.edu.au.'s avatar
      some bug-fixes, newtype deriving might work now · 44ba24dc
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 14:33:01 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * some bug-fixes, newtype deriving might work now
        Sat Aug  5 21:29:28 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * some bug-fixes, newtype deriving might work now
          Tue Jul 11 12:16:13 EDT 2006  kevind@bu.edu
    • chak@cse.unsw.edu.au.'s avatar
      Massive patch for the first months work adding System FC to GHC #34 · 3e83dfb2
      chak@cse.unsw.edu.au. authored
      Fri Sep 15 18:56:58 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Massive patch for the first months work adding System FC to GHC #34
        Fri Aug  4 18:20:57 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Massive patch for the first months work adding System FC to GHC #34
          Broken up massive patch -=chak
          Original log message:  
          This is (sadly) all done in one patch to avoid Darcs bugs.
          It's not complete work... more FC stuff to come.  A compiler
          using just this patch will fail dismally.
  24. 26 Jul, 2006 1 commit
  25. 18 Sep, 2006 1 commit
  26. 11 Aug, 2006 1 commit
  27. 07 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add -fextended-default-rules and -fmono-pat-binds · 6e0c3f50
      simonpj@microsoft.com authored
      Add -fextended-deafult-rules (in response to Don Stewart's message below),
      and document them.
      Also doucument -fmono-pat-binds/-fno-mono-pat-binds, which has been in 
      GHC a few weeks now. 
      (The two are in one patch because the diffs were so close together
      that Darcs combined them.)
      From: Donald Bruce Stewart [mailto:dons@cse.unsw.edu.au] 
      Sent: 07 August 2006 10:52
      While we're thinking about defaulting, I have a question..
      ghci uses an extended defaulting system, to allow things like:
              Prelude> reverse []
      to work, and to have the right instance of Show found. The manual says:
          "..it is tiresome for the user to have to specify the type, so GHCi extends
          Haskell's type-defaulting rules (Section 4.3.4 of the Haskell 98 Report
          (Revised)) as follows. If the expression yields a set of type constraints
          that are all from standard classes (Num, Eq etc.), and at least one is
          either a numeric class or the Show, Eq, or Ord class, GHCi will try to use
          one of the default types, just as described in the Report. The standard
          defaulting rules require that one of the classes is numeric; the difference
          here is that defaulting is also triggered at least one is Show, Eq, or Ord."
      Currently, there is no way to get at this "extended" defaulting for compiled
      modules. However, I have a use case for in fact doing this.
      With runtime evaluated Haskell, embedding 'interpreters' (over hs-plugins) is
      easy. lambdabot, for example, implements a sandboxed haskell eval system. But
      it doesn't have access to the defaulting mechanism of ghci, so we have:
          dons:: > reverse []
          lambdabot:: Add a type signature
          dons:: > reverse [] :: [()]
          lambdabot:: []
      Which is annoying -- newbies wonder why they have to add these extra
      constraints to get a Show instance.
      I'm wondering, since the extended defaulting mechanisms are already
      implemented, could they be made available to compiled modules as well,
      perhaps using a flag, -fextended-defaulting? 
  28. 27 Jul, 2006 1 commit
  29. 26 Jun, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Improve consistency checking for derived instances · 7f0ce617
      simonpj@microsoft.com authored
      This patch arranges that derived instances use the same instance-decl
      checking code as user-defined instances.  That gives greater consistency
      in error messages.
      Furthermore, the error description if this consistency check fails is now
      much more explicit.  For example, drvfail003 now says
           Variable occurs more often in a constraint than in the instance head
             in the constraint: Show (v (v a))
           (Use -fallow-undecidable-instances to permit this)
           In the derived instance
             instance (Show (v (v a))) => Show (Square_ v w a)
  30. 19 May, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Improved RULE lhs typechecking; less dictionary sharing · 5a8a219c
      simonpj@microsoft.com authored
      See long comment with Simplify.tcSimplifyRuleLhs.
      Here's the key example:
        RULE "g"  forall x y z. g (x == y) (y == z) = ...
      Here, the two dictionaries are *identical*, but we do NOT WANT to
      generate the rule
      RULE	forall x::a, y::a, z::a, d1::Eq a
      	  f ((==) d1 x y) ((>) d1 y z) = ...
      Instead we want
      RULE	forall x::a, y::a, z::a, d1::Eq a, d2:Eq a
      	  f ((==) d1 x y) ((>) d2 y z) = ...
  31. 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.
  32. 23 Feb, 2006 1 commit
  33. 13 Feb, 2006 1 commit