1. 01 Apr, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-04-01 08:23:30 by simonpj] · 9003a18c
      simonpj authored
      ------------------------------------
      	Change the treatment of the stupid
      	   context on data constructors
      	-----------------------------------
      
      Data types can have a context:
      
      	data (Eq a, Ord b) => T a b = T1 a b | T2 a
      
      and that makes the constructors have a context too
      (notice that T2's context is "thinned"):
      
      	T1 :: (Eq a, Ord b) => a -> b -> T a b
      	T2 :: (Eq a) => a -> T a b
      
      Furthermore, this context pops up when pattern matching
      (though GHC hasn't implemented this, but it is in H98, and
      I've fixed GHC so that it now does):
      
      	f (T2 x) = x
      gets inferred type
      	f :: Eq a => T a b -> a
      
      I say the context is "stupid" because the dictionaries passed
      are immediately discarded -- they do nothing and have no benefit.
      It's a flaw in the language.
      
      Up to now I have put this stupid context into the type of
      the "wrapper" constructors functions, T1 and T2, but that turned
      out to be jolly inconvenient for generics, and record update, and
      other functions that build values of type T (because they don't
      have suitable dictionaries available).
      
      So now I've taken the stupid context out.  I simply deal with
      it separately in the type checker on occurrences of a constructor,
      either in an expression or in a pattern.
      
      To this end
      
      * Lots of changes in DataCon, MkId
      
      * New function Inst.tcInstDataCon to instantiate a data constructor
      
      
      
      I also took the opportunity to
      
      * Rename
      	dataConId --> dataConWorkId
        for consistency.
      
      * Tidied up MkId.rebuildConArgs quite a bit, and renamed it
      	mkReboxingAlt
      
      * Add function DataCon.dataConExistentialTyVars, with the obvious meaning
      9003a18c
  2. 06 Feb, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-02-06 15:54:23 by simonpj] · 979947f5
      simonpj authored
      Eliminate all vestiages of UsageTy, in preparation for
      	Keith's new version.  Hurrah!
      
      	Keith: LBVarInfo and usOnce,usMany are still there,
      	because I know you have eliminated LBVarInfo, and I didn't
      	want to cause unnecessary conflicts.
      979947f5
  3. 27 Aug, 2001 1 commit
  4. 17 Aug, 2001 1 commit
    • apt's avatar
      [project @ 2001-08-17 17:18:51 by apt] · 1dfaee31
      apt authored
      How I spent my summer vacation.
      
      Primops
      -------
      
      The format of the primops.txt.pp file has been enhanced to allow
      (latex-style) primop descriptions to be included.  There is a new flag
      to genprimopcode that generates documentation including these
      descriptions. A first cut at descriptions of the more interesting
      primops has been made, and the file has been reordered a bit.
      
      31-bit words
      ------------
      
      The front end now can cope with the possibility of 31-bit (or even 30-bit)
      Int# and Word# types.  The only current use of this is to generate
      external .core files that can be translated into OCAML source files
      (OCAML uses a one-bit tag to distinguish integers from pointers).
      The only way to get this right now is by hand-defining the preprocessor
      symbol WORD_SIZE_IN_BITS, which is normally set automatically from
      the familiar WORD_SIZE_IN_BYTES.
      
      Just in case 31-bit words are used, we now have Int32# and Word32# primitive types
      and an associated family of operators, paralleling the existing 64-bit
      stuff.  Of course, none of the operators actually need to be implemented
      in the absence of a 31-bit backend.
      There has also been some minor re-jigging of the 32 vs. 64 bit stuff.
      See the description at the top of primops.txt.pp file for more details.
      Note that, for the first time, the *type* of a primop can now depend
      on the target word size.
      
      Also, the family of primops intToInt8#, intToInt16#, etc.
      have been renamed narrow8Int#, narrow16Int#, etc., to emphasize
      that they work on Int#'s and don't actually convert between types.
      
      Addresses
      ---------
      
      As another part of coping with the possibility of 31-bit ints,
      the addr2Int# and int2Addr# primops are now thoroughly deprecated
      (and not even defined in the 31-bit case) and all uses
      of them have been removed except from the (deprecated) module
      hslibs/lang/Addr
      
      Addr# should now be treated as a proper abstract type, and has these suitable operators:
      
      nullAddr# : Int# -> Addr# (ignores its argument; nullary primops cause problems at various places)
      plusAddr# :  Addr# -> Int# -> Addr#
      minusAddr : Addr# -> Addr# -> Int#
      remAddr# : Addr# -> Int# -> Int#
      
      Obviously, these don't allow completely arbitrary offsets if 31-bit ints are
      in use, but they should do for all practical purposes.
      
      It is also still possible to generate an address constant, and there is a built-in rule
      that makes use of this to remove the nullAddr# calls.
      
      Misc
      ----
      There is a new compile flag -fno-code that causes GHC to quit after generating .hi files
      and .core files (if requested) but before generating STG.
      
      Z-encoded names for tuples have been rationalized; e.g.,
      Z3H now means an unboxed 3-tuple, rather than an unboxed
      tuple with 3 commas (i.e., a 4-tuple)!
      
      Removed misc. litlits in hslibs/lang
      
      Misc. small changes to external core format.  The external core description
      has also been substantially updated, and incorporates the automatically-generated
      primop documentation; its in the repository at /papers/ext-core/core.tex.
      
      A little make-system addition to allow passing CPP options to compiler and
      library builds.
      1dfaee31
  5. 19 Jul, 2001 1 commit
  6. 25 Jun, 2001 2 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
  7. 01 Jun, 2001 1 commit