1. 17 Feb, 2003 2 commits
  2. 14 Feb, 2003 5 commits
    • panne's avatar
      [project @ 2003-02-14 19:21:57 by panne] · 5ee05a2b
      panne authored
      Not sure if this fix is correct, but at least this module compiles
      again...
      5ee05a2b
    • simonpj's avatar
      [project @ 2003-02-14 14:22:24 by simonpj] · 5538aeeb
      simonpj authored
      -------------------------------------
         Do the top-level tcSimpifyTop (to resolve monomorphic constraints)
         once for the whole program, rather than once per splice group
      	-------------------------------------
      
      This change makes the trivial program
      
      	main = return ()
      
      work again.  It had stopped working (emitting an error about Monad m
      being unconstrained) because the 'checkMain' stuff (which knows special
      things about 'main' was happening only *after* all the groups of
      decls in the module had been dealt with and zonked (incl tcSimplifyTop).
      
      Better to postpone.  A little more plumbing, but one fewer unexpected
      happenings.
      5538aeeb
    • simonpj's avatar
      [project @ 2003-02-14 14:19:29 by simonpj] · 580b4fe6
      simonpj authored
      Comments
      580b4fe6
    • simonpj's avatar
      [project @ 2003-02-14 14:19:15 by simonpj] · 9eb59090
      simonpj authored
      A bit more debug info + comments
      9eb59090
    • simonpj's avatar
      [project @ 2003-02-14 13:01:32 by simonpj] · 9d3463ad
      simonpj authored
      Fix for deriving of records with leading underscore, and corresponding lex
      9d3463ad
  3. 13 Feb, 2003 3 commits
  4. 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
  5. 11 Feb, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-02-11 11:53:51 by wolfgang] · 5819de0c
      wolfgang authored
      Mac OS X:
      Add support for dynamic linker "symbol stubs". For every function that might
      be imported from a dynamic library, we have to generate a short piece of
      assembly code.
      Extend the NatM monad to keep track of the list of imports (for which stubs
      will be generated later).
      Fix a bug concerning 64 bit ints (hi and low words were swapped in one place).
      5819de0c
  6. 08 Feb, 2003 1 commit
  7. 07 Feb, 2003 2 commits
  8. 06 Feb, 2003 6 commits
  9. 05 Feb, 2003 5 commits
  10. 04 Feb, 2003 8 commits
    • simonpj's avatar
      [project @ 2003-02-04 15:31:18 by simonpj] · 17777c53
      simonpj authored
      -------------------------------------
      	Fix a name-capture bug in Ext-Core
      	-------------------------------------
      
      Don't expand newtypes (even non-recursive ones) when going to External Core.
      Reason: the expansion was performed *after* Tidying; the expansion performs
      type substitution, which is only done right if you take account of the Uniques.
      But since it's post-tidying, we got capture of occurence names.
      
      I hope the lack of newtype expansion doesn't hurt anyone; I doubt it will.
      If so, we can think again.
      
      Thanks to Tobias Gedell for this one.
      17777c53
    • simonpj's avatar
      [project @ 2003-02-04 15:09:38 by simonpj] · 957bf375
      simonpj authored
      -------------------------------------
      	Remove all vestiges of usage analysis
      	-------------------------------------
      
      This commit removes a large blob of usage-analysis-related code, almost
      all of which was commented out.
      
      Sadly, it doesn't look as if Keith is going to have enough time to polish it
      up, and in any case the actual performance benefits (so far as we can measure
      them) turned out to be pretty modest (a few percent).
      
      So, with regret, I'm chopping it all out.  It's still there in the repository
      if anyone wants go hack on it.  And Tobias Gedell at Chalmers is implementing
      a different analysis, via External Core.
      957bf375
    • simonpj's avatar
      [project @ 2003-02-04 13:06:41 by simonpj] · e8f681e4
      simonpj authored
      ---------------------------------------------------
      			External Core fix
      	output implicit bindings in correct dependency order
      	---------------------------------------------------
      
      In coreSyn/MkExternalCore, output constructor wrappers before the
      other implicit bindings, because the latter may use the former.
      
      Thanks to Tobias Gedell for this one.
      e8f681e4
    • simonpj's avatar
      [project @ 2003-02-04 12:40:00 by simonpj] · 74775c6b
      simonpj authored
      Make utils/genprimopcode recognise the type ().
          It was previously written 'Unit', which is easily
          confused with the type 'Unit' (used for generic
          derived instances).
      74775c6b
    • simonpj's avatar
      [project @ 2003-02-04 12:33:05 by simonpj] · e6d00492
      simonpj authored
      ---------------------------------------------------
      	Template-Haskell fix to make the global environment
      		      more side-effect-ful
      	---------------------------------------------------
      
      Consider
      
      	f = $(...foldl...) $(...foldl...)
      
      The first splice sucks in the type sig for foldl, which the second
      splice needs.  That means that the second splice is going to have to
      consult the persistent compiler state to see the effect of imports
      by the first one.
      
      We used to cache the global type environment in the TcGblEnv, but
      this commit switches to the obvious thing: consult the persistent
      state on every global lookup.  After all, reading a MutVar is no
      big deal; and it's a benign, ever-growing cache of type signatures,
      so the side effect is fine.
      
      On the way I tidied up the knot-tying in TcIfaceSig a bit more.
      Previously, I think the setUnfoldingInfo was being strict in the
      unfolding, which forced it to be type-checked.  Now it's lazy.
      That could mean a lot less typechecking overall, for things whose
      unfolding isn't looked at.  I hope I havn't broken it, though.
      e6d00492
    • simonpj's avatar
      [project @ 2003-02-04 12:28:22 by simonpj] · 115f0fae
      simonpj authored
      ---------------------------------------------------
      	Important fix to the handling of class methods that
      	      mention their own class type variable
      	---------------------------------------------------
      
      [NB: I'm not 100% certain that this commit is independent of the
           Template-Haskell-related commit I'm doing at the same time.
           I've tried to separate them but may not have succeeded totally.]
      
      This bug gives utterly bogus (detected by Core Lint) programs.
      Isaac Jones discovered it.  Here's an example, now enshrined as tc165.
      
          class C a where
      	f :: (Eq a) => a
      
          instance C () where
      	f = f
      
      The instance decl was translated as
      
          dfC() = MkC (let f = \dEq -> f in f)
      
      which is utterly wrong.  Reason: the 'f' on the left was being treated
      as an available Inst, but it doesn't obey INVARIANT 2 for Insts, which
      is that they are applied to all their dictionaries.  (See the data type
      decl for Inst.)
      
      Solution: don't include such class methods in the available Insts.
      115f0fae
    • simonpj's avatar
      [project @ 2003-02-04 12:25:21 by simonpj] · 60beff5f
      simonpj authored
      Use nameIsLocalOrFrom instead of open code
      60beff5f
    • simonpj's avatar
      [project @ 2003-02-04 12:23:32 by simonpj] · 23a4e1f0
      simonpj authored
      Add type sig
      23a4e1f0
  11. 03 Feb, 2003 1 commit
  12. 25 Jan, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-01-25 15:54:48 by wolfgang] · af136096
      wolfgang authored
      This commit fixes many bugs and limitations in the threaded RTS.
      There are still some issues remaining, though.
      
      The following bugs should have been fixed:
      
      - [+] "safe" calls could cause crashes
      - [+] yieldToReturningWorker/grabReturnCapability
          -     It used to deadlock.
      - [+] couldn't wake blocked workers
          -     Calls into the RTS could go unanswered for a long time, and
                that includes ordinary callbacks in some circumstances.
      - [+] couldn't block on an MVar and expect to be woken up by a signal
            handler
          -     Depending on the exact situation, the RTS shut down or
                blocked forever and ignored the signal.
      - [+] The locking scheme in RtsAPI.c didn't work
      - [+] run_thread label in wrong place (schedule())
      - [+] Deadlock in GHC.Handle
          -     if a signal arrived at the wrong time, an mvar was never
                filled again
      - [+] Signals delivered to the "wrong" thread were ignored or handled
            too late.
      
      Issues:
      *) If GC can move TSO objects (I don't know - can it?), then ghci
      will occasionally crash when calling foreign functions, because the
      parameters are stored on the TSO stack.
      
      *) There is still a race condition lurking in the code
      (both threaded and non-threaded RTS are affected):
      If a signal arrives after the check for pending signals in
      schedule(), but before the call to select() in awaitEvent(),
      select() will be called anyway. The signal handler will be
      executed much later than expected.
      
      *) For Win32, GHC doesn't yet support non-blocking IO, so while a
      thread is waiting for IO, no call-ins can happen. If the RTS is
      blocked in awaitEvent, it uses a polling loop on Win32, so call-ins
      should work (although the polling loop looks ugly).
      
      *) Deadlock detection is disabled for the threaded rts, because I
      don't know how to do it properly in the presence of foreign call-ins
      from foreign threads.
      This causes the tests conc031, conc033 and conc034 to fail.
      
      *) "safe" is currently treated as "threadsafe". Implementing "safe" in
      a way that blocks other Haskell threads is more difficult than was
      thought at first. I think it could be done with a few additional lines
      of code, but personally, I'm strongly in favour of abolishing the
      distinction.
      
      *) Running finalizers at program termination is inefficient - there
      are two OS threads passing messages back and forth for every finalizer
      that is run. Also (just as in the non-threaded case) the finalizers
      are run in parallel to any remaining haskell threads and to any
      foreign call-ins that might still happen.
      af136096
  13. 24 Jan, 2003 3 commits
    • simonmar's avatar
      [project @ 2003-01-24 14:04:40 by simonmar] · b429adbb
      simonmar authored
      - Generalise seq to allow an unlifted type in its second argument.  This
        works because seq is *always* inlined and replaced by a case.
      
      - Remove getTag, a wired-in Id with an unfolding, with a definition
        in GHC.Base:
      
      	getTag x = x `seq` dataToTag# x
      
        this is why we required the above generalisation to seq (dataToTag#
        returns an Int#).  See the comments in GHC.Base for more details.
      
      - As a side-effect, this fixes a bug in the interpreter, where the
        compiler optimised away the evaluation of the argument to dataToTag#,
        but the interpreter ended up passing it an unevaluated thunk (nullary
        constructors aren't always evaluated in GHCi, but the simplifier
        assumes they are).  Now, in the interpreter, getTag won't be inlined
        so the compiler can't optimise away the evaluation, and we're saved.
      
        The real bug here is either (a) dataToTag# requires an evaluated
        argument or (b) the interpreter doesn't supply it with one, take your
        pick.
      b429adbb
    • 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
    • simonpj's avatar
      [project @ 2003-01-24 11:26:39 by simonpj] · 9ceeb6e5
      simonpj authored
      Perform 'tidying' on the implicit bindings before emitting
      	External Core.  We were getting silly bindings like
      		\ tpl -> case tpl of tpl -> (tpl,tpl) -> tpl
      
      	Maybe we should add these implicit bindings in CoreTidy,
      	rather than in both MkExternalCore and CorePrep?
      9ceeb6e5