1. 27 Nov, 2001 1 commit
  2. 26 Nov, 2001 4 commits
    • simonpj's avatar
      [project @ 2001-11-26 10:33:40 by simonpj] · 5a1ac8dc
      simonpj authored
      Complete previous tcAddImportedIdInfo commit
      5a1ac8dc
    • simonpj's avatar
      [project @ 2001-11-26 10:26:59 by simonpj] · 1fdd97b6
      simonpj authored
      --------------------------------------
      	Finally get rid of tcAddImportedIdInfo
      	--------------------------------------
      
      TcEnv.tcAddImportedIdInfo is a notorious source of space leaks.
      Simon M got rid of the need for it on default methods.
      This commit gets rid of the need for it for dictionary function Ids,
      and finally nukes the beast altogether. Hurrah!
      
      The change really involves putting tcInterfaceSigs *before*
      tcInstDecls1, so that any imported DFunIds are in the typechecker's
      environment before we get to tcInstDecls.
      1fdd97b6
    • simonpj's avatar
      [project @ 2001-11-26 09:22:05 by simonpj] · 0760818e
      simonpj authored
      Add missing files for Rank-N commit
      0760818e
    • simonpj's avatar
      [project @ 2001-11-26 09:20:25 by simonpj] · 5e3f005d
      simonpj authored
      ----------------------
      	Implement Rank-N types
      	----------------------
      
      This commit implements the full glory of Rank-N types, using
      the Odersky/Laufer approach described in their paper
      	"Putting type annotations to work"
      
      In fact, I've had to adapt their approach to deal with the
      full glory of Haskell (including pattern matching, and the
      scoped-type-variable extension).  However, the result is:
      
      * There is no restriction to rank-2 types.  You can nest forall's
        as deep as you like in a type.  For example, you can write a type
        like
      	p :: ((forall a. Eq a => a->a) -> Int) -> Int
        This is a rank-3 type, illegal in GHC 5.02
      
      * When matching types, GHC uses the cunning Odersky/Laufer coercion
        rules.  For example, suppose we have
      	q :: (forall c. Ord c => c->c) -> Int
        Then, is this well typed?
      	x :: Int
      	x = p q
        Yes, it is, but GHC has to generate the right coercion.  Here's
        what it looks like with all the big lambdas and dictionaries put in:
      
      	x = p (\ f :: (forall a. Eq a => a->a) ->
      		 q (/\c \d::Ord c -> f c (eqFromOrd d)))
      
        where eqFromOrd selects the Eq superclass dictionary from the Ord
        dicationary:		eqFromOrd :: Ord a -> Eq a
      
      
      * You can use polymorphic types in pattern type signatures.  For
        example:
      
      	f (g :: forall a. a->a) = (g 'c', g True)
      
        (Previously, pattern type signatures had to be monotypes.)
      
      * The basic rule for using rank-N types is that you must specify
        a type signature for every binder that you want to have a type
        scheme (as opposed to a plain monotype) as its type.
      
        However, you don't need to give the type signature on the
        binder (as I did above in the defn for f).  You can give it
        in a separate type signature, thus:
      
      	f :: (forall a. a->a) -> (Char,Bool)
      	f g = (g 'c', g True)
      
        GHC will push the external type signature inwards, and use
        that information to decorate the binders as it comes across them.
        I don't have a *precise* specification of this process, but I
        think it is obvious enough in practice.
      
      * In a type synonym you can use rank-N types too.  For example,
        you can write
      
      	type IdFun = forall a. a->a
      
      	f :: IdFun -> (Char,Bool)
      	f g = (g 'c', g True)
      
        As always, type synonyms must always occur saturated; GHC
        expands them before it does anything else.  (Still, GHC goes
        to some trouble to keep them unexpanded in error message.)
      
      
      The main plan is as before.  The main typechecker for expressions,
      tcExpr, takes an "expected type" as its argument.  This greatly
      improves error messages.  The new feature is that when this
      "expected type" (going down) meets an "actual type" (coming up)
      we use the new subsumption function
      	TcUnify.tcSub
      which checks that the actual type can be coerced into the
      expected type (and produces a coercion function to demonstrate).
      
      The main new chunk of code is TcUnify.tcSub.  The unifier itself
      is unchanged, but it has moved from TcMType into TcUnify.  Also
      checkSigTyVars has moved from TcMonoType into TcUnify.
      Result: the new module, TcUnify, contains all stuff relevant
      to subsumption and unification.
      
      Unfortunately, there is now an inevitable loop between TcUnify
      and TcSimplify, but that's just too bad (a simple TcUnify.hi-boot
      file).
      
      
      All of this doesn't come entirely for free.  Here's the typechecker
      line count (INCLUDING comments)
      	Before	16,551
      	After	17,116
      5e3f005d
  3. 23 Nov, 2001 3 commits
  4. 19 Nov, 2001 3 commits
    • simonpj's avatar
      [project @ 2001-11-19 16:34:12 by simonpj] · 53ce311e
      simonpj authored
      Tidy up imports
      53ce311e
    • simonpj's avatar
      [project @ 2001-11-19 16:33:17 by simonpj] · 615a5546
      simonpj authored
      Improve error msg
      615a5546
    • simonpj's avatar
      [project @ 2001-11-19 14:23:52 by simonpj] · d8af6b8c
      simonpj authored
      --------------------------------------
      	Yet another cut at the DmdAnal domains
      	--------------------------------------
      
      This version of the domain for demand analysis was developed
      in discussion with Peter Sestoft, so I think it might at last
      be more or less right!
      
      Our idea is mentally to separate
      	strictness analysis
      from
      	absence and boxity analysis
      
      Then we combine them back into a single domain.  The latter
      is all you see in the compiler (the Demand type, as before)
      but we understand it better now.
      d8af6b8c
  5. 08 Nov, 2001 1 commit
    • sof's avatar
      [project @ 2001-11-08 19:34:23 by sof] · 629b8c60
      sof authored
      gen_Eq_binds: when comparing constructor tags, emit just
      
         a == b = case con2tag_Foo# a of
                    a# -> case con2tag_Foo# b of b# -> a# PrelGHC.==# b#
      
      and not
      
         a == b = case con2tag_Foo# a of
                    a# -> case con2tag_Foo# b of
                            b# -> if a# PrelGHC.==# b# then PrelBase.True else PrelBase.False
      
      (Not that this wouldn't get simplified, but still).
      629b8c60
  6. 07 Nov, 2001 1 commit
  7. 05 Nov, 2001 1 commit
  8. 02 Nov, 2001 1 commit
  9. 31 Oct, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-10-31 16:17:59 by simonpj] · 317a1fd9
      simonpj authored
      Add hi-boot files for the new knot
      317a1fd9
    • simonpj's avatar
      [project @ 2001-10-31 15:22:53 by simonpj] · 61bfd5dd
      simonpj authored
      ------------------------------------------
      	Improved handling of scoped type variables
      	------------------------------------------
      
      The main effect of this commit is to allow scoped type variables
      in pattern bindings, thus
      
      	(x::a, y::b) = e
      
      This was illegal, but now it's ok.  a and b have the same scope
      as x and y.
      
      
      On the way I beefed up the info inside a type variable
      (TcType.TyVarDetails; c.f. IdInfo.GlobalIdDetails) which
      helps to improve error messages. Hence the wide ranging changes.
      Pity about the extra loop from Var to TcType, but can't be helped.
      61bfd5dd
  10. 25 Oct, 2001 3 commits
    • simonpj's avatar
      [project @ 2001-10-25 14:30:43 by simonpj] · d5f94cc1
      simonpj authored
      -------------------------------------------------------
        Correct an error in the handling of implicit parameters
        -------------------------------------------------------
      
      	MERGE WITH STABLE BRANCH UNLESS HARD TO DO
      
      Mark Shields discovered a bug in the way that implicit parameters
      are dealt with by the type checker.  It's all a bit subtle, and
      is extensively documented in TcSimplify.lhs.
      
      This commit makes the code both simpler and more correct.  It subtly
      changes the way in which type signatures are treated, but not in a way
      anyone would notice: see notes with "Question 2: type signatures"
      in TcSimplify.lhs.
      d5f94cc1
    • simonpj's avatar
      [project @ 2001-10-25 09:58:39 by simonpj] · 2007c7e6
      simonpj authored
      Cosmetica
      2007c7e6
    • sof's avatar
      [project @ 2001-10-25 02:13:10 by sof] · 9e933350
      sof authored
      - Pet peeve removal / code tidyup, replaced various sub-optimal
        uses of 'length' with something a bit better, i.e., replaced
        the following patterns
      
         *  length as `cmpOp` length bs
         *  length as `cmpOp` val   -- incl. uses where val == 1 and val == 0
         *  {take,drop,splitAt} (length as) bs
         *  length [ () | pat <- as ]
      
        with uses of misc Util functions.
      
        I'd be surprised if there's a noticeable reduction in running
        times as a result of these changes, but every little bit helps.
      
        [ The changes have been tested wrt testsuite/ - I'm seeing a couple
          of unexpected breakages coming from CorePrep, but I'm currently
          assuming that these are due to other recent changes. ]
      
      - compMan/CompManager.lhs: restored 4.08 compilability + some code
        cleanup.
      
      None of these changes are HEADworthy.
      9e933350
  11. 23 Oct, 2001 1 commit
    • sof's avatar
      [project @ 2001-10-23 22:25:46 by sof] · 1181f398
      sof authored
      Deleted HsVersions.h #defines that were now past their use-by-dates; in
      particular, make the assumption that a post-Haskell 1.4 compiler is now
      used to compile ghc/compiler/
      
      Hanging on to those FastString #defines is probably not worth it any longer,
      either, but I punted on making that (much bigger) change.
      1181f398
  12. 22 Oct, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-10-22 11:37:45 by simonpj] · 2c128fe8
      simonpj authored
      -------------------------------
      	Correct a nasty existential bug
      	-------------------------------
      
      	MERGE WITH STABLE BRANCH
      
      Thanks to Volker Stolz for finding this existential bug.
      Again, it's amazing that it hasn't shown up before.
      GHC 5.02 allows this utterly bogus program to get past
      the type checker
      
        data DS = forall a. C (a -> Int)
      
        call (C f) arg = f arg
      
      The existential-tyvar-escape check was wrong. Easily fixed, though.
      
      	tcfail099 now tests for this
      2c128fe8
  13. 19 Oct, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-10-19 10:04:37 by sewardj] · d7510542
      sewardj authored
      merge from stable, rev 1.105.4.1:
      
        When not compiling via C, catch Casms in the typecheck and reject
        them in a civilised way rather than having the various back ends barf.
      d7510542
  14. 18 Oct, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-10-18 16:29:12 by simonpj] · 685e04e4
      simonpj authored
      ----------------------------------------------
      	The CoreTidy/CorePrep/CoreToStg saga continues
      	[actually, this commit mostly completes the job]
      	----------------------------------------------
      
      			DO NOT MERGE!
      
      * CorePrep injects implicit bindings, not the type checker,
        nor CgConTbls.   (This way, all the code generators see
        them, so no need to fiddle with the byte code generator.)
      
        As a result, all bindings in the module are for LocalIds,
        at least until CoreTidy.   This is a Big Win.
      
        Hence remove nasty isImplicitId test in update_bndr in
        SimplCore and DmdAnal
      
      * hasNoBinding is no longer true of a dataConId (worker).
        There's an implicit curried binding for it.
      
      * Remove yukky test in exprIsTrivial that did not regard
        a hasNoBinding Id as trivial; similarly in SimplUtils.tryEtaReduce
      
      * In CoreTidy, get the names to avoid from the type env.
        That way it includes implicit bindings too.
      
      * CoreTidy set the Arity of a top-level Id permanently;
        it's up to the rest of the compiler to respect it.
        Notably, CorePrep uses etaExpand to make the manifest arity
        match the claimed arity.
      
      * As a result, nuke CgArity, so that CgInfo now contains only
        CafInfo.  The CafInfo is knot-tied as before.
      
      
      Other things
      
      * In Simplify.simplLazyBind, be a bit keener to float bindings
        out if it's a top-level binding.
      685e04e4
  15. 17 Oct, 2001 3 commits
  16. 26 Sep, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-09-26 16:19:28 by simonpj] · 6858f7c1
      simonpj authored
      ------------------
      		Simon's big commit
      		------------------
      	[ These files seem to have been left out for some reason ]
      
      
      This commit, which I don't think I can sensibly do piecemeal, consists
      of the things I've been doing recently, mainly directed at making
      Manuel, George, and Marcin happier with RULES.
      
      
      Reogranise the simplifier
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      1. The simplifier's environment is now an explicit parameter.  This
      makes it a bit easier to figure out where it is going.
      
      2. Constructor arguments can now be arbitrary expressions, except
      when the application is the RHS of a let(rec).  This makes it much
      easier to match rules like
      
      	RULES
      	    "foo"  f (h x, g y) = f' x y
      
      In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
      constructor application where necessary.  In the occurrence analyser,
      there's a new piece of context info (OccEncl) to say whether a
      constructor app is in a place where it should be in ANF.  (Unless
      it knows this it'll give occurrence info which will inline the
      argument back into the constructor app.)
      
      3. I'm experimenting with doing the "float-past big lambda" transformation
      in the full laziness pass, rather than mixed in with the simplifier (was
      tryRhsTyLam).
      
      4.  Arrange that
      	case (coerce (S,T) (x,y)) of ...
      will simplify.  Previous it didn't.
      A local change to CoreUtils.exprIsConApp_maybe.
      
      5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
      error function in one branch.
      
      
      Phase numbers, RULES, and INLINE pragmas
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1.  Phase numbers decrease from N towards zero (instead of increasing).
      This makes it easier to add new earlier phases, which is what users want
      to do.
      
      2.  RULES get their own phase number, N, and are disabled in phases before N.
      
      e.g. 	{-# RULES "foo" [2] forall x y.  f (x,y) = f' x y #-}
      
      Note the [2], which says "only active in phase 2 and later".
      
      3.  INLINE and NOINLINE pragmas have a phase number to.  This is now treated
      in just the same way as the phase number on RULE; that is, the Id is not inlined
      in phases earlier than N.  In phase N and later the Id *may* be inlined, and
      here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
      as soon as it *may* be inlined it probably *will* be inlined.
      
      The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
      like the RULES case (i.e. in square brackets).  This should also make sure
      you examine all such phase numbers; many will need to change now the numbering
      is reversed.
      
      Inlining Ids is no longer affected at all by whether the Id appears on the
      LHS of a rule.  Now it's up to the programmer to put a suitable INLINE/NOINLINE
      pragma to stop it being inlined too early.
      
      
      Implementation notes:
      
      *  A new data type, BasicTypes.Activation says when a rule or inline pragma
      is active.   Functions isAlwaysActive, isNeverActive, isActive, do the
      obvious thing (all in BasicTypes).
      
      * Slight change in the SimplifierSwitch data type, which led to a lot of
      simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.
      
      * The InlinePragma in the IdInfo of an Id is now simply an Activation saying
      when the Id can be inlined.  (It used to be a rather bizarre pair of a
      Bool and a (Maybe Phase), so this is much much easier to understand.)
      
      * The simplifier has a "mode" environment switch, replacing the old
      black list.  Unfortunately the data type decl has to be in
      CmdLineOpts, because it's an argument to the CoreDoSimplify switch
      
          data SimplifierMode = SimplGently | SimplPhase Int
      
      Here "gently" means "no rules, no inlining".   All the crucial
      inlining decisions are now collected together in SimplMonad
      (preInlineUnconditionally, postInlineUnconditionally, activeInline,
      activeRule).
      
      
      Specialisation
      ~~~~~~~~~~~~~~
      1.  Only dictionary *functions* are made INLINE, not dictionaries that
      have no parameters.  (This inline-dictionary-function thing is Marcin's
      idea and I'm still not sure whether it's a good idea.  But it's definitely
      a Bad Idea when there are no arguments.)
      
      2.  Be prepared to specialise an INLINE function: an easy fix in
      Specialise.lhs
      
      But there is still a problem, which is that the INLINE wins
      at the call site, so we don't use the specialised version anyway.
      I'm still unsure whether it makes sense to SPECIALISE something
      you want to INLINE.
      
      
      
      
      
      Random smaller things
      ~~~~~~~~~~~~~~~~~~~~~~
      
      * builtinRules (there was only one, but may be more) in PrelRules are now
        incorporated.   They were being ignored before...
      
      * OrdList.foldOL -->  OrdList.foldrOL, OrdList.foldlOL
      
      * Some tidying up of the tidyOpenTyVar, tidyTyVar functions.  I've
        forgotten exactly what!
      6858f7c1
    • simonpj's avatar
      [project @ 2001-09-26 15:12:33 by simonpj] · e0d750be
      simonpj authored
      ------------------
      		Simon's big commit
      		------------------
      
      This commit, which I don't think I can sensibly do piecemeal, consists
      of the things I've been doing recently, mainly directed at making
      Manuel, George, and Marcin happier with RULES.
      
      
      Reogranise the simplifier
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      1. The simplifier's environment is now an explicit parameter.  This
      makes it a bit easier to figure out where it is going.
      
      2. Constructor arguments can now be arbitrary expressions, except
      when the application is the RHS of a let(rec).  This makes it much
      easier to match rules like
      
      	RULES
      	    "foo"  f (h x, g y) = f' x y
      
      In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
      constructor application where necessary.  In the occurrence analyser,
      there's a new piece of context info (OccEncl) to say whether a
      constructor app is in a place where it should be in ANF.  (Unless
      it knows this it'll give occurrence info which will inline the
      argument back into the constructor app.)
      
      3. I'm experimenting with doing the "float-past big lambda" transformation
      in the full laziness pass, rather than mixed in with the simplifier (was
      tryRhsTyLam).
      
      4.  Arrange that
      	case (coerce (S,T) (x,y)) of ...
      will simplify.  Previous it didn't.
      A local change to CoreUtils.exprIsConApp_maybe.
      
      5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
      error function in one branch.
      
      
      Phase numbers, RULES, and INLINE pragmas
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1.  Phase numbers decrease from N towards zero (instead of increasing).
      This makes it easier to add new earlier phases, which is what users want
      to do.
      
      2.  RULES get their own phase number, N, and are disabled in phases before N.
      
      e.g. 	{-# RULES "foo" [2] forall x y.  f (x,y) = f' x y #-}
      
      Note the [2], which says "only active in phase 2 and later".
      
      3.  INLINE and NOINLINE pragmas have a phase number to.  This is now treated
      in just the same way as the phase number on RULE; that is, the Id is not inlined
      in phases earlier than N.  In phase N and later the Id *may* be inlined, and
      here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
      as soon as it *may* be inlined it probably *will* be inlined.
      
      The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
      like the RULES case (i.e. in square brackets).  This should also make sure
      you examine all such phase numbers; many will need to change now the numbering
      is reversed.
      
      Inlining Ids is no longer affected at all by whether the Id appears on the
      LHS of a rule.  Now it's up to the programmer to put a suitable INLINE/NOINLINE
      pragma to stop it being inlined too early.
      
      
      Implementation notes:
      
      *  A new data type, BasicTypes.Activation says when a rule or inline pragma
      is active.   Functions isAlwaysActive, isNeverActive, isActive, do the
      obvious thing (all in BasicTypes).
      
      * Slight change in the SimplifierSwitch data type, which led to a lot of
      simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.
      
      * The InlinePragma in the IdInfo of an Id is now simply an Activation saying
      when the Id can be inlined.  (It used to be a rather bizarre pair of a
      Bool and a (Maybe Phase), so this is much much easier to understand.)
      
      * The simplifier has a "mode" environment switch, replacing the old
      black list.  Unfortunately the data type decl has to be in
      CmdLineOpts, because it's an argument to the CoreDoSimplify switch
      
          data SimplifierMode = SimplGently | SimplPhase Int
      
      Here "gently" means "no rules, no inlining".   All the crucial
      inlining decisions are now collected together in SimplMonad
      (preInlineUnconditionally, postInlineUnconditionally, activeInline,
      activeRule).
      
      
      Specialisation
      ~~~~~~~~~~~~~~
      1.  Only dictionary *functions* are made INLINE, not dictionaries that
      have no parameters.  (This inline-dictionary-function thing is Marcin's
      idea and I'm still not sure whether it's a good idea.  But it's definitely
      a Bad Idea when there are no arguments.)
      
      2.  Be prepared to specialise an INLINE function: an easy fix in
      Specialise.lhs
      
      But there is still a problem, which is that the INLINE wins
      at the call site, so we don't use the specialised version anyway.
      I'm still unsure whether it makes sense to SPECIALISE something
      you want to INLINE.
      
      
      
      
      
      Random smaller things
      ~~~~~~~~~~~~~~~~~~~~~~
      
      * builtinRules (there was only one, but may be more) in PrelRules are now
        incorporated.   They were being ignored before...
      
      * OrdList.foldOL -->  OrdList.foldrOL, OrdList.foldlOL
      
      * Some tidying up of the tidyOpenTyVar, tidyTyVar functions.  I've
        forgotten exactly what!
      e0d750be
  17. 07 Sep, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-09-07 12:44:30 by simonpj] · 991a868b
      simonpj authored
      ----------------------------------------
      	Make dict funs and default methods
      	into LocalIds only at their binding site
      	----------------------------------------
              [part of 3 related commits]
      
      There's a long comment about this with MkId.mkDefaultMethodId,
      which I reproduce below.
      
      While I was at it, I renamed setIdNoDiscard to setIdLocalExported.
      Which is hardly an improvement, I'm afraid.  This renaming touches
      	Var.lhs, Id.lhs, SimplCore.lhs
      in a trivial way.
      
      	---------------------
      
      Dict funs and default methods are *not* ImplicitIds.  Their definition
      involves user-written code, so we can't figure out their strictness etc
      based on fixed info, as we can for constructors and record selectors (say).
      
      We build them as GlobalIds, but when in the module where they are
      bound, we turn the Id at the *binding site* into an exported LocalId.
      This ensures that they are taken to account by free-variable finding
      and dependency analysis (e.g. CoreFVs.exprFreeVars).   The simplifier
      will propagate the LocalId to all occurrence sites.
      
      Why shouldn't they be bound as GlobalIds?  Because, in particular, if
      they are globals, the specialiser floats dict uses above their defns,
      which prevents good simplifications happening.  Also the strictness
      analyser treats a occurrence of a GlobalId as imported and assumes it
      contains strictness in its IdInfo, which isn't true if the thing is
      bound in the same module as the occurrence.
      
      It's OK for dfuns to be LocalIds, because we form the instance-env to
      pass on to the next module (md_insts) in CoreTidy, afer tidying
      and globalising the top-level Ids.
      
      BUT make sure they are *exported* LocalIds (setIdLocalExported) so
      that they aren't discarded by the occurrence analyser.
      991a868b
    • simonpj's avatar
      [project @ 2001-09-07 12:34:03 by simonpj] · b8711eeb
      simonpj authored
      -------------------
      	Newtypes and ccalls
      	     [addendum]
      	-------------------
      
      	MERGE WITH STABLE BRANCH
      
      I accidentally omitted these two wibbles from my previous commit.
      I've added PrelNames.unitTyConKey, and used it in TcType and DsCCall.
      b8711eeb
  18. 06 Sep, 2001 3 commits
  19. 04 Sep, 2001 1 commit
    • ken's avatar
      [project @ 2001-09-04 18:22:34 by ken] · c00aaade
      ken authored
      On the Alpha we can only handle <= 4 integer arguments with foreign export
      dynamic.  Following the example of the corresponding Sparc hack, we detect
      when we're being asked to do something we can't and refuse.
      
      MERGE TO STABLE BRANCH
      c00aaade
  20. 28 Aug, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-08-28 10:06:29 by simonpj] · b0604aad
      simonpj authored
      ----------------------------------------
      	Make isFFIArgumentTy understand newtypes
      	----------------------------------------
      
      This fixes the bug Manuel reported:
      
      	newtype T = T (Ptr T)
      	foreign import ccall foo :: T -> IO (Ptr T)
      
        test.hs:6:
            Unacceptable argument type in foreign declaration: T
      
      
      On the way, I moved isFFIArgumentTy and friends out of TysWiredIn,
      where they didn't really belong, into TcType.  That in turn force
      me to move isStrictType, and isPrimitiveType.
      b0604aad
    • simonpj's avatar
      [project @ 2001-08-28 10:03:23 by simonpj] · ad6bc60d
      simonpj authored
      Add pprEquation
      ad6bc60d
  21. 24 Aug, 2001 2 commits
  22. 23 Aug, 2001 1 commit