1. 09 Mar, 2008 1 commit
  2. 21 Jan, 2008 1 commit
  3. 18 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add quasi-quotation, courtesy of Geoffrey Mainland · f3399c44
      simonpj@microsoft.com authored
      This patch adds quasi-quotation, as described in
        "Nice to be Quoted: Quasiquoting for Haskell"
      	(Geoffrey Mainland, Haskell Workshop 2007)
      Implemented by Geoffrey and polished by Simon.
      The syntax for quasiquotation is very similar to the existing
      Template haskell syntax:
      	[$q| stuff |]
      where 'q' is the "quoter".  This syntax differs from the paper, by using
      a '$' rather than ':', to avoid clashing with parallel array comprehensions.
      The "quoter" is a value of type Language.Haskell.TH.Quote.QuasiQuoter, which
      contains two functions for quoting expressions and patterns, respectively.
           quote = Language.Haskell.TH.Quote.QuasiQuoter quoteExp quotePat
           quoteExp :: String -> Language.Haskell.TH.ExpQ
           quotePat :: String -> Language.Haskell.TH.PatQ
      TEXT is passed unmodified to the quoter. The context of the
      quasiquotation statement determines which of the two quoters is
      called: if the quasiquotation occurs in an expression context,
      quoteExp is called, and if it occurs in a pattern context, quotePat
      is called.
      The result of running the quoter on its arguments is spliced into
      the program using Template Haskell's existing mechanisms for
      splicing in code. Note that although Template Haskell does not
      support pattern brackets, with this patch binding occurrences of
      variables in patterns are supported. Quoters must also obey the same
      stage restrictions as Template Haskell; in particular, in this
      example quote may not be defined in the module where it is used as a
      quasiquoter, but must be imported from another module.
      Points to notice
      * The whole thing is enabled with the flag -XQuasiQuotes
      * There is an accompanying patch to the template-haskell library. This
        involves one interface change:
      	currentModule :: Q String
        is replaced by
      	location :: Q Loc
        where Loc is a data type defined in TH.Syntax thus:
            data Loc
              = Loc { loc_filename :: String
      	      , loc_package  :: String
      	      , loc_module   :: String
      	      , loc_start    :: CharPos
      	      , loc_end      :: CharPos }
            type CharPos = (Int, Int)	-- Line and character position
        So you get a lot more info from 'location' than from 'currentModule'.
        The location you get is the location of the splice.
        This works in Template Haskell too of course, and lets a TH program
        generate much better error messages.
      * There's also a new module in the template-haskell package called 
        Language.Haskell.TH.Quote, which contains support code for the
        quasi-quoting feature.
      * Quasi-quote splices are run *in the renamer* because they can build 
        *patterns* and hence the renamer needs to see the output of running the
        splice.  This involved a bit of rejigging in the renamer, especially
        concerning the reporting of duplicate or shadowed names.
        (In fact I found and removed a few calls to checkDupNames in RnSource 
        that are redundant, becuase top-level duplicate decls are handled in
  4. 10 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix 2030: make -XScopedTypeVariables imply -XRelaxedPolyRec · 493fd9df
      simonpj@microsoft.com authored
      The type checker doesn't support lexically scoped type variables 
      unless we are using the RelaxedPolyRec option.  Reasons: see
      Note [Scoped tyvars] in TcBinds.
      So I've changed DynFlags to add this implication, improved the 
      documentation, and simplified the code in TcBinds somewhat.
      (It's longer but only because of comments!)
  5. 07 Jan, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add -XImpredicativeTypes, and tighten up type-validity checking (cf Trac 2019) · 5e04ae34
      simonpj@microsoft.com authored
      Somehow we didn't have a separate flag for impredicativity; now we do.
      Furthermore, Trac #2019 showed up a missing test for monotypes in data
      constructor return types.  And I realised that we were even allowing
      things like
      	Num (forall a. a) => ...
      which we definitely should not.  
      This patch insists on monotypes in several places where we were (wrongly)
      too liberal before.
      Could be merged to 6.8 but no big deal.
  6. 04 Jan, 2008 1 commit
  7. 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 
  8. 26 Nov, 2007 3 commits
  9. 19 Nov, 2007 1 commit
  10. 16 Nov, 2007 2 commits
  11. 12 Nov, 2007 1 commit
  12. 06 Nov, 2007 3 commits
  13. 07 Oct, 2007 1 commit
  14. 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.
  15. 24 Sep, 2007 1 commit
  16. 11 Sep, 2007 1 commit
  17. 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.
  18. 29 Aug, 2007 1 commit
  19. 30 Aug, 2007 1 commit
  20. 24 Aug, 2007 1 commit
  21. 20 Aug, 2007 1 commit
  22. 09 Aug, 2007 1 commit
  23. 04 Aug, 2007 1 commit
  24. 01 Aug, 2007 1 commit
  25. 21 Jun, 2007 2 commits
    • 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
    • Ian Lynagh's avatar
  26. 20 Jun, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Implement -X=GADTs and -X=RelaxedPolyRec · 970d5b88
      simonpj@microsoft.com authored
      Two new -X flags, one for GADTs and one for relaxed polymorphic recursion
      This also fixes a rather confusing error message that the Darcs folk 
      tripped over.
    • simonpj@microsoft.com's avatar
      Use -X for language extensions · 5e05865d
      simonpj@microsoft.com authored
      We've often talked about having a separate flag for language extensions,
      and now we have one. You can say
      as you like.  These replace the "-f" flags with similar names (though
      the -f prefix will serve as a synonym for -X for a while).  
      There's an optional "=", and the flag is normalised by removing hyphens
      and lower-casing, so all the above variants mean the same thing.
      The nomenclature is intended to match the LANGUAGE pramgas, which are
      defined by Cabal.  So you can also say
      	{-# LANGUAGE ImplicitParams #-}
      But Cabal doesn't have as many language options as GHC does, so the -X
      things are a superset of the LANGUAGE things.
      The optional "=" applies to all flags that take an argument, so you can,
      for example, say
      I hope that's ok.  (It's an unforced change; just fitted in.)
      I hope we'll add more -X flags, to replace the portmanteau -fglasgow-exts 
      which does everything!  
      I have updated the manual, but doubtless missed something.
  27. 19 Jun, 2007 1 commit
  28. 15 May, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Added -ftype-families to the user's manual · 25ebbb76
      chak@cse.unsw.edu.au. authored
      - This adds the option to the flag reference and puts a stub pointing to the
        Haskell wiki page about type families into the section about type extensions.
      - Once, the implementation has stabilised, the material from the wiki page 
        will be integreated into the user's manual.
  29. 02 May, 2007 2 commits
  30. 28 Mar, 2007 1 commit
  31. 22 Mar, 2007 1 commit
  32. 27 Feb, 2007 1 commit