Merge branch 'master' of darcs.haskell.org:/home/darcs/ghc
authorSimon Peyton Jones <simonpj@microsoft.com>
Wed, 15 Aug 2012 13:24:43 +0000 (14:24 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Wed, 15 Aug 2012 13:24:43 +0000 (14:24 +0100)
1  2 
compiler/typecheck/TcInstDcls.lhs
docs/users_guide/glasgow_exts.xml

@@@ -237,7 -237,7 +237,7 @@@ end up with non-inlined dictionaries th
      $df = $cop |> blah
  which adds an extra indirection to every use, which seems stupid.  See
  Trac #4138 for an example (although the regression reported there
 -wasn't due to the indirction).
 +wasn't due to the indirection).
  
  There is an awkward wrinkle though: we want to be very
  careful when we have
@@@ -432,7 -432,7 +432,7 @@@ addFamInsts :: [FamInst] -> TcM a -> Tc
  --        (b) the type envt with stuff from data type decls
  addFamInsts fam_insts thing_inside
    = tcExtendLocalFamInstEnv fam_insts $ 
-     tcExtendGlobalEnvImplicit things  $ 
+     tcExtendGlobalEnv things $
      do { traceTc "addFamInsts" (pprFamInsts fam_insts)
         ; tcg_env <- tcAddImplicits things
         ; setGblEnv tcg_env thing_inside }
@@@ -71,17 -71,18 +71,18 @@@ documentation</ulink> describes all th
  <para>GHC is built on a raft of primitive data types and operations;
  "primitive" in the sense that they cannot be defined in Haskell itself.
  While you really can use this stuff to write fast code,
  we generally find it a lot less painful, and more satisfying in the
  long run, to use higher-level language features and libraries.  With
  any luck, the code you write will be optimised to the efficient
  unboxed version in any case.  And if it isn't, we'd like to know
  about it.</para>
+ we generally find it a lot less painful, and more satisfying in the
+ long run, to use higher-level language features and libraries.  With
+ any luck, the code you write will be optimised to the efficient
+ unboxed version in any case.  And if it isn't, we'd like to know
+ about it.</para>
  
  <para>All these primitive data types and operations are exported by the
  library <literal>GHC.Prim</literal>, for which there is
  <ulink url="&libraryGhcPrimLocation;/GHC-Prim.html">detailed online documentation</ulink>.
  (This documentation is generated from the file <filename>compiler/prelude/primops.txt.pp</filename>.)
  </para>
  <para>
  If you want to mention any of the primitive data types or operations in your
  program, you must first import <literal>GHC.Prim</literal> to bring them
@@@ -94,8 -95,7 +95,7 @@@ and <link linkend="unboxed-tuples">unbo
  we briefly summarise here. </para>
  
  <sect2 id="glasgow-unboxed">
- <title>Unboxed types
- </title>
+ <title>Unboxed types</title>
  
  <para>
  <indexterm><primary>Unboxed types (Glasgow extension)</primary></indexterm>
@@@ -202,8 -202,7 +202,7 @@@ since <literal>b</literal> has type <li
  </sect2>
  
  <sect2 id="unboxed-tuples">
- <title>Unboxed Tuples
- </title>
+ <title>Unboxed tuples</title>
  
  <para>
  Unboxed tuples aren't really exported by <literal>GHC.Exts</literal>;
@@@ -238,46 -237,19 +237,19 @@@ tuples to avoid unnecessary allocation 
  </para>
  
  <para>
- There are some pretty stringent restrictions on the use of unboxed tuples:
+ There are some restrictions on the use of unboxed tuples:
  <itemizedlist>
- <listitem>
  
+ <listitem>
  <para>
  Values of unboxed tuple types are subject to the same restrictions as
  other unboxed types; i.e. they may not be stored in polymorphic data
  structures or passed to polymorphic functions.
  </para>
  </listitem>
- <listitem>
- <para>
- No variable can have an unboxed tuple type, nor may a constructor or function
- argument have an unboxed tuple type.  The following are all illegal:
- <programlisting>
-   data Foo = Foo (# Int, Int #)
-   f :: (# Int, Int #) -&#62; (# Int, Int #)
-   f x = x
  
-   g :: (# Int, Int #) -&#62; Int
-   g (# a,b #) = a
-   h x = let y = (# x,x #) in ...
- </programlisting>
- </para>
- </listitem>
  <listitem>
  <para>
- Unboxed tuples may not be nested. So this is illegal:
- <programlisting>
- f :: (# Int, (# Int, Int #), Bool #)
- </programlisting>
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
  The typical use of unboxed tuples is simply to return multiple values,
  binding those multiple results with a <literal>case</literal> expression, thus:
  <programlisting>
@@@ -299,6 -271,10 +271,10 @@@ above example desugars like this
  </programlisting>
  Indeed, the bindings can even be recursive.
  </para>
+ </listitem>
+ </itemizedlist>
+ </para>
  
  </sect2>
  </sect1>
@@@ -7065,94 -7041,6 +7041,94 @@@ If you supply a type signature, then th
  </sect1>
  <!-- ==================== End of type system extensions =================  -->
  
 +<sect1 id="defer-type-errors">
 +<title>Deferring type errors to runtime</title>
 +  <para>
 +    While developing, sometimes it is desirable to allow compilation to succeed
 +    even if there are type errors in the code. Consider the following case:
 +<programlisting>
 +module Main where
 +
 +a :: Int
 +a = 'a'
 +
 +main = print "b"
 +</programlisting>
 +    Even though <literal>a</literal> is ill-typed, it is not used in the end, so if
 +    all that we're interested in is <literal>main</literal> it can be useful to be
 +    able to ignore the problems in <literal>a</literal>.
 +  </para>
 +  <para>
 +    For more motivation and details please refer to the <ulink
 +      url="http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime">HaskellWiki</ulink>
 +    page or the <ulink
 +      url="http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/">original
 +      paper</ulink>.
 +  </para>
 +
 +<sect2><title>Enabling deferring of type errors</title>
 +  <para>
 +    The flag <literal>-fdefer-type-errors</literal> controls whether type
 +    errors are deferred to runtime. Type errors will still be emitted as
 +    warnings, but will not prevent compilation.
 +  </para>
 +  <para>
 +    At runtime, whenever a term containing a type error would need to be
 +    evaluated, the error is converted into a runtime exception.
 +    Note that type errors are deferred as much as possible during runtime, but
 +    invalid coercions are never performed, even when they would ultimately
 +    result in a value of the correct type. For example, given the following
 +    code:
 +<programlisting>
 +x :: Int
 +x = 0
 +
 +y :: Char
 +y = x
 +
 +z :: Int
 +z = y
 +</programlisting>
 +    evaluating <literal>x</literal> will result in a runtime type error.
 +  </para>
 +</sect2>
 +<sect2><title>Deferred type errors in GHCi</title>
 +  <para>
 +    The flag <literal>-fdefer-type-errors</literal> works in GHCi as well, with
 +    one exception: for "naked" expressions typed at the prompt, type
 +    errors don't get delayed, so for example:
 +<programlisting>
 +Prelude> fst (True, 1 == 'a')
 +
 +&lt;interactive&gt;:2:12:
 +    No instance for (Num Char) arising from the literal `1'
 +    Possible fix: add an instance declaration for (Num Char)
 +    In the first argument of `(==)', namely `1'
 +    In the expression: 1 == 'a'
 +    In the first argument of `fst', namely `(True, 1 == 'a')'
 +</programlisting>
 +Otherwise, in the common case of a simple type error such as 
 +typing <literal>reverse True</literal> at the prompt, you would get a warning and then
 +an immediately-following type error when the expression is evaluated.
 +  </para>
 +  <para>
 +    This exception doesn't apply to statements, as the following example demonstrates:
 +<programlisting>
 +Prelude> let x = (True, 1 == 'a')
 +
 +&lt;interactive&gt;:3:16: Warning:
 +    No instance for (Num Char) arising from the literal `1'
 +    Possible fix: add an instance declaration for (Num Char)
 +    In the first argument of `(==)', namely `1'
 +    In the expression: 1 == 'a'
 +    In the expression: (True, 1 == 'a')
 +Prelude> fst x
 +True
 +</programlisting>
 +  </para>
 +</sect2>
 +</sect1>
 +
  <!-- ====================== TEMPLATE HASKELL =======================  -->
  
  <sect1 id="template-haskell">