1. 29 Dec, 2006 1 commit
  2. 18 Dec, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Deriving for indexed data types · 380512de
      chak@cse.unsw.edu.au. authored
      - This patch implements deriving clauses for data instance declarations
        (toplevel and associated)
      - Doesn't support standalone deriving.  This could be easily supported,
        but requires an extension of the syntax of standalone deriving clauses.
        Björn, fancy adding this?
      - We cannot derive Typeable.  This seems a problem of notation, more than 
        anything else.  Why?  For a binary vanilla data type "T a b", we would 
        generate an instance Typeable2 T; ie, the instance is for the constructor
        alone.  In the case of a family instance, such as (S [a] (Maybe b)), we
        simply have no means to denote the associated constuctor.  It appears to
        require type level lambda - something like (/\a b. S [a] (Maybe b).
      - Derivings are for *individual* family *instances*, not for entire families.
        Currently, I know of no simple translation of class instances for entire 
        families to System F_C.  This actually seems to be similar to implementing
        open data types à la Löh & Hinze.
      - This patch only covers data types, not newtypes.
      380512de
  3. 10 Dec, 2006 1 commit
    • mnislaih's avatar
      Closure inspection in GHCi · 121da25a
      mnislaih authored
      The :print, :sprint and :force commands for GHCi.
      This set of commands allows inspection of heap structures of the bindings in the interactive environment.
      This is useful to observe lazyness and specially to inspect things with undespecified polymorphic types, as happens often in breakpoints.
      121da25a
  4. 24 Nov, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Improve handling of implicit parameters · 2e9952b7
      simonpj@microsoft.com authored
      A message to Haskell Cafe from Grzegorz Chrupala made me realise that
      GHC was not handling implicit parameters correctly, when it comes to
      choosing the variables to quantify, and ambiguity tests.  Here's the 
      note I added to TcSimplify:
      
      Note [Implicit parameters and ambiguity] 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      What type should we infer for this?
      	f x = (show ?y, x::Int)
      Since we must quantify over the ?y, the most plausible type is
      	f :: (Show a, ?y::a) => Int -> (String, Int)
      But notice that the type of the RHS is (String,Int), with no type 
      varibables mentioned at all!  The type of f looks ambiguous.  But
      it isn't, because at a call site we might have
      	let ?y = 5::Int in f 7
      and all is well.  In effect, implicit parameters are, well, parameters,
      so we can take their type variables into account as part of the
      "tau-tvs" stuff.  This is done in the function 'FunDeps.grow'.
      
      
      The actual changes are in FunDeps.grow, and the tests are
      	tc219, tc219
      2e9952b7
  5. 10 Nov, 2006 2 commits
  6. 06 Nov, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up substitutions · 94b170a0
      simonpj@microsoft.com authored
      The new simplifer stuff exposed the fact that the invariants on the
      TvSubstEnv and IdSubstEnv were insufficiently explicit.  (Resulted in
      a bug found by Sam Brosnon.)
      
      This patch fixes the bug, and tries to document the invariants pretty
      thoroughly. See 
      	Note [Extending the TvSubst] in Type
      	Note [Extenting the Subst]   in CoreSubst
      
      (Most of the new lines are comments.)
      94b170a0
  7. 01 Nov, 2006 2 commits
  8. 19 Oct, 2006 2 commits
  9. 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
  10. 13 Oct, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add assertion checks for mkCoVar/mkTyVar · ac704fca
      simonpj@microsoft.com authored
      A type variable has a flag saying whether it is a *type* variable or
      a *coercion* variable.  This patch adds assertions to check the flag.
      
      And it adds fixes to places which were Wrong (and hence fired the
      assertion)! 
      
      Also removed isCoVar from Coercion, since it's done by Var.isCoVar.
      
      
      ac704fca
  11. 12 Oct, 2006 1 commit
  12. 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
  13. 10 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Rough matches for family instances · 2a8cdc3a
      chak@cse.unsw.edu.au. authored
      - Class and type family instances just got a lot more similar.
      - FamInst, like Instance, now has a rough match signature.  The idea is the
        same: if the rough match doesn't match, there is no need to pull in the while
        tycon describing the instance (from a lazily read iface).
      - IfaceFamInst changes in a similar way and the list of all IFaceFamInsts is
        now written into the binary iface (as for class instances), as deriving it
        from the tycon (as before) would render the whole rough matching useless.
      - As a result of this, the plumbing of class instances and type instances 
        through the various environments, ModIface, ModGuts, and ModDetails is now
        almost the same.  (The remaining difference are mostly because the dfun of a
        class instance is an Id, but type instance refer to a TyCon, not an Id.)
      
      *** WARNING: The interface file format changed! ***
      ***	     Rebuild from scratch.		***
      2a8cdc3a
  14. 09 Oct, 2006 1 commit
  15. 06 Oct, 2006 2 commits
  16. 29 Sep, 2006 2 commits
  17. 14 Sep, 2006 1 commit
  18. 23 Sep, 2006 7 commits
  19. 21 Sep, 2006 1 commit
  20. 20 Sep, 2006 8 commits
    • chak@cse.unsw.edu.au.'s avatar
      Adding FamInstEnv & FamInst modules · 91923f12
      chak@cse.unsw.edu.au. authored
      - They got lost during manual patching, as they are file additions.
      91923f12
    • 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