[commit: ghc] master: Document splitAt deviation from the Report (8b480d3)

git at git.haskell.org git at git.haskell.org
Wed Dec 10 01:58:37 UTC 2014


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

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/8b480d3192e6eff6183934d7bbcc2054611c3651/ghc

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

commit 8b480d3192e6eff6183934d7bbcc2054611c3651
Author: David Feuer <david.feuer at gmail.com>
Date:   Tue Dec 9 18:12:33 2014 -0600

    Document splitAt deviation from the Report
    
    Summary:
    `splitAt` is stricter than the Report specifies, so we should
    say so.
    
    Reviewers: hvr, austin
    
    Reviewed By: austin
    
    Subscribers: carter, thomie
    
    Projects: #ghc
    
    Differential Revision: https://phabricator.haskell.org/D562
    
    GHC Trac Issues: #9870


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

8b480d3192e6eff6183934d7bbcc2054611c3651
 docs/users_guide/bugs.xml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/docs/users_guide/bugs.xml b/docs/users_guide/bugs.xml
index 2d6fc65..30770f0 100644
--- a/docs/users_guide/bugs.xml
+++ b/docs/users_guide/bugs.xml
@@ -292,6 +292,17 @@ checking for duplicates.  The reason for this is efficiency, pure and simple.
 	    </listitem>
 	  </varlistentry>
           <varlistentry>
+            <term><literal>splitAt</literal> semantics</term>
+            <para><literal>Data.List.splitAt</literal> is stricter than specified in the
+            Report. Specifically, the Report specifies that
+<programlisting>splitAt n xs = (take n xs, drop n xs)</programlisting>
+            which implies that
+<programlisting>splitAt undefined undefined = (undefined, undefined)</programlisting>
+            but GHC's implementation is strict in its first argument, so
+<programlisting>splitAt undefined [] = undefined</programlisting>
+            </para>
+          </varlistentry>
+          <varlistentry>
             <term><literal>zip</literal> and <literal>zipWith</literal> semantics</term>
             <para><literal>zip</literal> and <literal>zipWith</literal> can give
             less defined results than the Report specifies in certain cases. This deviation



More information about the ghc-commits mailing list