[commit: ghc] wip/type-app: Visible type application (6d2bf73)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : wip/type-app
Link       : http://ghc.haskell.org/trac/ghc/changeset/6d2bf73e8d207efcec503c75e996da6a8d85d2fa/ghc

>---------------------------------------------------------------

commit 6d2bf73e8d207efcec503c75e996da6a8d85d2fa
Author: Richard Eisenberg <eir at cis.upenn.edu>
Date:   Fri Aug 7 08:13:54 2015 -0400

    Visible type application
    
    Summary:
    This implements visible type application into GHC, as described in
    http://www.seas.upenn.edu/~sweirich/papers/type-app-extended.pdf
    
    Very briefly, this means (with new extension `TypeApplications`
    enabled) that you can say `show (read @Int "5")` and get the
    behavior that you want.
    
    This is a sizable change to the type-checker, because it means that
    `tcExpr` does //not// instantiate types it infers. Instead, types
    are instantiated only when required. The details are in the paper.
    
    * At this point, kind variables may not be visibly instantiated. I
    expect to fix this deficiency in the merging type/kind work.
    
    * Visible type application is not yet available in patterns, only
    expressions. I expect to fix this, also.
    
    * This patch also adds some more tidying to TcValidity, necessary
    for good error messages. This actually fixes a bug unrelated to
    visible type application.
    
    * There are some open design questions. I will post to #5296, as
    Trac seems a better forum for design issues.
    
    There is one part of this patch which is atrociously ugly. As
    described in the paper, we must keep track of the difference between
    specified type variables (as given by the user) and inferred type
    variables (as generated by GHC). There is not a convenient place to
    mark this distinction. BUT, there //is// a convenient place in my
    merging types/kinds patch, which should land for 7.12. So I did
    an ugly thing: I put the bit in the `Name` of the type variable,
    using `System` names for inferred variables and `Internal` names for
    specified ones. This was actually only a small change from existing
    practice, but I well know that having type-checking depend on a
    variable's `Name` is terrible. However, I think it's better for this
    patch to land separate from my types/kinds patch, and changing
    `ForAllTy` to note the specified/inferred distinction would duplicate
    a bunch of effort in my other patch. Thus the compromise seen here.
    This behavior will be removed when this patch is merged into my
    other one.
    
    If this is just too ugly, I can accept that and merge this with
    my other patch internally, without going via `master`.
    
    Test Plan: ./validate
    
    Reviewers: simonpj, bgamari, austin, hvr
    
    Subscribers: thomie, mpickering
    
    Differential Revision: https://phabricator.haskell.org/D1138
    
    GHC Trac Issues: #5296, #10619, #10589, #10709.


>---------------------------------------------------------------

6d2bf73e8d207efcec503c75e996da6a8d85d2fa
 docs/users_guide/7.12.1-notes.xml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/docs/users_guide/7.12.1-notes.xml b/docs/users_guide/7.12.1-notes.xml
index b026507..b80db1d 100644
--- a/docs/users_guide/7.12.1-notes.xml
+++ b/docs/users_guide/7.12.1-notes.xml
@@ -72,6 +72,13 @@
             </listitem>
 	    <listitem>
 	      <para>
+		GHC now supports visible type application, allowing programmers
+		to easily specify how type parameters should be instantiated
+		when calling a function. See <xref linkend="visible-type-application"/> for the details.
+	      </para>
+	    </listitem>
+	    <listitem>
+	      <para>
 		To conform to the common case, the default role assigned to parameters
 		of datatypes declared in <literal>hs-boot</literal> files is
 		<literal>representational</literal>. However, if the constructor(s)