Skip to content
Snippets Groups Projects
Commit d4ae21ae authored by Doug Burke's avatar Doug Burke Committed by thoughtpolice
Browse files

Rearrange order of the release note highlights 

Summary:
I noticed that the highlights do not highlight the breaking changes first,
so I re-ordered them to what - to me, as a general and not power-user of
ghc - seems a more sensible order.

Should I have opened a ticket for this?

Test Plan: This is a doc change.

Reviewers: ezyang, austin

Reviewed By: ezyang, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D736

GHC Trac Issues: #10038
parent b189a5a3
No related merge requests found
Hide whitespace changes
Inline Side-by-side
docs/users_guide/7.10.1-notes.xml
+ 46
− 37
View file @ d4ae21ae
......@@ -16,19 +16,6 @@
</para>
<itemizedlist>
<listitem>
<para>
GHC now has support for plugins which modify the type
checker. This allows external users to interface with
GHC and write type-checking plugins to solve
constraints and equalities generated by the
typechecker.
</para>
<para>
This feature is experimental and will likely change in
the future.
</para>
</listitem>
<listitem>
<para>
GHC has implemented "The Applicative Monad Proposal",
......@@ -36,6 +23,9 @@
is now a superclass of <literal>Monad</literal>. This
is a breaking change and your programs will need to be
updated.
Please see the <ulink
href="https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10">GHC
7.10 Migration Guide</ulink> on the GHC wiki.
</para>
</listitem>
<listitem>
......@@ -47,6 +37,9 @@
<literal>Data.Traversable</literal>), rather than exporting
custom, less-generic versions. This is a change that
may require updates to your program.
Please see the <ulink
href="https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10">GHC
7.10 Migration Guide</ulink> on the GHC wiki.
</para>
</listitem>
<listitem>
......@@ -56,6 +49,40 @@
signature that the compiler can later infer. For more,
see <xref linkend="partial-type-signatures"/>.
</para>
</listitem>
<listitem>
<para>
The <literal>integer-gmp</literal> package has been
completely rewritten from the ground up. The primary
change in this rewrite is that GHC-compiled programs
that link to GMP no longer 'hook' GMP allocation
routines, to create an <literal>Integer</literal> on
the raw Haskell heap. Instead,
<literal>integer-gmp</literal> now allocates all
memory in Haskell code, and talks to GMP via normal
FFI imports like other C code.
</para>
<para>
The practical side effect of this is that C libraries
which bind to GMP (such as MPFR or FLINT) no longer
need careful (or impossible) hacks to be used inside a
GHC-compiled program via the FFI; GMP is treated just
like any other C library, with no special
accomodations.
</para>
</listitem>
<listitem>
<para>
GHC now has support for plugins which modify the type
checker. This allows external users to interface with
GHC and write type-checking plugins to solve
constraints and equalities generated by the
typechecker.
</para>
<para>
This feature is experimental and will likely change in
the future.
</para>
</listitem>
<listitem>
<para>
......@@ -87,27 +114,6 @@
should still be useful today.
</para>
</listitem>
<listitem>
<para>
The <literal>integer-gmp</literal> package has been
completely rewritten from the ground up. The primary
change in this rewrite is that GHC-compiled programs
that link to GMP no longer 'hook' GMP allocation
routines, to create an <literal>Integer</literal> on
the raw Haskell heap. Instead,
<literal>integer-gmp</literal> now allocates all
memory in Haskell code, and talks to GMP via normal
FFI imports like other C code.
</para>
<para>
The practical side effect of this is that C libraries
which bind to GMP (such as MPFR or FLINT) no longer
need careful (or impossible) hacks to be used inside a
GHC-compiled program via the FFI; GMP is treated just
like any other C library, with no special
accomodations.
</para>
</listitem>
</itemizedlist>
</sect2>
......@@ -881,19 +887,22 @@ echo "[]" > package.conf
On Mac OS X, the <literal>-threaded</literal> Garbage
Collector currently suffers from a large performance
penalty due to a lack of system-specific optimization
(issue #7602).
(<ulink
href="https://ghc.haskell.org/trac/ghc/ticket/7602">issue #7602</ulink>).
</para>
</listitem>
<listitem>
<para>
GHC's LLVM backend is currently incompatible with LLVM
3.4 (issue #9929).
3.4 (<ulink
href="https://ghc.haskell.org/trac/ghc/ticket/9929">issue #9929</ulink>).
</para>
</listitem>
<listitem>
<para>
GHCi fails to appropriately load
<literal>.dyn_o</literal> files (issue #8736).
<literal>.dyn_o</literal> files (<ulink
href="https://ghc.haskell.org/trac/ghc/ticket/8736">issue #8736</ulink>).
</para>
</listitem>
<listitem>
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment