1. 14 Aug, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-08-14 15:37:55 by simonpj] · 2b09da89
      simonpj authored
      Wibbles to the checking-types commit
      2b09da89
    • simonpj's avatar
      [project @ 2001-08-14 06:35:56 by simonpj] · 2767767f
      simonpj authored
      1. Arrange that w/w records unfoldings
         And that the simplifier preserves them
      
      2. Greatly improve structure of checking user types in the typechecker
         Main changes:
      	TcMType.checkValidType checks for a valid type
      	TcMonoType.tcHsSigType uses checkValidType
      	Type and class decls use TcMonoType.tcHsType (which does not
      		check for validity) inside the knot in TcTyClsDecls,
      		and then runs TcTyDecls.checkValidTyCon
      		or TcClassDcl.checkValidClass to check for validity
      		once the knot is tied
      2767767f
  2. 07 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-07 09:16:15 by sewardj] · 0632467a
      sewardj authored
      This buffer is for notes you don't want to save, and for Lisp evaluation.
      If you want to create a file, visit that file with C-x C-f,
      then enter the text in that file's own buffer.
      
      Interpreter FFI improvements:
      
      * Support f-i dynamic.
      * Correctly handle fns which don't return anything.
      * Support x86 stdcall call-conv.
      
      Clean-up of FFI-related code in ByteCodeGen.lhs.
      0632467a
  3. 02 Aug, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-08-02 17:15:16 by sewardj] · 54afa8cb
      sewardj authored
      Haskell-side support for FFI (foreign import only).
      
      Since doing the FFI necessarily involves gruesome
      architecture-specific knowledge about calling conventions, I have
      chosen to put this knowledge in Haskell-land, in ByteCodeFFI.
      
      The general idea is: to do a ccall, the interpreter accumulates the
      args R to L on the stack, as is the normal case for tail-calls.
      However, it then calls a piece of machine code created by ByteCodeFFI
      and which is specific to this call site.  This glue code copies args
      off the Haskell stack, calls the target function, and places the
      result back into a dummy placeholder created on the Haskell stack
      prior to the call.  The interpreter then SLIDEs and RETURNs in the
      normal way.
      
      The magic glue code copies args off the Haskell stack and pushes them
      directly on the C stack (x86) and/or into regs (sparc et al).  Because
      the code is made up specifically for this call site, it can do all
      that non-interpretively.  The address (of the C fn to call) is
      presented as just another tagged Addr# on the Haskell stack.  This
      makes f-i-dynamic trivial since the first arg is the said Addr#.
      
      Presently ByteCodeFFI only knows how to generate x86 code sequences.
      54afa8cb
  4. 25 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-25 15:55:30 by simonpj] · 7fde87b3
      simonpj authored
      -----------------------------------------
      	Fix a bug in the monomorphism restriction
      	------------------------------------------
      
      Thanks for Koen for reporting this bug.
      
      In tcSimplifyRestricted, I wrongly called tcSimpifyToDicts,
      whereas actually we have to simplfy further than simply to
      a dictionary.
      
      The test for this is in typecheck/should_compile/tc132.hs
      7fde87b3
  5. 23 Jul, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-07-23 10:54:46 by simonpj] · f6cd95ff
      simonpj authored
      ---------------------------------
      	Switch to the new demand analyser
      	---------------------------------
      
      This commit makes the new demand analyser the main beast,
      with the old strictness analyser as a backup.  When
      DEBUG is on, the old strictness analyser is run too, and the
      results compared.
      
      WARNING: this isn't thorougly tested yet, so expect glitches.
      Delay updating for a few days if the HEAD is mission critical
      for you.
      
      But do try it out.  I'm away for 2.5 weeks from Thursday, so
      it would be good to shake out any glaring bugs before then.
      f6cd95ff
    • simonpj's avatar
      [project @ 2001-07-23 10:24:57 by simonpj] · b20ad447
      simonpj authored
      Yet another newtype-squashing bug; this time TcType.unifyTyX
      b20ad447
  6. 20 Jul, 2001 3 commits
    • simonpj's avatar
      [project @ 2001-07-20 16:48:20 by simonpj] · 5d095cc1
      simonpj authored
      This commit adds the very convenient function
      
        Subst.substTyWith :: [TyVar] -> [Type] -> Type -> Type
      
      and uses it in various places.
      5d095cc1
    • simonpj's avatar
      [project @ 2001-07-20 16:47:55 by simonpj] · e3defabc
      simonpj authored
      ------------------------
      	More newtype squashing
      	------------------------
      
      Recursive newtypes were confusing the worker/wrapper generator.
      This is because I originally got rid of opaque newtypes altogether,
      then put them back for recursive ones only, and forgot to reinstate
      the cunning stuff in the w/w stuff.
      
      (Discovered by Sigbjorn; thanks!)
      e3defabc
    • simonpj's avatar
      [project @ 2001-07-20 15:22:21 by simonpj] · 0fa26afe
      simonpj authored
      -----------------------
      	Get rid of ArityAtLeast
      	-----------------------
      
      Now that we have CgInfo, with the exact code-generator arity
      for the value, we don't need the distinction between ArityAtLeast
      and ArityExactly in the ArityInfo field of an IdInfo.
      
      This commit makes
      
      	type ArityInfo = Maybe Arity
      
      and propagates this change consistently through the compiler.
      0fa26afe
  7. 17 Jul, 2001 1 commit
  8. 13 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-13 13:29:56 by simonpj] · d4e38936
      simonpj authored
      ------------------------------------
      	Tidy up the "syntax rebinding" story
      	------------------------------------
      
      I found a bug in the code that dealt with re-binding implicit
      numerical syntax:
      	literals 	(fromInteger/fromRational)
      	negation	(negate)
      	n+k patterns	(minus)
      
      This is triggered by the -fno-implicit-prelude flag, and it
      used to be handled via the PrelNames.SyntaxMap.
      
      But I found a nicer way to do it that involves much less code,
      and doesn't have the bug.  The explanation is with
      	RnEnv.lookupSyntaxName
      d4e38936
  9. 12 Jul, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-07-12 16:21:22 by simonpj] · ab46fd8e
      simonpj authored
      --------------------------------------------
      	Fix another bug in the squash-newtypes story.
      	--------------------------------------------
      
      [This one was spotted by Marcin, and is now enshrined in test tc130.]
      
      The desugarer straddles the boundary between the type checker and
      Core, so it sometimes needs to look through newtypes/implicit parameters
      and sometimes not.  This is really a bit painful, but I can't think of
      a better way to do it.
      
      The only simple way to fix things was to pass a bit more type
      information in the HsExpr type, from the type checker to the desugarer.
      That led to the non-local changes you can see.
      
      On the way I fixed one other thing.  In various HsSyn constructors
      there is a Type that is bogus (bottom) before the type checker, and
      filled in with a real type by the type checker.  In one place it was
      a (Maybe Type) which was Nothing before, and (Just ty) afterwards.
      I've defined a type synonym HsTypes.PostTcType for this, and a named
      bottom value HsTypes.placeHolderType to use when you want the bottom
      value.
      ab46fd8e
    • rrt's avatar
      [project @ 2001-07-12 12:59:48 by rrt] · 36d394f3
      rrt authored
      Fix spacing
      36d394f3
  10. 10 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-10 11:32:28 by simonpj] · c4786b4e
      simonpj authored
      Two bug-fixes to the new newtype story
      
      1. 	Be consistent about using TcType (not Type) in the
      	typechecker.  There was an odd function in TcMType that
      	used splitTyConApp instead of tcSplitTyConApp, which
      	resulted in bogus error messages
      
      2.	TcType.isTauTy should not look through SourceTy
      c4786b4e
  11. 28 Jun, 2001 1 commit
  12. 27 Jun, 2001 1 commit
  13. 25 Jun, 2001 3 commits
    • simonpj's avatar
      [project @ 2001-06-25 14:36:04 by simonpj] · a5ded1f8
      simonpj authored
      Import wibbles
      a5ded1f8
    • simonpj's avatar
      [project @ 2001-06-25 08:09:57 by simonpj] · d069cec2
      simonpj authored
      ----------------
      	Squash newtypes
      	----------------
      
      This commit squashes newtypes and their coerces, from the typechecker
      onwards.  The original idea was that the coerces would not get in the
      way of optimising transformations, but despite much effort they continue
      to do so.   There's no very good reason to retain newtype information
      beyond the typechecker, so now we don't.
      
      Main points:
      
      * The post-typechecker suite of Type-manipulating functions is in
      types/Type.lhs, as before.   But now there's a new suite in types/TcType.lhs.
      The difference is that in the former, newtype are transparent, while in
      the latter they are opaque.  The typechecker should only import TcType,
      not Type.
      
      * The operations in TcType are all non-monadic, and most of them start with
      "tc" (e.g. tcSplitTyConApp).  All the monadic operations (used exclusively
      by the typechecker) are in a new module, typecheck/TcMType.lhs
      
      * I've grouped newtypes with predicate types, thus:
      	data Type = TyVarTy Tyvar | ....
      		  | SourceTy SourceType
      
      	data SourceType = NType TyCon [Type]
      			| ClassP Class [Type]
      			| IParam Type
      
      [SourceType was called PredType.]  This is a little wierd in some ways,
      because NTypes can't occur in qualified types.   However, the idea is that
      a SourceType is a type that is opaque to the type checker, but transparent
      to the rest of the compiler, and newtypes fit that as do implicit parameters
      and dictionaries.
      
      * Recursive newtypes still retain their coreces, exactly as before. If
      they were transparent we'd get a recursive type, and that would make
      various bits of the compiler diverge (e.g. things which do type comparison).
      
      * I've removed types/Unify.lhs (non-monadic type unifier and matcher),
      merging it into TcType.
      
      Ditto typecheck/TcUnify.lhs (monadic unifier), merging it into TcMType.
      d069cec2
    • simonpj's avatar
      [project @ 2001-06-25 08:01:16 by simonpj] · a12bed53
      simonpj authored
      ----------------------------------
      	Fix a predicate-simplification bug
      	----------------------------------
      
      Fixes a bug pointed out by Marcin
      
          data R = R {f :: Int}
          foo:: (?x :: Int) => R -> R
          foo r = r {f = ?x}
      
          Test.hs:4:
      	Could not deduce `?x :: Int' from the context ()
      	arising from use of implicit parameter `?x' at Test.hs:4
      	In the record update: r {f = ?x}
      	In the definition of `foo': r {f = ?x}
      
      The predicate simplifier was declining to 'inherit' an
      implicit parameter.  This is right for a let-binding, but
      wrong for an expression binding.  For example, a simple
      expression type signature:
      
      		(?x + 1) :: Int
      
      This was rejected because the ?x constraint could not be
      floated out -- but that's wrong for expressions.
      a12bed53
  14. 13 Jun, 2001 1 commit
  15. 11 Jun, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-06-11 12:24:51 by simonpj] · 2c6d73e2
      simonpj authored
      --------------------------------------
      	Tidy up and improve "pattern contexts"
      	--------------------------------------
      
      In various places (renamer, typechecker, desugarer) we need to know
      what the context of a pattern match is (case expression, function defn,
      let binding, etc).  This commit tidies up the story quite a bit.  I
      think it represents a net decrease in code, and certainly it improves the
      error messages from:
      
      	f x x = 3
      
      Prevsiously we got a message like "Conflicting bindings for x in a pattern match",
      but not it says "..in a defn of function f".
      
      WARNING: the tidy up had a more global effect than I originally expected,
      so it's possible that some other error messages look a bit peculiar.  They
      should be easy to fix, but tell us!
      2c6d73e2
  16. 31 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-31 09:46:21 by simonpj] · f0d65bc7
      simonpj authored
      ----------------------------------
      	Fix an existential-constructor bug
      	----------------------------------
      
      		DON'T MERGE!
      
      This fixes a bug I introduced in my
      tidying up for scoped type variables.
      
      You'll get bizarre behaviour from the HEAD if
      you use existentials, until you add this fix!
      f0d65bc7
  17. 25 May, 2001 2 commits
    • dsyme's avatar
      [project @ 2001-05-25 16:14:02 by dsyme] · d67b0a6c
      dsyme authored
      Minor tweaks to IlxGen backend
      d67b0a6c
    • simonpj's avatar
      [project @ 2001-05-25 08:55:03 by simonpj] · 3af411e9
      simonpj authored
      -------------------------------------
      	Wibbles to Don's runtime-types commit
      	-------------------------------------
      
      There was an upside down predicate which utterly broke the compiler.
      
      While I was about it
      
      * I changed the global flag to
      	opt_RuntimeTypes
        with command line option
      	-fruntime-types (was -fkeep-stg-types)
      
      * I moved isRuntimeArg, isRuntimeVar to CoreSyn
      3af411e9
  18. 24 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-24 13:59:09 by simonpj] · cbdeae8f
      simonpj authored
      ------------------------------------------------------
      	More stuff towards generalising 'foreign' declarations
      	------------------------------------------------------
      
      This is the second step towards generalising 'foreign' declarations to
      handle langauges other than C.  Now I can handle
      
        foreign import dotnet type T
        foreign import dotnet "void Foo.Baz.f( T )" f :: T -> IO ()
      
      
      
      			** WARNING **
      	I believe that all the foreign stuff for C should
      	work exactly as before, but I have not tested it
      	thoroughly.  Sven, Manuel, Marcin: please give it a
      	whirl and compare old with new output.
      
      
      Lots of fiddling around with data types.  The main changes are
      
      * HsDecls.lhs
      	The ForeignDecl type and its friends
      	Note also the ForeignType constructor to TyClDecl
      
      * ForeignCall.lhs
      	Here's where the stuff that survives right through
      	compilation lives
      
      * TcForeign.lhs DsForeign.lhs
      	Substantial changes driven by the new data types
      
      * Parser.y ParseIface.y RnSource
      	Just what you'd expect
      cbdeae8f
  19. 22 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-22 13:43:14 by simonpj] · f16228e4
      simonpj authored
      -------------------------------------------
      	Towards generalising 'foreign' declarations
      	-------------------------------------------
      
      This is a first step towards generalising 'foreign' declarations to
      handle langauges other than C.  Quite a lot of files are touched,
      but nothing has really changed.  Everything should work exactly as
      before.
      
      	But please be on your guard for ccall-related bugs.
      
      Main things
      
      Basic data types: ForeignCall.lhs
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      * Remove absCSyn/CallConv.lhs
      
      * Add prelude/ForeignCall.lhs.  This defines the ForeignCall
        type and its variants
      
      * Define ForeignCall.Safety to say whether a call is unsafe
        or not (was just a boolean).  Lots of consequential chuffing.
      
      * Remove all CCall stuff from PrimOp, and put it in ForeignCall
      
      
      Take CCallOp out of the PrimOp type (where it was always a glitch)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      * Add IdInfo.FCallId variant to the type IdInfo.GlobalIdDetails,
      	along with predicates Id.isFCallId, Id.isFCallId_maybe
      
      * Add StgSyn.StgOp, to sum PrimOp with FCallOp, because it
        *is* useful to sum them together in Stg and AbsC land.  If
        nothing else, it minimises changes.
      
      
      Also generally rename "CCall" stuff to "FCall" where it's generic
      to all foreign calls.
      f16228e4
  20. 21 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-21 09:19:14 by simonpj] · c7e7bc25
      simonpj authored
      -------------------------------
      	Improve pattern type-signatures
      	-------------------------------
      
      The main effect of this commit is to implement the idea (originally
      Marcin's suggestion) that type variables in pattern type signatures
      are simply names for types; they don't have to name a type that is
      itself a type variable.
      
      For example
      
      	f :: Int -> Int
      	f (x::a) = let  y::a
      			y = x
      		   in x+y
      
      is fine.  Here 'a' is a name for the type 'Int', and does not have
      to be universally quantified.
      
      
      I also took the opportunity to modularise the implementation of
      pattern type-checking, mainly in TcMatches.  As a result pattern type
      signatures should work in do-notation (which they didn't before).
      
      ToDo: update documentation
      c7e7bc25
  21. 18 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-18 08:46:18 by simonpj] · b4775e5e
      simonpj authored
      -----------------------------
      	Get unbox-strict-fields right
      	-----------------------------
      
      The problem was that when a library was compiled *without* -funbox-strict-fields,
      and the main program was compiled *with* that flag, we were wrongly treating
      the fields of imported data types as unboxed.
      
      To fix this I added an extra constructor to StrictnessMark to express whether
      the "!" annotation came from an interface file (don't fiddle) or a source
      file (decide whether to unbox).
      
      On the way I tided things up:
      
      * StrictnessMark moves to Demand.lhs, and doesn't have the extra DataCon
        fields that kept it in DataCon before.
      
      * HsDecls.BangType has one constructor, not three, with a StrictnessMark field.
      
      * DataCon keeps track of its strictness signature (dcRepStrictness), but not
        its "user strict marks" (which were never used)
      
      * All the functions, like getUniquesDs, that used to take an Int saying how
        many uniques to allocate, now return an infinite list. This saves arguments
        and hassle.  But it involved touching quite a few files.
      
      * rebuildConArgs takes a list of Uniques to use as its unique supply.  This
        means I could combine DsUtils.rebuildConArgs with MkId.rebuildConArgs
        (hooray; the main point of the previous change)
      
      
      I also tidied up one or two error messages
      b4775e5e
  22. 08 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-08 14:44:37 by simonpj] · 7c72bad5
      simonpj authored
      ****	MERGE WITH 5.00 BRANCH     ********
      
      	--------------------------------------
      	Make parallel list comprehensions work
      	--------------------------------------
      
      There were two bugs
      
      1.  The desugaring in DsListComp was generating code that failed Lint.
          I've restructured it quite a lot.
      
      2.  More seriously, in a ParStmt, the last 'stmt' may be a guard;
          but previously both guards and the result of a list comprehension
          were encoded as an ExprStmt (see HsExpr.Stmt), using the fact that
          the stmt was last in the list to make the difference between a guard
          and a result.  But in parallel list comp this isn't right:
      
      	[ e | x <- xs, guard | y <- ys ]
      
          Here 'guard' is last in its list, but isn't an overall result.
      
          The sensible fix is to properly distinguish
      	"here's the answer" 			 (ResultStmt)
      	"here's a guard or an imperative action" (ExprStmt)
      
          The fix is rather easy, but touched quite a lot of files.  On the
          way I tidied up the parser a little.
      7c72bad5
  23. 04 May, 2001 4 commits
    • simonpj's avatar
      [project @ 2001-05-04 14:44:07 by simonpj] · 0aca75a2
      simonpj authored
      Add more TC tracing
      0aca75a2
    • simonpj's avatar
      [project @ 2001-05-04 14:43:26 by simonpj] · cb2d1981
      simonpj authored
      ****	MERGE WITH 5.00 BRANCH     ********
      
      	--------------------------------
      	Fix a black hole when type checking type decls
      	--------------------------------
      
      GHC was falling into a black hole when type checking a recursive
      group of type declarations including a chain of type synonyms.
      
        type PhraseFun = PMap -> Float
        type PMap      = () -> Player
        data Player    = P.MkT P.PhraseFun
      
      Reason: too much consistency checking in TcMonoType.
      Easily fixed using the existing wimp_out hack, but it's a mess.
      This commit fixes it for the 5.00 branch but I'll do something
      better in the head shortly.
      cb2d1981
    • simonpj's avatar
      [project @ 2001-05-04 14:40:42 by simonpj] · d6888704
      simonpj authored
      Comments only
      d6888704
    • simonpj's avatar
      [project @ 2001-05-04 08:10:30 by simonpj] · cf158e40
      simonpj authored
      Comments only
      cf158e40
  24. 03 May, 2001 6 commits
    • simonpj's avatar
      [project @ 2001-05-03 12:33:50 by simonpj] · bbc670f4
      simonpj authored
      ****	MERGE WITH 5.00 BRANCH     ********
      
      	--------------------------------
      	Monomorphism restriction for implicit parameters
      	--------------------------------
      
      This commit tidies up the way in which monomorphic bindings
      are dealt with, incidentally fixing a bug to do with implicit
      parameters.
      
      The tradeoffs concerning monomorphism and implicit paramters are
      now documented in TcSimplify.lhs, and all the strategic choices
      are made there (rather than in TcBinds where they were before).
      
      I've continued with choice (B) -- which Jeff first implemented --
      because that's what Hugs does, lacking any other consensus.
      bbc670f4
    • simonpj's avatar
      [project @ 2001-05-03 09:32:48 by simonpj] · b473b6c2
      simonpj authored
      ------------------------------------------------
      	Dramatically improve the error messages arising
      	from failed unifications triggered by 'improvement'
      	------------------------------------------------
      
      A bit more plumbing in FunDeps, and consequential wibbles elsewhere
      
      Changes this:
      
          Couldn't match `Int' against `[(String, Int)]'
      	Expected type: Int
      	Inferred type: [(String, Int)]
      
      to this:
      
          Foo.hs:8:
      	Couldn't match `Int' against `[(String, Int)]'
      	    Expected type: Int
      	    Inferred type: [(String, Int)]
      	When using functional dependencies to combine
      	  ?env :: Int, arising from a type signature at Foo.hs:7
      	  ?env :: [(String, Int)],
      	    arising from use of implicit parameter `?env' at Foo.hs:8
      	When generalising the types for ident
      b473b6c2
    • simonpj's avatar
      [project @ 2001-05-03 09:04:43 by simonpj] · 0f7c4b88
      simonpj authored
      Improve error message when two signature tyvars get unified
      0f7c4b88
    • simonpj's avatar
      [project @ 2001-05-03 09:02:44 by simonpj] · 62462136
      simonpj authored
      Error message wibble
      62462136
    • simonpj's avatar
      [project @ 2001-05-03 09:02:24 by simonpj] · 08b51f29
      simonpj authored
      Tidy up output from -ddump-types
      08b51f29
    • simonpj's avatar
      [project @ 2001-05-03 09:01:50 by simonpj] · 9708f9d9
      simonpj authored
      Improve error message
      9708f9d9