1. 31 Jul, 2008 2 commits
  2. 25 Mar, 2008 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Change syntax for newtypes in External Core · 2fbab1a0
      chevalier@alum.wellesley.edu authored
      The way that newtype declarations were printed in External Core files was
      incomplete, since there was no declaration for the coercion introduced by a
      newtype.
      
      For example, the Haskell source:
      
      newtype T a = MkT (a -> a)
      
      foo (MkT x) = x
      
      got printed out in External Core as (roughly):
      
        %newtype T a = a -> a;
      
        foo :: %forall t . T t -> t -> t =
          %cast (\ @ t -> a1 @ t)
          (%forall t . T t -> ZCCoT t);
      
      There is no declaration anywhere in the External Core program for :CoT, so
      that's bad.
      
      I changed the newtype decl syntax so as to include the declaration for the
      coercion axiom introduced by the newtype. Now, it looks like:
      
        %newtype T a ^ (ZCCoT :: ((T a) :=: (a -> a))) = a -> a;
      
      And an external typechecker could conceivably typecheck code that uses this.
      
      The major changes are to MkExternalCore and PprExternalCore (as well as
      ExternalCore, to change the External Core AST.) I also corrected some typos in
      comments in other files.
      
      Documentation and external tool changes to follow.
      2fbab1a0
  3. 04 Feb, 2008 1 commit
    • Simon Marlow's avatar
      Support for using libffi to implement FFI calls in GHCi (#631) · 937eb1f1
      Simon Marlow authored
      This means that an unregisterised build on a platform not directly
      supported by GHC can now have full FFI support using libffi.
      
      Also in this commit:
      
       - use PrimRep rather than CgRep to describe FFI args in the byte
         code generator.  No functional changes, but PrimRep is more correct.
      
       - change TyCon.sizeofPrimRep to primRepSizeW, which is more useful
      937eb1f1
  4. 26 Jan, 2008 1 commit
  5. 21 Dec, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Improve handling of newtypes (fixes Trac 1495) · 219f900f
      simonpj@microsoft.com authored
      In a few places we want to "look through" newtypes to get to the
      representation type.  But we need to be careful that  we don't fall 
      into an ininite loop with e.g.
      	newtype T = MkT T
      
      The old mechansim for doing this was to have a field nt_rep, inside 
      a newtype TyCon, that gave the "ultimate representation" of the type.
      But that failed for Trac 1495, which looked like this:
         newtype Fix a = Fix (a (Fix a))
         data I a = I a
      Then, expanding the type (Fix I) went on for ever.
      
      The right thing to do seems to be to check for loops when epxanding
      the *type*, rather than in the *tycon*.  This patch does that, 
      	- Removes nt_rep from TyCon
      	- Make Type.repType check for loops
      See Note [Expanding newtypes] in Type.lhs.
      
      At the same time I also fixed a bug for Roman, where newtypes were not
      being expanded properly in FamInstEnv.topNormaliseType.  This function
      and Type.repType share a common structure.
      
      
      	Ian, see if this merges easily to the branch
      	If not, I don't think it's essential to fix 6.8
      219f900f
  6. 05 Nov, 2007 1 commit
  7. 16 Oct, 2007 1 commit
  8. 29 Sep, 2007 1 commit
  9. 05 Sep, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Refactor, improve, and document the deriving mechanism · 25f84fa7
      simonpj@microsoft.com authored
      This patch does a fairly major clean-up of the code that implements 'deriving.
      
      * The big changes are in TcDeriv, which is dramatically cleaned up.
        In particular, there is a clear split into
      	a) inference of instance contexts for deriving clauses
      	b) generation of the derived code, given a context 
        Step (a) is skipped for standalone instance decls, which 
        have an explicitly provided context.
      
      * The handling of "taggery", which is cooperative between TcDeriv and
        TcGenDeriv, is cleaned up a lot
      
      * I have added documentation for standalone deriving (which was 
        previously wrong).
      
      * The Haskell report is vague on exactly when a deriving clause should
        succeed.  Prodded by Conal I have loosened the rules slightly, thereyb
        making drv015 work again, and documented the rules in the user manual.
      
      I believe this patch validates ok (once I've update the test suite)
      and can go into the 6.8 branch.
      25f84fa7
  10. 04 Sep, 2007 1 commit
  11. 03 Sep, 2007 1 commit
  12. 01 Sep, 2007 1 commit
  13. 28 Aug, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Type checking for type synonym families · 5822cb8d
      chak@cse.unsw.edu.au. authored
      This patch introduces type checking for type families of which associated
      type synonyms are a special case. E.g.
      
              type family Sum n m
      
              type instance Sum Zero n = n
              type instance Sum (Succ n) m = Succ (Sum n m)
      
      where
      
              data Zero       -- empty type
              data Succ n     -- empty type
      
      In addition we support equational constraints of the form:
      
              ty1 ~ ty2
      
      (where ty1 and ty2 are arbitrary tau types) in any context where
      type class constraints are already allowed, e.g.
      
              data Equals a b where
                      Equals :: a ~ b => Equals a b
      
      The above two syntactical extensions are disabled by default. Enable
      with the -XTypeFamilies flag.
      
      For further documentation about the patch, see:
      
              * the master plan
                http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions
      
              * the user-level documentation
                http://haskell.org/haskellwiki/GHC/Indexed_types
      
      The patch is mostly backwards compatible, except for:
      
              * Some error messages have been changed slightly.
      
              * Type checking of GADTs now requires a bit more type declarations:
                not only should the type of a GADT case scrutinee be given, but also
                that of any identifiers used in the branches and the return type.
      
      Please report any unexpected behavior and incomprehensible error message 
      for existing code.
      
      Contributors (code and/or ideas):
              Tom Schrijvers
              Manuel Chakravarty
              Simon Peyton-Jones
              Martin Sulzmann 
      with special thanks to Roman Leshchinskiy
      5822cb8d
  14. 09 Aug, 2007 1 commit
  15. 04 Aug, 2007 1 commit
  16. 19 May, 2007 1 commit
  17. 11 May, 2007 1 commit
  18. 04 May, 2007 1 commit
    • simonpj@microsoft.com's avatar
      isDataTyCon should be False for all type families, even data type families · 71d2bf92
      simonpj@microsoft.com authored
      isDataTyCon advertises that it's true of "data types that are
      definitely represented by heap-allocated constructors.  These are
      srcutinised by Core-level @case@ expressions, and they get info tables
      allocated for them."
      
      Type-family TyCons never have this property, not even data type families.
      It's the *instance* TyCons that do.
      
      I hope that this change does not break anything that somehow relied
      on the old (wrong) semantics.
      71d2bf92
  19. 02 May, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fixes to data type families · 683a2690
      simonpj@microsoft.com authored
      - Fix two distinct bugs, one in MkId.mkDataConIds, one in DataCon.mkDataCon
      - Add more comments
      - Add a little assertion checking in TyCon
      
      Type-family tests now work.
      683a2690
  20. 25 Apr, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Generating synonym instance representation tycons · 13cd965d
      chak@cse.unsw.edu.au. authored
      - Type synonym instances are turned into representation synonym tycons
      - They are entered into the pool of family instances (FamInst environments)
        in the same way as data/newtype instances
      - Still missing is writing the parent tycon information into ifaces and 
        various well-formedness checks.
      13cd965d
  21. 22 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fixes to datacon wrappers for indexed data types · 70918cf4
      simonpj@microsoft.com authored
      nominolo@gmail.com pointed out (Trac #1204) that indexed data types
      aren't quite right. I investigated and found that the wrapper
      functions for indexed data types, generated in MkId, are really very
      confusing.  In particular, we'd like these combinations to work
      	newtype + indexed data type
      	GADT + indexted data type
      The wrapper situation gets a bit complicated!  
      
      I did a bit of refactoring, and improved matters, I think.  I am not
      certain that I have gotten it right yet, but I think it's better.
      I'm committing it now becuase it's been on my non-backed-up laptop for
      a month and I want to get it into the repo. I don't think I've broken
      anything, but I don't regard it as 'done'.
      70918cf4
  22. 23 Feb, 2007 1 commit
  23. 10 Jan, 2007 1 commit
  24. 03 Jan, 2007 1 commit
  25. 02 Jan, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Big tidy-up of deriving code · 84923cc7
      simonpj@microsoft.com authored
      This tidy-up, triggered by Trac #1068, re-factors the way that 'deriving' 
      happens.  It took me way longer than I had intended.  The main changes,
      by far are to TcDeriv; everyting else is a minor consequence.
      
      While I was at it, I changed the syntax for standalone deriving, so that
      it goes
      	derive instance Show (T a)
      
      (instead of "derive Show for T").  However, there's still an implicit
      context, generated by the deriving code, and I wonder if it shouldn't really
      be
      	derive instance (..) => Show (T a)
      but I have left it simple for now.
      
      I also added a function Type.substTyVars, and used it here and there, which
      led to some one-line changes otherwise unrelated (sorry).
      
      Loose ends:
        * 'deriving Typeable' for indexed data types is still not right
        * standalone deriving should be documented
      84923cc7
  26. 19 Oct, 2006 1 commit
  27. 18 Oct, 2006 2 commits
    • simonpj@microsoft.com's avatar
      Add the primitive type Any, and use it for Dynamics · c128930d
      simonpj@microsoft.com authored
      GHC's code generator can only enter a closure if it's guaranteed
      not to be a function.  In the Dynamic module, we were using the 
      type (forall a.a) as the type to which the dynamic type was unsafely
      cast:
      	type Obj = forall a.a
      
      Gut alas this polytype was sometimes instantiated to (), something 
      like this (it only bit when profiling was enabled)
      	let y::() = dyn ()
      	in (y `cast` ..) p q
      As a result, an ASSERT in ClosureInfo fired (hooray).
      
      I've tided this up by making a new, primitive, lifted type Any, and
      arranging that Dynamic uses Any, thus:
      	type Obj = ANy
      
      While I was at it, I also arranged that when the type checker instantiates 
      un-constrained type variables, it now instantiates them to Any, not ()
      	e.g.  length Any []
      
      [There remains a Horrible Hack when we want Any-like things at arbitrary 
      kinds.  This essentially never happens, but see comments with 
      TysPrim.mkAnyPrimTyCon.]
      
      Anyway, this fixes Trac #905
      c128930d
    • simonpj@microsoft.com's avatar
      Add comment about arity · 5e41a5af
      simonpj@microsoft.com authored
      I'm not sure what the significance of the "arity" of a primtive
      TyCon is.  They aren't necessarily saturated, so it's not that.
      
      I rather think that arity is only relevant for 
      	SynTyCon 
      	AlgTyCon
      	CoercionTyCon
      
      This comment (and commit message) is just an aide memoire.
      5e41a5af
  28. 11 Oct, 2006 2 commits
    • Simon Marlow's avatar
      ab22f4e6
    • Simon Marlow's avatar
      Interface file optimisation and removal of nameParent · b00b5bc0
      Simon Marlow authored
      This large commit combines several interrelated changes:
      
        - IfaceSyn now contains actual Names rather than the special
          IfaceExtName type.  The binary interface file contains
          a symbol table of Names, where each entry is a (package,
          ModuleName, OccName) triple.  Names in the IfaceSyn point
          to entries in the symbol table.
      
          This reduces the size of interface files, which should
          hopefully improve performance (not measured yet).
      
          The toIfaceXXX functions now do not need to pass around
          a function from Name -> IfaceExtName, which makes that
          code simpler.
      
        - Names now do not point directly to their parents, and the
          nameParent operation has gone away.  It turned out to be hard to
          keep this information consistent in practice, and the parent info
          was only valid in some Names.  Instead we made the following
          changes:
      
          * ImportAvails contains a new field 
                imp_parent :: NameEnv AvailInfo
            which gives the family info for any Name in scope, and
            is used by the renamer when renaming export lists, amongst
            other things.  This info is thrown away after renaming.
      
          * The mi_ver_fn field of ModIface now maps to
            (OccName,Version) instead of just Version, where the
            OccName is the parent name.  This mapping is used when
            constructing the usage info for dependent modules.
            There may be entries in mi_ver_fn for things that are not in
            scope, whereas imp_parent only deals with in-scope things.
      
          * The md_exports field of ModDetails now contains
            [AvailInfo] rather than NameSet.  This gives us
            family info for the exported names of a module.
      
      Also:
      
         - ifaceDeclSubBinders moved to IfaceSyn (seems like the
           right place for it).
      
         - heavily refactored renaming of import/export lists.
      
         - Unfortunately external core is now broken, as it relied on
           IfaceSyn.  It requires some attention.
      b00b5bc0
  29. 29 Sep, 2006 1 commit
  30. 23 Sep, 2006 1 commit
  31. 20 Sep, 2006 7 commits
    • chak@cse.unsw.edu.au.'s avatar
      Fix type checking of imported data instances · 6070e794
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:48:41 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Fix type checking of imported data instances
        Mon Sep 11 20:06:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Fix type checking of imported data instances
          - When reading a data/newtype instance from an interface, the data constructors
            have their own universals that do not necessarily match up with their tycon's
            type parameters.  (Whereas when type checking source, they are always the 
            same.)
          - Hence, we need to be careful when building the wrapper signature of imported
            data constructors from data/newtype instances, and rename the type variables
            in the instance types appropriately.
      6070e794
    • chak@cse.unsw.edu.au.'s avatar
      Get of fam inst index in ifaces · 0cb269be
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:40:42 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Get of fam inst index in ifaces
        Fri Sep  8 16:31:26 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Get of fam inst index in ifaces
          - Removes the explicit index to get unique names for derived tycons for family
            instances again, following a suggestion by SPJ.
          - We now derive the coercion tycon name from the name of the representation 
            tycon, which is in the iface anyways.
          
          *** WARNING: Change of interface file format! ***
          ***          Recompile from scratch!          ***
      0cb269be
    • chak@cse.unsw.edu.au.'s avatar
      Straightened out implicit coercions for indexed types · d76c18e0
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:35:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Straightened out implicit coercions for indexed types
        Mon Sep  4 23:46:14 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Straightened out implicit coercions for indexed types
          - HscTypes.implicitTyThings and LoadIface.ifaceDeclSubBndrs now
            include the coercion of indexed data/newtypes.
          - Name generation for the internal names of indexed data/newtypes now uses
            the same counter that generates the dfun unique indexes (ie, class and type
            instances are counted with the one counter).  We could make this two 
            separate counters if that's what's preferred.
          - The unique index of a data/newtype instances needs to go into the iface, so
            that we can generate the same names on slurping in the iface as when the
            original module was generated.  This is a bit yucky, but I don't see a way
            to avoid that (other than putting the full blown internal tycon name and 
            coercion name into the iface, which IMHO would be worse).
          - The predicate for when a datacon has a wrapper didn't take GADT
            equations nor whether it comes froma  family instance into account.
          
          *** WARNING!  This patch changed the interface file format. ***
          ***           Please recompile from scratch.                ***
      d76c18e0
    • chak@cse.unsw.edu.au.'s avatar
      Indexed newtypes · 27897431
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:24:27 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Indexed newtypes
        Thu Aug 31 22:09:21 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Indexed newtypes
          - This patch makes indexed newtypes work
          - Only lightly tested
          - We need to distinguish between open and closed newtypes in a number of 
            places, because looking through newtypes doesn't work easily for open ones.
      27897431
    • chak@cse.unsw.edu.au.'s avatar
      Check category of type instances and some newtype family fixes · d5c4754d
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:23:39 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Check category of type instances and some newtype family fixes
        Thu Aug 31 16:54:14 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Check category of type instances and some newtype family fixes
      d5c4754d
    • chak@cse.unsw.edu.au.'s avatar
      Checking conformance of AT indexes with instance heads · 53569e14
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:18:18 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Checking conformance of AT indexes with instance heads
        Wed Aug 30 20:13:52 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Checking conformance of AT indexes with instance heads
      53569e14
    • chak@cse.unsw.edu.au.'s avatar
      Check that AT instance is in a class · feb584b7
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:16:40 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Check that AT instance is in a class
        Sat Aug 26 21:49:56 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Check that AT instance is in a class
      feb584b7