1. 08 Feb, 2006 1 commit
    • Simon Marlow's avatar
      make the smp way RTS-only, normal libraries now work with -smp · beb5737b
      Simon Marlow authored
      We had to bite the bullet here and add an extra word to every thunk,
      to enable running ordinary libraries on SMP.  Otherwise, we would have
      needed to ship an extra set of libraries with GHC 6.6 in addition to
      the two sets we already ship (normal + profiled), and all Cabal
      packages would have to be compiled for SMP too.  We decided it best
      just to take the hit now, making SMP easily accessible to everyone in
      GHC 6.6.
      
      Incedentally, although this increases allocation by around 12% on
      average, the performance hit is around 5%, and much less if your inner
      loop doesn't use any laziness.
      beb5737b
  2. 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
  3. 28 Apr, 2005 2 commits
  4. 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
  5. 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
  6. 25 Feb, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-02-25 13:06:31 by simonpj] · 8e67f550
      simonpj authored
      ---------------------------------------------
      Type signatures are no longer instantiated with skolem constants
      	---------------------------------------------
      
      	Merge to STABLE
      
      Consider
      
        p :: a
        q :: b
        (p,q,r) = (r,r,p)
      
      Here, 'a' and 'b' end up being the same, because they are both bound
      to the type for 'r', which is just a meta type variable.  So 'a' and 'b'
      can't be skolems.
      
      Sigh.  This commit goes back to an earlier way of doing things, by
      arranging that type signatures get instantiated with *meta* type
      variables; then at the end we must check that they have not been
      unified with types, nor with each other.
      
      This is a real bore.  I had to do quite a bit of related fiddling around
      to make error messages come out right.  Improved one or two.
      
      Also a small unrelated fix to make
      	:i (:+)
      print with parens in ghci.  Sorry this got mixed up in the same commit.
      8e67f550
  7. 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
  8. 07 Sep, 2004 1 commit
  9. 19 Aug, 2004 1 commit
  10. 17 Aug, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-08-17 15:23:47 by simonpj] · 59c796f8
      simonpj authored
      -------------------------------
      	Use merge-sort not quicksort
      	Nuke quicksort altogether
      	-------------------------------
      
      Quicksort has O(n**2) behaviour worst case, and this occasionally bites.
      In particular, when compiling large files consisting only of static data,
      we get loads of top-level delarations -- and that led to more than half the
      total compile time being spent in the strongly connected component analysis
      for the occurrence analyser.  Switching to merge sort completely solved the
      problem.
      
      I've nuked quicksort altogether to make sure this does not happen again.
      59c796f8
  11. 13 Aug, 2004 1 commit
  12. 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
  13. 30 Oct, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-10-30 16:01:49 by simonpj] · 57573e7e
      simonpj authored
      This commit does a long-overdue tidy-up
      
      * Remove PprType (gets rid of one more bunch of hi-boot files)
      
      * Put pretty-printing for types in TypeRep
      
      * Make a specialised pretty-printer for Types, rather than
        converting to IfaceTypes and printing those
      57573e7e
  14. 16 Sep, 2003 1 commit
  15. 02 Jul, 2003 1 commit
  16. 22 May, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-05-22 10:53:53 by simonmar] · d0b1c1cd
      simonmar authored
      Fix obscure bug in GHCi: when generating code for tag2enum#, we were
      wrongly using the source name for the DataCons rather than the worker
      name, which lead to spurious link errors.
      
      This fixes galois_raytrace(ghci).
      d0b1c1cd
  17. 14 May, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-05-14 09:13:52 by simonmar] · 7a236a56
      simonmar authored
      Change the way SRTs are represented:
      
      Previously, the SRT associated with a function or thunk would be a
      sub-list of the enclosing top-level function's SRT.  But this approach
      can lead to lots of duplication: if a CAF is referenced in several
      different thunks, then it may appear several times in the SRT.
      Let-no-escapes compound the problem, because the occurrence of a
      let-no-escape-bound variable would expand to all the CAFs referred to
      by the let-no-escape.
      
      The new way is to describe the SRT associated with a function or thunk
      as a (pointer+offset,bitmap) pair, where the pointer+offset points
      into some SRT table (the enclosing function's SRT), and the bitmap
      indicates which entries in this table are "live" for this closure.
      The bitmap is stored in the 16 bits previously used for the length
      field, but this rarely overflows.  When it does overflow, we store the
      bitmap externally in a new "SRT descriptor".
      
      Now the enclosing SRT can be a set, hence eliminating the duplicates.
      
      Also, we now have one SRT per top-level function in a recursive group,
      where previously we used to have one SRT for the whole group.  This
      helps keep the size of SRTs down.
      
      Bottom line: very little difference most of the time.  GHC itself got
      slightly smaller.  One bad case of a module in GHC which had a huge
      SRT has gone away.
      
      While I was in the area:
      
        - Several parts of the back-end require bitmaps.  Functions for
          creating bitmaps are now centralised in the Bitmap module.
      
        - We were trying to be independent of word-size in a couple of
          places in the back end, but we've now abandoned that strategy so I
          simplified things a bit.
      7a236a56
  18. 28 Mar, 2003 1 commit
    • sof's avatar
      [project @ 2003-03-28 01:59:05 by sof] · a5687b3b
      sof authored
      Off-by-one tidyup.
      
      ALLOC_AP, ALLOC_PAP and MKAP were all being constructed
      with size arguments equal to (1+number of args/FVs) in
      ByteCodeGen.schemeE, only for Interpreter.c to subtract 1
      when fishing out the payloads. This commit drops the
      up-and-downery.
      
      Simplification spotted by Andy Moran
      a5687b3b
  19. 27 Mar, 2003 1 commit
    • sof's avatar
      [project @ 2003-03-27 17:59:09 by sof] · 6da62425
      sof authored
      NCG support for f.e.d. stdcall -- Literal.MachLabels now optionally carry
      the size (in bytes) of the stack frame it expects, if known. That just
      so happens to match what stdcall labels need to be annotated with when
      emitting them in the NCG..
      6da62425
  20. 03 Mar, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-03-03 12:43:31 by simonmar] · 19108ede
      simonmar authored
      A round of space-leak fixing.
      
        - re-instate zapping of the PersistentCompilerState at various
          points during the compilation cycle in HscMain.  This affects
          one-shot compilation only, since in this mode the information
          collected in the PCS is not required after creating the final
          interface file.
      
        - Unravel the recursive dependency between MkIface and
          CoreTidy/CoreToStg.  Previously the CafInfo for each binding was
          calculated by CoreToStg, and fed back into the IdInfo of the Ids
          generated by CoreTidy (an earlier pass).  MkIface then took this
          IdInfo and the bindings from CoreTidy to generate the interface;
          but it couldn't do this until *after* CoreToStg, because the CafInfo
          hadn't been calculated yet.  The result was that the CoreTidy
          output lived until after CoreToStg, and at the same time as the
          CorePrep and STG syntax, which is wasted space, not to mention
          the complexity and general ugliness in HscMain.
      
          So now we calculate CafInfo directly in CoreTidy.  The downside is
          that we have to predict what CorePrep is going to do to the
          bindings so we can tell what will turn into a CAF later, but it's
          no worse than before (it turned out that we were doing this
          prediction before in CoreToStg anyhow).
      
        - The typechecker lazilly typechecks unfoldings.  It turns out that
          this is a good idea from a performance perspective, but it also
          means that it must hang on to all the information it needs to
          do the typechecking.  Previously this meant holding on to the
          whole of the typechecker's environment, which includes all sorts
          of stuff which isn't necessary to typecheck unfoldings.  By paring
          down the environment captured by the lazy unfoldings, we can
          save quite a bit of space in the phases after typechecking.
      19108ede
  21. 17 Feb, 2003 1 commit
  22. 12 Feb, 2003 2 commits
    • simonpj's avatar
      [project @ 2003-02-12 17:57:34 by simonpj] · 0c56ef64
      simonpj authored
      A wibble to the constructor-naming story
      0c56ef64
    • simonpj's avatar
      [project @ 2003-02-12 15:01:31 by simonpj] · 42b63073
      simonpj authored
      -------------------------------------
        Big upheaval to the way that constructors are named
      	-------------------------------------
      
      This commit enshrines the new story for constructor names.  We could never
      really get External Core to work nicely before, but now it does.
      
      The story is laid out in detail in the Commentary
      	ghc/docs/comm/the-beast/data-types.html
      so I will not repeat it here.
      
      	[Manuel: the commentary isn't being updated, apparently.]
      
      However, the net effect is that in Core and in External Core, contructors look
      like constructors, and the way things are printed is all consistent.
      
      It is a fairly pervasive change (which is why it has been so long postponed),
      but I hope the question is now finally closed.
      
      All the libraries compile etc, and I've run many tests, but doubtless there will
      be some dark corners.
      42b63073
  23. 24 Jan, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-01-24 13:56:45 by simonmar] · 519c3db4
      simonmar authored
      - Reverse the code for workers and wrappers for nullary constructors.
        For some reason it was the wrong way around, but the effects were
        harmless since they both evaluate to the same thing.
      
      - When passing a nullary constructor as an argument, we should pass
        the name of the worker rather than the wrapper.  Again, this is
        mostly harmless, but it enables some small simplification in
        pushAtom.
      
      - Rearrange/cleanup pushAtom.
      519c3db4
  24. 10 Jan, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-01-10 16:33:49 by simonmar] · c3fb6ff1
      simonmar authored
      Changes to the way stack checks are handled in GHCi, to fix a rare bug
      when a stack check fails in a BCO.
      
      We now aggregate all stack use from case alternatives up to the
      enclosing function/thunk BCO, and do a single stack check at the
      beginning of that BCO.  This simplifies the stack check failure code,
      because it doesn't have to cope with the case when a case alternative
      needs to restart.
      
      We still employ the trick of doing a fixed stack check before every
      BCO, only inserting an actual stack check instruction in the BCO if it
      needs more stack than this fixed amount.  The fixed stack check is now
      only done before running a function/thunk BCO.
      c3fb6ff1
  25. 09 Jan, 2003 2 commits
    • simonpj's avatar
      [project @ 2003-01-09 16:11:03 by simonpj] · 08c45040
      simonpj authored
      Wibble
      08c45040
    • simonpj's avatar
      [project @ 2003-01-09 15:42:27 by simonpj] · dc7c699d
      simonpj authored
      ---------------------------------------
      	Improvements to the byte-code generator
      	---------------------------------------
      
      1. The schemeR call in coreExprToBCOs was bogusly passing a bunch of free
         variables, when the set should always be empty. As a result, compiling
         an expression with an unbound free variable (e.g. 'x + 1', where 'x' is
         entirely unbound) succeeded, expecting 'x' to be passed on the stack,
         which of course it won't be.
      
         This bug only shows up if an earlier stage of the compiler goes wrong,
         but fixing turns a seg-fault into a more graceful failure.
      
      2. Make schemeE allocate non-recursive constructors directly.
      
      3. Lots of general tidying up.  Result is 50 lines shorter than before.
      dc7c699d
  26. 18 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-18 11:17:15 by simonmar] · 9ae23eae
      simonmar authored
      Correctly describe the stack during a GHCi CCALL instruction to the
      RTS.  The previous hack, temporarily truncating the stack to the
      topmost valid stack frame, didn't work because stack-squeezing tends
      to move the stack around before the call.
      
      The right thing to do is correctly describe the chunk of ccall args
      with an info table, which is what this change does.  We use a RET_DYN
      info table with the number of non-ptrs from the CCALL instruction.
      9ae23eae
  27. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      ------------------------------------------
      
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
      
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
      
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
      
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
      
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
      
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
      
        - Info tables are a bit more complicated.  See InfoTables.h for the
          details.
      
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
          fixed.
      
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
      
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
      0bffc410
  28. 11 Nov, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-11-11 10:58:40 by simonpj] · d0829767
      simonpj authored
      ------------------
        	Improve byte-code compilation of unboxed
      	 	tuple returns
      		------------------
      
      The previous byte-code for returning unboxed tuples was just wrong.  It's
      a special case for the situation where we return (# s, x #), where s is
      a state token, so we can just return the single result 'x' on top of the
      stack.  Previously we generated an ENTER at the end, which is plain wrong.
      We should RETURN.
      
      It still doesn't work, for other tiresome reasons...but rather than fix it
      we'll wait for eval-apply.  Meanwhile it's less wrong than before.
      d0829767
  29. 13 Sep, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-09-13 15:02:25 by simonpj] · 9af77fa4
      simonpj authored
      --------------------------------------
      	Make Template Haskell into the HEAD
      	--------------------------------------
      
      This massive commit transfers to the HEAD all the stuff that
      Simon and Tim have been doing on Template Haskell.  The
      meta-haskell-branch is no more!
      
      WARNING: make sure that you
      
        * Update your links if you are using link trees.
          Some modules have been added, some have gone away.
      
        * Do 'make clean' in all library trees.
          The interface file format has changed, and you can
          get strange panics (sadly) if GHC tries to read old interface files:
          e.g.  ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
      	  Binary.get(TyClDecl): ForeignType
      
        * You need to recompile the rts too; Linker.c has changed
      
      
      However the libraries are almost unaltered; just a tiny change in
      Base, and to the exports in Prelude.
      
      
      NOTE: so far as TH itself is concerned, expression splices work
      fine, but declaration splices are not complete.
      
      
      		---------------
      		The main change
      		---------------
      
      The main structural change: renaming and typechecking have to be
      interleaved, because we can't rename stuff after a declaration splice
      until after we've typechecked the stuff before (and the splice
      itself).
      
      * Combine the renamer and typecheker monads into one
      	(TcRnMonad, TcRnTypes)
        These two replace TcMonad and RnMonad
      
      * Give them a single 'driver' (TcRnDriver).  This driver
        replaces TcModule.lhs and Rename.lhs
      
      * The haskell-src library package has a module
      	Language/Haskell/THSyntax
        which defines the Haskell data type seen by the TH programmer.
      
      * New modules:
      	hsSyn/Convert.hs 	converts THSyntax -> HsSyn
      	deSugar/DsMeta.hs 	converts HsSyn -> THSyntax
      
      * New module typecheck/TcSplice type-checks Template Haskell splices.
      
      		-------------
      		Linking stuff
      		-------------
      
      * ByteCodeLink has been split into
      	ByteCodeLink	(which links)
      	ByteCodeAsm	(which assembles)
      
      * New module ghci/ObjLink is the object-code linker.
      
      * compMan/CmLink is removed entirely (was out of place)
        Ditto CmTypes (which was tiny)
      
      * Linker.c initialises the linker when it is first used (no need to call
        initLinker any more).  Template Haskell makes it harder to know when
        and whether to initialise the linker.
      
      
      	-------------------------------------
      	Gathering the LIE in the type checker
      	-------------------------------------
      
      * Instead of explicitly gathering constraints in the LIE
      	tcExpr :: RenamedExpr -> TcM (TypecheckedExpr, LIE)
        we now dump the constraints into a mutable varabiable carried
        by the monad, so we get
      	tcExpr :: RenamedExpr -> TcM TypecheckedExpr
      
        Much less clutter in the code, and more efficient too.
        (Originally suggested by Mark Shields.)
      
      
      		-----------------
      		Remove "SysNames"
      		-----------------
      
      Because the renamer and the type checker were entirely separate,
      we had to carry some rather tiresome implicit binders (or "SysNames")
      along inside some of the HsDecl data structures.  They were both
      tiresome and fragile.
      
      Now that the typechecker and renamer are more intimately coupled,
      we can eliminate SysNames (well, mostly... default methods still
      carry something similar).
      
      		-------------
      		Clean up HsPat
      		-------------
      
      One big clean up is this: instead of having two HsPat types (InPat and
      OutPat), they are now combined into one.  This is more consistent with
      the way that HsExpr etc is handled; there are some 'Out' constructors
      for the type checker output.
      
      So:
      	HsPat.InPat	--> HsPat.Pat
      	HsPat.OutPat	--> HsPat.Pat
      	No 'pat' type parameter in HsExpr, HsBinds, etc
      
      	Constructor patterns are nicer now: they use
      		HsPat.HsConDetails
      	for the three cases of constructor patterns:
      		prefix, infix, and record-bindings
      
      	The *same* data type HsConDetails is used in the type
      	declaration of the data type (HsDecls.TyData)
      
      Lots of associated clean-up operations here and there.  Less code.
      Everything is wonderful.
      9af77fa4
  30. 03 Sep, 2002 1 commit
  31. 06 Aug, 2002 1 commit
  32. 01 Aug, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-08-01 14:34:42 by simonpj] · 5b868c3b
      simonpj authored
      Make the byte-code generator understand about unboxed
      tuple returns.  The previous code was just wrong.
      
      This code is better but it is still not *right*, I fear.
      Don't merge till we sort this out.
      5b868c3b
  33. 10 May, 2002 1 commit
  34. 29 Apr, 2002 2 commits
    • panne's avatar
      [project @ 2002-04-29 18:42:03 by panne] · a3f306d5
      panne authored
      (F)SLIT fixes, continued...
      a3f306d5
    • simonmar's avatar
      [project @ 2002-04-29 14:03:38 by simonmar] · b085ee40
      simonmar authored
      FastString cleanup, stage 1.
      
      The FastString type is no longer a mixture of hashed strings and
      literal strings, it contains hashed strings only with O(1) comparison
      (except for UnicodeStr, but that will also go away in due course).  To
      create a literal instance of FastString, use FSLIT("..").
      
      By far the most common use of the old literal version of FastString
      was in the pattern
      
      	  ptext SLIT("...")
      
      this combination still works, although it doesn't go via FastString
      any more.  The next stage will be to remove the need to use this
      special combination at all, using a RULE.
      
      To convert a FastString into an SDoc, now use 'ftext' instead of
      'ptext'.
      
      I've also removed all the FAST_STRING related macros from HsVersions.h
      except for SLIT and FSLIT, just use the relevant functions from
      FastString instead.
      b085ee40
  35. 05 Apr, 2002 1 commit
  36. 02 Apr, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-04-02 12:22:37 by simonmar] · 0fd760c2
      simonmar authored
      oops, accidentally committed some untested (and non-working) cleanups
      in the last commit.  This commit fixes it up again.
      
      (fixes the ByteCodeGen panic in GHCi on the HEAD)
      0fd760c2