1. 11 Jan, 2006 4 commits
  2. 10 Jan, 2006 8 commits
  3. 09 Jan, 2006 14 commits
  4. 06 Jan, 2006 2 commits
    • 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
        - 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.
    • simonmar's avatar
      [project @ 2006-01-06 11:04:07 by simonmar] · 2a2efb72
      simonmar authored
      Document -Rghc-timing
  5. 05 Jan, 2006 3 commits
    • simonpj's avatar
      [project @ 2006-01-05 13:10:55 by simonpj] · dd45134b
      simonpj authored
      This commit fixes a nasty problem discovered by Volker Stolz.
      The problem is described in Note [Multiple instantiation] in
      TcExpr, which is reproduced below.
      (Core Lint identifies the problem, incidentally.)
      tc200 is a test case.
      Note [Multiple instantiation]
      We are careful never to make a MethodInst that has, as its meth_id, another MethodInst.
      For example, consider
      	f :: forall a. Eq a => forall b. Ord b => a -> b
      At a call to f, at say [Int, Bool], it's tempting to translate the call to
      	f_m1 :: forall b. Ord b => Int -> b
      	f_m1 = f Int dEqInt
      	f_m2 :: Int -> Bool
      	f_m2 = f_m1 Bool dOrdBool
      But notice that f_m2 has f_m1 as its meth_id.  Now the danger is that if we do
      a tcSimplCheck with a Given f_mx :: f Int dEqInt, we may make a binding
      	f_m1 = f_mx
      But it's entirely possible that f_m2 will continue to float out, because it
      mentions no type variables.  Result, f_m1 isn't in scope.
      Here's a concrete example that does this (test tc200):
          class C a where
            f :: Eq b => b -> a -> Int
            baz :: Eq a => Int -> a -> Int
          instance C Int where
            baz = f
      Current solution: only do the "method sharing" thing for the first type/dict
      application, not for the iterated ones.  A horribly subtle point.
    • simonpj's avatar
      [project @ 2006-01-05 10:02:58 by simonpj] · 82e428eb
      simonpj authored
      'newtype' declarations are now parsed exactly like data type declarations,
      so that you can declare newtypes using GADT syntax.  But that means we
      must check all the newtype restrictions separately, and I mised one.
      This commit checks that there is no existential context on the newtype.
      Test is tcfail156
    • simonmar's avatar
      [project @ 2006-01-05 09:42:54 by simonmar] · acc7c961
      simonmar authored
      This file is not quite POSIX compliant; hopefully fix build on MacOS X
  6. 04 Jan, 2006 3 commits
  7. 03 Jan, 2006 6 commits