1. 17 Sep, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Loosen the syntax of types slightly · fa1a55ba
      simonpj@microsoft.com authored
      This change allows you to write
      	f :: (Eq a) => (Ord b) => a -> b -> b
      Previously you could only have a forall and context after '->'
      but not after '=>' which is strange and inconsistent.
      Making the parser a bit more generous didn't change the number
      of shift/reduce conflicts.
      tc236 tests.
  2. 04 Sep, 2007 1 commit
  3. 03 Sep, 2007 1 commit
  4. 01 Sep, 2007 1 commit
  5. 17 Aug, 2007 1 commit
  6. 16 Aug, 2007 1 commit
  7. 10 Aug, 2007 1 commit
  8. 23 Jul, 2007 1 commit
  9. 21 Jun, 2007 2 commits
    • simonpj@microsoft.com's avatar
      FIX read040: patterns with type sig on LHS of do-binding · bb511e2d
      simonpj@microsoft.com authored
      f () = do { x :: Bool <- return True; ... }
      For some reason the production for 'pat' required 'infixexp' on the
      LHS of a do-notation binding.  This patch makes it an 'exp', which 
      thereby allows an expression with a type sig.
      Happily, there are no new shift-reduce errors, so I don't think this
      will break anything else.
    • 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
  10. 26 May, 2007 1 commit
  11. 11 May, 2007 1 commit
  12. 07 May, 2007 1 commit
  13. 23 Mar, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Emit a decent error message when there is a decl-splice inside a decl-bracket · d52ec21d
      simonpj@microsoft.com authored
      This fixes Trac #1065.  The fix is just to emit a decent error message
      rather than crash.  The situation is this:
        f x = ... [d| $(..stuff..); 
                      f x = v :: T |] ...
      TH wants to rename and typecheck the bracket; but it can't run the 
      nested splice yet.  That seems hard, because we know nothing about v, T,
      which are, presumably bound by the splice.
      The original TH paper says this isn't allowed, and now it's checked for
      properly (in the parser, in fact) rather than causing a crash.  In the
      fullness of time we might want to do something more flexible, but not now.
  14. 24 Feb, 2007 1 commit
  15. 04 Feb, 2007 1 commit
  16. 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.
  17. 05 Jan, 2007 1 commit
  18. 02 Jan, 2007 2 commits
    • simonpj@microsoft.com's avatar
    • 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
      	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
  19. 29 Dec, 2006 2 commits
  20. 28 Dec, 2006 1 commit
  21. 08 Dec, 2006 1 commit
  22. 06 Dec, 2006 1 commit
  23. 10 Nov, 2006 1 commit
  24. 11 Oct, 2006 1 commit
  25. 05 Oct, 2006 1 commit
  26. 21 Sep, 2006 1 commit
  27. 20 Sep, 2006 1 commit
  28. 18 Sep, 2006 1 commit
  29. 17 Sep, 2006 1 commit
  30. 29 Sep, 2006 1 commit
  31. 20 Sep, 2006 2 commits
    • chak@cse.unsw.edu.au.'s avatar
      Kind sig for toplevel family decls is optional · 7ab880e6
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:13:47 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Kind sig for toplevel family decls is optional
        Sat Aug 26 19:03:50 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Kind sig for toplevel family decls is optional
          - Kind sigs are still compulsory for AT family decls.  Changing this is more 
            tricky, as AT decls don't have the family keyword and hence look like empty 
            data decls.  That impacts reduce/reduce conflicts and/or the criteria for 
            checking whether a TyData variant is a family signature.
          - Also removed iso from the syntax (it's still in the lexer in case we want to
            resurrect it). 
    • chak@cse.unsw.edu.au.'s avatar
      Extend Class.Class to include the TyCons of ATs · bb106f28
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 18:58:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Extend Class.Class to include the TyCons of ATs
        Wed Aug 16 16:15:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Extend Class.Class to include the TyCons of ATs
  32. 18 Sep, 2006 3 commits
  33. 15 Sep, 2006 2 commits