Commit 8b480d31 authored by David Feuer's avatar David Feuer Committed by Austin Seipp
Browse files

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
parent 09b79433
...@@ -291,6 +291,17 @@ checking for duplicates. The reason for this is efficiency, pure and simple. ...@@ -291,6 +291,17 @@ checking for duplicates. The reason for this is efficiency, pure and simple.
if you get stuck on it.</para> if you get stuck on it.</para>
</listitem> </listitem>
</varlistentry> </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> <varlistentry>
<term><literal>zip</literal> and <literal>zipWith</literal> semantics</term> <term><literal>zip</literal> and <literal>zipWith</literal> semantics</term>
<para><literal>zip</literal> and <literal>zipWith</literal> can give <para><literal>zip</literal> and <literal>zipWith</literal> can give
......
Markdown is supported
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