[commit: ghc] ghc-7.10: Rearrange order of the release note highlights (d4ae21a)
git at git.haskell.org
git at git.haskell.org
Tue Mar 24 15:27:51 UTC 2015
Repository : ssh://git@git.haskell.org/ghc
On branch : ghc-7.10
Link : http://ghc.haskell.org/trac/ghc/changeset/d4ae21ae7c1f8c198c5cccb1132db65f8c9bd8b6/ghc
>---------------------------------------------------------------
commit d4ae21ae7c1f8c198c5cccb1132db65f8c9bd8b6
Author: Douglas Burke <dburke.gw at gmail.com>
Date: Tue Mar 24 10:26:45 2015 -0500
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
>---------------------------------------------------------------
d4ae21ae7c1f8c198c5cccb1132db65f8c9bd8b6
docs/users_guide/7.10.1-notes.xml | 83 ++++++++++++++++++++++-----------------
1 file changed, 46 insertions(+), 37 deletions(-)
diff --git a/docs/users_guide/7.10.1-notes.xml b/docs/users_guide/7.10.1-notes.xml
index df7359e..7669d2c 100644
--- a/docs/users_guide/7.10.1-notes.xml
+++ b/docs/users_guide/7.10.1-notes.xml
@@ -18,24 +18,14 @@
<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",
meaning the <literal>Applicative</literal> typeclass
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>
@@ -59,6 +52,40 @@
</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>
GHC now has support for a new extension,
<literal>-XStaticPointers</literal>, that allows you
to (de)reference and serialize pointers to known,
@@ -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>
More information about the ghc-commits
mailing list