1. 24 Jan, 2008 1 commit
    • Ian Lynagh's avatar
      Fix the build · 6c7b41cc
      Ian Lynagh authored
      Work around various problems caused by some of the monadification patches
      not being applied.
  2. 22 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up the treatment of SPECIALISE pragmas · 43a2e4a2
      simonpj@microsoft.com authored
      Remove the now-redundant "const-dicts" field in SpecPrag
      In dsBinds, abstract over constant dictionaries in the RULE.
      This avoids the creation of a redundant, duplicate, rule later
      in the Specialise pass, which was happening before.
      There should be no effect on performance either way, just less
      duplicated code, and the compiler gets a little simpler.
  3. 17 Jan, 2008 1 commit
    • Isaac Dupree's avatar
      lots of portability changes (#1405) · 206b4dec
      Isaac Dupree authored
      re-recording to avoid new conflicts was too hard, so I just put it
      all in one big patch :-(  (besides, some of the changes depended on
      each other.)  Here are what the component patches were:
      Fri Dec 28 11:02:55 EST 2007  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * document BreakArray better
      Fri Dec 28 11:39:22 EST 2007  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * properly ifdef BreakArray for GHCI
      Fri Jan  4 13:50:41 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * change ifs on __GLASGOW_HASKELL__ to account for... (#1405)
        for it not being defined. I assume it being undefined implies
        a compiler with relatively modern libraries but without most
        unportable glasgow extensions.
      Fri Jan  4 14:21:21 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * MyEither-->EitherString to allow Haskell98 instance
      Fri Jan  4 16:13:29 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * re-portabilize Pretty, and corresponding changes
      Fri Jan  4 17:19:55 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * Augment FastTypes to be much more complete
      Fri Jan  4 20:14:19 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * use FastFunctions, cleanup FastString slightly
      Fri Jan  4 21:00:22 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * Massive de-"#", mostly Int# --> FastInt (#1405)
      Fri Jan  4 21:02:49 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * miscellaneous unnecessary-extension-removal
      Sat Jan  5 19:30:13 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * add FastFunctions
  4. 07 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Make the treatment of equalities more uniform · 3787d987
      simonpj@microsoft.com authored
      This patch (which is part of the fix for Trac #2018) makes coercion variables
      be handled more uniformly.  Generally, they are treated like dictionaries
      in the type checker, not like type variables, but in a couple of places we
      were treating them like type variables.  Also when zonking we should use
      zonkDictBndr not zonkIdBndr.
  5. 20 Dec, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Implement generalised list comprehensions · 67cb4091
      simonpj@microsoft.com authored
        This patch implements generalised list comprehensions, as described in 
        the paper "Comprehensive comprehensions" (Peyton Jones & Wadler, Haskell
        Workshop 2007).  If you don't use the new comprehensions, nothing
        should change.
        The syntax is not exactly as in the paper; see the user manual entry 
        for details.
        You need an accompanying patch to the base library for this stuff 
        to work.
        The patch is the work of Max Bolingbroke [batterseapower@hotmail.com], 
        with some advice from Simon PJ.
        The related GHC Wiki page is 
  6. 19 Nov, 2007 1 commit
  7. 05 Nov, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Inline implication constraints · 85e16365
      simonpj@microsoft.com authored
      This patch fixes Trac #1643, where Lennart found that GHC was generating
      code with unnecessary dictionaries.  The reason was that we were getting
      an implication constraint floated out of an INLINE (actually an instance
      decl), and the implication constraint therefore wasn't inlined even 
      though it was used only once (but inside the INLINE).  Thus we were 
      	ic = \d -> <stuff>
      	foo = _inline_me_ (...ic...)
      Then 'foo' gets inlined in lots of places, but 'ic' now looks a bit 
      But implication constraints should *always* be inlined; they are just
      artefacts of the constraint simplifier.
      This patch solves the problem, by adding a WpInline form to the HsWrap
  8. 27 Oct, 2007 1 commit
    • simonpj@microsoft.com's avatar
      In an AbsBinds, the 'dicts' can include EqInsts · 6bb65108
      simonpj@microsoft.com authored
      An AbsBinds abstrats over evidence, and the evidence can be both
      Dicts (class constraints, implicit parameters) and EqInsts (equality
      constraints).  So we need to
        - use varType rather than idType
        - use instToVar rather than instToId
        - use zonkDictBndr rather than zonkIdBndr in zonking
      It actually all worked before, but gave warnings.
  9. 10 Oct, 2007 1 commit
    • Dan Licata's avatar
      View patterns, record wildcards, and record puns · 6a05ec5e
      Dan Licata authored
      This patch implements three new features:
      * view patterns (syntax: expression -> pat in a pattern)
      * working versions of record wildcards and record puns
      See the manual for detailed descriptions.
      Other minor observable changes:
      * There is a check prohibiting local fixity declarations
        when the variable being fixed is not defined in the same let
      * The warn-unused-binds option now reports warnings for do and mdo stmts
      Implementation notes: 
      * The pattern renamer is now in its own module, RnPat, and the
      implementation is now in a CPS style so that the correct context is
      delivered to pattern expressions.
      * These features required a fairly major upheaval to the renamer.
      Whereas the old version used to collect up all the bindings from a let
      (or top-level, or recursive do statement, ...) and put them into scope
      before renaming anything, the new version does the collection as it
      renames.  This allows us to do the right thing with record wildcard
      patterns (which need to be expanded to see what names should be
      collected), and it allows us to implement the desired semantics for view
      patterns in lets.  This change had a bunch of domino effects brought on
      by fiddling with the top-level renaming.
      * Prior to this patch, there was a tricky bug in mkRecordSelId in HEAD,
      which did not maintain the invariant necessary for loadDecl.  See note
      [Tricky iface loop] for details.
  10. 04 Sep, 2007 1 commit
  11. 03 Sep, 2007 1 commit
  12. 01 Sep, 2007 1 commit
  13. 21 Jun, 2007 2 commits
    • simonpj@microsoft.com's avatar
      FIX BUILD: add missing prime! · 13c7a6e6
      simonpj@microsoft.com authored
    • David Himmelstrup's avatar
      Add several new record features · 2eb04ca0
      David Himmelstrup authored
      1. Record disambiguation (-fdisambiguate-record-fields)
      In record construction and pattern matching (although not
      in record updates) it is clear which field name is intended
      even if there are several in scope.  This extension uses
      the constructor to disambiguate.  Thus
      	C { x=3 }
      uses the 'x' field from constructor C (assuming there is one)
      even if there are many x's in scope.
      2. Record punning (-frecord-puns)
      In a record construction or pattern match or update you can 
      omit the "=" part, thus
      	C { x, y }
      This is just syntactic sugar for
      	C { x=x, y=y }
      3.  Dot-dot notation for records (-frecord-dot-dot)
      In record construction or pattern match (but not update) 
      you can use ".." to mean "all the remaining fields".  So
      	C { x=v, .. }
      means to fill in the remaining fields to give
      	C { x=v, y=y }
      (assuming C has fields x and y).  This might reasonably
      considered very dodgy stuff.  For pattern-matching it brings
      into scope a bunch of things that are not explictly mentioned;
      and in record construction it just picks whatver 'y' is in
      scope for the 'y' field.   Still, Lennart Augustsson really
      wants it, and it's a feature that is extremely easy to explain.
      I thought of using the "parent" field in the GlobalRdrEnv, but
      that's really used for import/export and just isn't right for this.
      For example, for import/export a field is a subordinate of the *type
      constructor* whereas here we need to know what fields belong to a
      particular *data* constructor.
      The main thing is that we need to map a data constructor to its
      fields, and we need to do so in the renamer.   For imported modules
      it's easy: just look in the imported TypeEnv.  For the module being
      compiled, we make a new field tcg_field_env in the TcGblEnv.
      The important functions are
      There is still a significant infelicity in the way the renamer
      works on patterns, which I'll tackle next.
      I also did quite a bit of refactoring in the representation of
      record fields (mainly in HsPat).***END OF DESCRIPTION***
      Place the long patch description above the ***END OF DESCRIPTION*** marker.
      The first line of this file will be the patch name.
      This patch contains the following changes:
      M ./compiler/deSugar/Check.lhs -3 +5
      M ./compiler/deSugar/Coverage.lhs -6 +7
      M ./compiler/deSugar/DsExpr.lhs -6 +13
      M ./compiler/deSugar/DsMeta.hs -8 +8
      M ./compiler/deSugar/DsUtils.lhs -1 +1
      M ./compiler/deSugar/MatchCon.lhs -2 +2
      M ./compiler/hsSyn/Convert.lhs -3 +3
      M ./compiler/hsSyn/HsDecls.lhs -9 +25
      M ./compiler/hsSyn/HsExpr.lhs -13 +3
      M ./compiler/hsSyn/HsPat.lhs -25 +63
      M ./compiler/hsSyn/HsUtils.lhs -3 +3
      M ./compiler/main/DynFlags.hs +6
      M ./compiler/parser/Parser.y.pp -13 +17
      M ./compiler/parser/RdrHsSyn.lhs -16 +18
      M ./compiler/rename/RnBinds.lhs -2 +2
      M ./compiler/rename/RnEnv.lhs -22 +82
      M ./compiler/rename/RnExpr.lhs -34 +12
      M ./compiler/rename/RnHsSyn.lhs -3 +2
      M ./compiler/rename/RnSource.lhs -50 +78
      M ./compiler/rename/RnTypes.lhs -50 +84
      M ./compiler/typecheck/TcExpr.lhs -18 +18
      M ./compiler/typecheck/TcHsSyn.lhs -20 +21
      M ./compiler/typecheck/TcPat.lhs -8 +6
      M ./compiler/typecheck/TcRnMonad.lhs -6 +15
      M ./compiler/typecheck/TcRnTypes.lhs -2 +11
      M ./compiler/typecheck/TcTyClsDecls.lhs -3 +4
      M ./docs/users_guide/flags.xml +7
      M ./docs/users_guide/glasgow_exts.xml +42
  14. 18 Jun, 2007 1 commit
  15. 10 May, 2007 1 commit
  16. 02 May, 2007 1 commit
  17. 22 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fix corner case of useless constraint in SPECIALISE pragma · e5ca7e6e
      simonpj@microsoft.com authored
      This patch fixes Trac #1287.  
      The problem is described in Note [Unused spec binders] in DsBinds.
      At the same time I realised that the error messages in DsBinds.dsPrag
      were being given the location of the *binding* not the *pragma*.
      So I've fixed that too.
  18. 04 Feb, 2007 1 commit
  19. 21 Dec, 2006 1 commit
    • lennart@augustsson.net's avatar
      Add support for overloaded string literals. · 90dc9026
      lennart@augustsson.net authored
      The class is named IsString with the single method fromString.
      Overloaded strings work the same way as overloaded numeric literals.
      In expressions a string literals gets a fromString applied to it.
      In a pattern there will be an equality comparison with the fromString:ed literal.
      Use -foverloaded-strings to enable this extension.
  20. 29 Dec, 2006 1 commit
    • andy@galois.com's avatar
      Adding a GENERATED pragma · d386e0d2
      andy@galois.com authored
      Adding a {-# GENERATED "SourceFile" SourceSpan #-} <expr> pragma.
      This will be used to generate coverage for tool generated (or quoted) code.
      The pragma states the the expression was generated/quoted from the stated
      source file and source span.
  21. 18 Oct, 2006 1 commit
    • 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
      	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 
      Anyway, this fixes Trac #905
  22. 11 Oct, 2006 1 commit
  23. 05 Oct, 2006 1 commit
  24. 29 Sep, 2006 2 commits
  25. 20 Sep, 2006 2 commits
    • chak@cse.unsw.edu.au.'s avatar
      Complete the evidence generation for GADTs · 15cb792d
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 14:43:22 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Complete the evidence generation for GADTs
        Sat Aug  5 21:39:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Complete the evidence generation for GADTs
          Thu Jul 13 17:18:07 EDT 2006  simonpj@microsoft.com
            This patch completes FC evidence generation for GADTs.
            It doesn't work properly yet, because part of the compiler thinks
            	(t1 :=: t2) => t3
            is represented with FunTy/PredTy, while the rest thinks it's represented
            using ForAllTy.  Once that's done things should start to work.
    • chak@cse.unsw.edu.au.'s avatar
      Massive patch for the first months work adding System FC to GHC #34 · 3e83dfb2
      chak@cse.unsw.edu.au. authored
      Fri Sep 15 18:56:58 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Massive patch for the first months work adding System FC to GHC #34
        Fri Aug  4 18:20:57 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Massive patch for the first months work adding System FC to GHC #34
          Broken up massive patch -=chak
          Original log message:  
          This is (sadly) all done in one patch to avoid Darcs bugs.
          It's not complete work... more FC stuff to come.  A compiler
          using just this patch will fail dismally.
  26. 18 Sep, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Remove argument variance info of tycons · 3e0b6b25
      chak@cse.unsw.edu.au. authored
      Fri Aug 11 13:53:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Remove argument variance info of tycons
        - Following SPJ's suggestion, this patch removes the variance information from
          type constructors.  This information was computed, but never used.
        ** WARNING: This patch changes the format of interface files **
        **          You will need to rebuild from scratch.           **
  27. 06 Aug, 2006 1 commit
  28. 18 Sep, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Ensure that only zonked poly_ids are passed to tcSpecPrag · 40f5a075
      simonpj@microsoft.com authored
      This is a long-standing bug really (Trac #900).  The poly_id passed
      to tcSpecPrag should be zonked, else it calls tcSubExp with a non-zonked
      type; but that contradicts the latter's invariant.
      I ended up doing a bit of refactoring too.  The extra lines are 
      comments I think; the code line count is reduced.
      Test is tc212.hs
  29. 09 Aug, 2006 1 commit
  30. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
  31. 01 Mar, 2006 1 commit
  32. 09 Feb, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Fix desugaring of unboxed tuples · 3c245de9
      simonpj@microsoft.com authored
      This patch is a slightly-unsatisfactory fix to desugaring unboxed
      tuples; it fixes ds057 which has been failing for some time.
      Unsatisfactory because rather ad hoc -- but that applies to lots
      of the unboxed tuple stuff. 
  33. 03 Feb, 2006 1 commit
  34. 02 Feb, 2006 1 commit
  35. 25 Jan, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Simon's big boxy-type commit · ac10f840
      simonpj@microsoft.com authored
      This very large commit adds impredicativity to GHC, plus
      numerous other small things.
      *** WARNING: I have compiled all the libraries, and
      ***	     a stage-2 compiler, and everything seems
      ***	     fine.  But don't grab this patch if you 
      ***	     can't tolerate a hiccup if something is
      ***	     broken.
      The big picture is this:
      a) GHC handles impredicative polymorphism, as described in the
         "Boxy types: type inference for higher-rank types and
         impredicativity" paper
      b) GHC handles GADTs in the new simplified (and very sligtly less
         epxrssive) way described in the
         "Simple unification-based type inference for GADTs" paper
      But there are lots of smaller changes, and since it was pre-Darcs
      they are not individually recorded.
      Some things to watch out for:
      c)   The story on lexically-scoped type variables has changed, as per
           my email.  I append the story below for completeness, but I 
           am still not happy with it, and it may change again.  In particular,
           the new story does not allow a pattern-bound scoped type variable
           to be wobbly, so (\(x::[a]) -> ...) is usually rejected.  This is
           more restrictive than before, and we might loosen up again.
      d)   A consequence of adding impredicativity is that GHC is a bit less
           gung ho about converting automatically between
        	(ty1 -> forall a. ty2)    and    (forall a. ty1 -> ty2)
           In particular, you may need to eta-expand some functions to make
           typechecking work again.
           Furthermore, functions are now invariant in their argument types,
           rather than being contravariant.  Again, the main consequence is
           that you may occasionally need to eta-expand function arguments when
           using higher-rank polymorphism.
      Please test, and let me know of any hiccups
      Scoped type variables in GHC
      	January 2006
      0) Terminology.
         A *pattern binding* is of the form
      	pat = rhs
         A *function binding* is of the form
      	f pat1 .. patn = rhs
         A binding of the formm
      	var = rhs
         is treated as a (degenerate) *function binding*.
         A *declaration type signature* is a separate type signature for a
         let-bound or where-bound variable:
      	f :: Int -> Int
         A *pattern type signature* is a signature in a pattern: 
      	\(x::a) -> x
      	f (x::a) = x
         A *result type signature* is a signature on the result of a
         function definition:
      	f :: forall a. [a] -> a
      	head (x:xs) :: a = x
         The form
      	x :: a = rhs
         is treated as a (degnerate) function binding with a result
         type signature, not as a pattern binding.
      1) The main invariants:
           A) A lexically-scoped type variable always names a (rigid)
       	type variable (not an arbitrary type).  THIS IS A CHANGE.
              Previously, a scoped type variable named an arbitrary *type*.
           B) A type signature always describes a rigid type (since
      	its free (scoped) type variables name rigid type variables).
      	This is also a change, a consequence of (A).
           C) Distinct lexically-scoped type variables name distinct
      	rigid type variables.  This choice is open; 
      2) Scoping
      2(a) If a declaration type signature has an explicit forall, those type
         variables are brought into scope in the right hand side of the 
         corresponding binding (plus, for function bindings, the patterns on
         the LHS).  
      	f :: forall a. a -> [a]
      	f (x::a) = [x :: a, x]
         Both occurences of 'a' in the second line are bound by 
         the 'forall a' in the first line
         A declaration type signature *without* an explicit top-level forall
         is implicitly quantified over all the type variables that are
         mentioned in the type but not already in scope.  GHC's current
         rule is that this implicit quantification does *not* bring into scope
         any new scoped type variables.
      	f :: a -> a
      	f x = ...('a' is not in scope here)...
         This gives compatibility with Haskell 98
      2(b) A pattern type signature implicitly brings into scope any type
         variables mentioned in the type that are not already into scope.
         These are called *pattern-bound type variables*.
      	g :: a -> a -> [a]
      	g (x::a) (y::a) = [y :: a, x]
         The pattern type signature (x::a) brings 'a' into scope.
         The 'a' in the pattern (y::a) is bound, as is the occurrence on 
         the RHS.  
         A pattern type siganture is the only way you can bring existentials 
         into scope.
      	data T where
      	  MkT :: forall a. a -> (a->Int) -> T
      	f x = case x of
      		MkT (x::a) f -> f (x::a)
      2a) QUESTION
      	class C a where
      	  op :: forall b. b->a->a
      	instance C (T p q) where
      	  op = <rhs>
          Clearly p,q are in scope in <rhs>, but is 'b'?  Not at the moment.
          Nor can you add a type signature for op in the instance decl.
          You'd have to say this:
      	instance C (T p q) where
      	  op = let op' :: forall b. ...
      	           op' = <rhs>
      	       in op'
      3) A pattern-bound type variable is allowed only if the pattern's
         expected type is rigid.  Otherwise we don't know exactly *which*
         skolem the scoped type variable should be bound to, and that means
         we can't do GADT refinement.  This is invariant (A), and it is a 
         big change from the current situation.
      	f (x::a) = x	-- NO; pattern type is wobbly
      	g1 :: b -> b
      	g1 (x::b) = x	-- YES, because the pattern type is rigid
      	g2 :: b -> b
      	g2 (x::c) = x	-- YES, same reason
      	h :: forall b. b -> b
      	h (x::b) = x	-- YES, but the inner b is bound
      	k :: forall b. b -> b
      	k (x::c) = x	-- NO, it can't be both b and c
      3a) You cannot give different names for the same type variable in the same scope
          (Invariant (C)):
      	f1 :: p -> p -> p		-- NO; because 'a' and 'b' would be
      	f1 (x::a) (y::b) = (x::a)	--     bound to the same type variable
      	f2 :: p -> p -> p		-- OK; 'a' is bound to the type variable
      	f2 (x::a) (y::a) = (x::a)	--     over which f2 is quantified
      					-- NB: 'p' is not lexically scoped
      	f3 :: forall p. p -> p -> p	-- NO: 'p' is now scoped, and is bound to
      	f3 (x::a) (y::a) = (x::a)	--     to the same type varialble as 'a'
      	f4 :: forall p. p -> p -> p	-- OK: 'p' is now scoped, and its occurences
      	f4 (x::p) (y::p) = (x::p)	--     in the patterns are bound by the forall
      3b) You can give a different name to the same type variable in different
          disjoint scopes, just as you can (if you want) give diferent names to 
          the same value parameter
      	g :: a -> Bool -> Maybe a
      	g (x::p) True  = Just x  :: Maybe p
      	g (y::q) False = Nothing :: Maybe q
      3c) Scoped type variables respect alpha renaming. For example, 
          function f2 from (3a) above could also be written:
      	f2' :: p -> p -> p
      	f2' (x::b) (y::b) = x::b
         where the scoped type variable is called 'b' instead of 'a'.
      4) Result type signatures obey the same rules as pattern types signatures.
         In particular, they can bind a type variable only if the result type is rigid
      	f x :: a = x	-- NO
      	g :: b -> b
      	g x :: b = x	-- YES; binds b in rhs
      5) A *pattern type signature* in a *pattern binding* cannot bind a 
         scoped type variable
      	(x::a, y) = ...		-- Legal only if 'a' is already in scope
         Reason: in type checking, the "expected type" of the LHS pattern is
         always wobbly, so we can't bind a rigid type variable.  (The exception
         would be for an existential type variable, but existentials are not
         allowed in pattern bindings either.)
         Even this is illegal
      	f :: forall a. a -> a
      	f x = let ((y::b)::a, z) = ... 
         Here it looks as if 'b' might get a rigid binding; but you can't bind
         it to the same skolem as a.
      6) Explicitly-forall'd type variables in the *declaration type signature(s)*
         for a *pattern binding* do not scope AT ALL.
      	x :: forall a. a->a	  -- NO; the forall a does 
      	Just (x::a->a) = Just id  --     not scope at all
      	y :: forall a. a->a
      	Just y = Just (id :: a->a)  -- NO; same reason
         THIS IS A CHANGE, but one I bet that very few people will notice.
         Here's why:
      	strange :: forall b. (b->b,b->b)
      	strange = (id,id)
      	x1 :: forall a. a->a
      	y1 :: forall b. b->b
      	(x1,y1) = strange
          This is legal Haskell 98 (modulo the forall). If both 'a' and 'b'
          both scoped over the RHS, they'd get unified and so cannot stand
          for distinct type variables. One could *imagine* allowing this:
      	x2 :: forall a. a->a
      	y2 :: forall a. a->a
      	(x2,y2) = strange
          using the very same type variable 'a' in both signatures, so that
          a single 'a' scopes over the RHS.  That seems defensible, but odd,
          because though there are two type signatures, they introduce just
          *one* scoped type variable, a.
      7) Possible extension.  We might consider allowing
      	\(x :: [ _ ]) -> <expr>
          where "_" is a wild card, to mean "x has type list of something", without
          naming the something.
  36. 27 Oct, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-10-27 14:35:20 by simonpj] · 958924a2
      simonpj authored
      Add a new pragma: SPECIALISE INLINE
      This amounts to adding an INLINE pragma to the specialised version
      of the function.  You can add phase stuff too (SPECIALISE INLINE [2]),
      and NOINLINE instead of INLINE.
      The reason for doing this is to support inlining of type-directed
      recursive functions.  The main example is this:
        -- non-uniform array type
        data Arr e where
          ArrInt  :: !Int -> ByteArray#       -> Arr Int
          ArrPair :: !Int -> Arr e1 -> Arr e2 -> Arr (e1, e2)
        (!:) :: Arr e -> Int -> e
        {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-}
        {-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-}
        ArrInt  _ ba    !: (I# i) = I# (indexIntArray# ba i)
        ArrPair _ a1 a2 !: i      = (a1 !: i, a2 !: i)
      If we use (!:) at a particular array type, we want to inline (:!),
      which is recursive, until all the type specialisation is done.
      On the way I did a bit of renaming and tidying of the way that
      pragmas are carried, so quite a lot of files are touched in a
      fairly trivial way.
  37. 10 Aug, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-08-10 11:05:06 by simonpj] · e3a4d6c3
      simonpj authored
      It turned out that doing all binding dependency analysis in the typechecker
      meant that the renamer's unused-binding error messages got worse.  So now
      I've put the first dep anal back into the renamer, while the second (which
      is specific to type checking) remains in the type checker.
      I've also made the pretty printer sort the decls back into source order
      before printing them (except with -dppr-debug).
      Fixes rn041.