<commit_before><?xml version="1.0" encoding="iso-8859-1"?>
<chapter id="bugs-and-infelicities">
  <title>Known bugs and infelicities</title>

  <sect1 id="vs-Haskell-defn">
    <title>Haskell&nbsp;98 vs.&nbsp;Glasgow Haskell: language non-compliance
</title>
    
    <indexterm><primary>GHC vs the Haskell 98 language</primary></indexterm>
    <indexterm><primary>Haskell 98 language vs GHC</primary></indexterm>

  <para>This section lists Glasgow Haskell infelicities in its
  implementation of Haskell&nbsp;98.  See also the &ldquo;when things
  go wrong&rdquo; section (<xref linkend="wrong"/>) for information
  about crashes, space leaks, and other undesirable phenomena.</para>

  <para>The limitations here are listed in Haskell Report order
  (roughly).</para>

  <sect2 id="haskell98-divergence">
    <title>Divergence from Haskell&nbsp;98</title>
    
      
    <sect3 id="infelicities-lexical">
      <title>Lexical syntax</title>
      
      <itemizedlist>
	<listitem>
	  <para>Certain lexical rules regarding qualified identifiers
	  are slightly different in GHC compared to the Haskell
	  report.  When you have
	  <replaceable>module</replaceable><literal>.</literal><replaceable>reservedop</replaceable>,
	  such as <literal>M.\</literal>, GHC will interpret it as a
	  single qualified operator rather than the two lexemes
	  <literal>M</literal> and <literal>.\</literal>.</para>
	</listitem>
      </itemizedlist>
    </sect3>
      
      <sect3 id="infelicities-syntax">
	<title>Context-free syntax</title>
	
	<itemizedlist>
	  <listitem>
	    <para>GHC is a little less strict about the layout rule when used
	      in <literal>do</literal> expressions.  Specifically, the
	      restriction that "a nested context must be indented further to
	      the right than the enclosing context" is relaxed to allow the
	      nested context to be at the same level as the enclosing context,
	      if the enclosing context is a <literal>do</literal>
	      expression.</para>

	    <para>For example, the following code is accepted by GHC:

<programlisting>
main = do args &lt;- getArgs
	  if null args then return [] else do
          ps &lt;- mapM process args
          mapM print ps</programlisting>

	      </para>
	  </listitem>

	<listitem>
	  <para>GHC doesn't do fixity resolution in expressions during
	  parsing.  For example, according to the Haskell report, the
	  following expression is legal Haskell:
<programlisting>
    let x = 42 in x == 42 == True</programlisting>
	and parses as:
<programlisting>
    (let x = 42 in x == 42) == True</programlisting>

          because according to the report, the <literal>let</literal>
	  expression <quote>extends as far to the right as
	  possible</quote>.  Since it can't extend past the second
	  equals sign without causing a parse error
	  (<literal>==</literal> is non-fix), the
	  <literal>let</literal>-expression must terminate there.  GHC
	  simply gobbles up the whole expression, parsing like this:
<programlisting>
    (let x = 42 in x == 42 == True)</programlisting>

          The Haskell report is arguably wrong here, but nevertheless
          it's a difference between GHC &amp; Haskell 98.</para>
	</listitem>
      </itemizedlist>
    </sect3>

  <sect3 id="infelicities-exprs-pats">
      <title>Expressions and patterns</title>

	<para>None known.</para>
    </sect3>

    <sect3 id="infelicities-decls">
      <title>Declarations and bindings</title>

      <para>GHC's typechecker makes all pattern bindings monomorphic
      by default; this behaviour can be disabled with
      <option>-XNoMonoPatBinds</option>.  See <xref
      linkend="options-language" />.</para>
    </sect3>
      
      <sect3 id="infelicities-Modules">
	<title>Module system and interface files</title>
	
	<para>None known.</para>
    </sect3>

    <sect3 id="infelicities-numbers">
      <title>Numbers, basic types, and built-in classes</title>

      <variablelist><commit_msg>Fix Trac #2518: add hs-boot files as an infelicty<commit_after><?xml version="1.0" encoding="iso-8859-1"?>
<chapter id="bugs-and-infelicities">
  <title>Known bugs and infelicities</title>

  <sect1 id="vs-Haskell-defn">
    <title>Haskell&nbsp;98 vs.&nbsp;Glasgow Haskell: language non-compliance
</title>
    
    <indexterm><primary>GHC vs the Haskell 98 language</primary></indexterm>
    <indexterm><primary>Haskell 98 language vs GHC</primary></indexterm>

  <para>This section lists Glasgow Haskell infelicities in its
  implementation of Haskell&nbsp;98.  See also the &ldquo;when things
  go wrong&rdquo; section (<xref linkend="wrong"/>) for information
  about crashes, space leaks, and other undesirable phenomena.</para>

  <para>The limitations here are listed in Haskell Report order
  (roughly).</para>

  <sect2 id="haskell98-divergence">
    <title>Divergence from Haskell&nbsp;98</title>
    
      
    <sect3 id="infelicities-lexical">
      <title>Lexical syntax</title>
      
      <itemizedlist>
	<listitem>
	  <para>Certain lexical rules regarding qualified identifiers
	  are slightly different in GHC compared to the Haskell
	  report.  When you have
	  <replaceable>module</replaceable><literal>.</literal><replaceable>reservedop</replaceable>,
	  such as <literal>M.\</literal>, GHC will interpret it as a
	  single qualified operator rather than the two lexemes
	  <literal>M</literal> and <literal>.\</literal>.</para>
	</listitem>
      </itemizedlist>
    </sect3>
      
      <sect3 id="infelicities-syntax">
	<title>Context-free syntax</title>
	
	<itemizedlist>
	  <listitem>
	    <para>GHC is a little less strict about the layout rule when used
	      in <literal>do</literal> expressions.  Specifically, the
	      restriction that "a nested context must be indented further to
	      the right than the enclosing context" is relaxed to allow the
	      nested context to be at the same level as the enclosing context,
	      if the enclosing context is a <literal>do</literal>
	      expression.</para>

	    <para>For example, the following code is accepted by GHC:

<programlisting>
main = do args &lt;- getArgs
	  if null args then return [] else do
          ps &lt;- mapM process args
          mapM print ps</programlisting>

	      </para>
	  </listitem>

	<listitem>
	  <para>GHC doesn't do fixity resolution in expressions during
	  parsing.  For example, according to the Haskell report, the
	  following expression is legal Haskell:
<programlisting>
    let x = 42 in x == 42 == True</programlisting>
	and parses as:
<programlisting>
    (let x = 42 in x == 42) == True</programlisting>

          because according to the report, the <literal>let</literal>
	  expression <quote>extends as far to the right as
	  possible</quote>.  Since it can't extend past the second
	  equals sign without causing a parse error
	  (<literal>==</literal> is non-fix), the
	  <literal>let</literal>-expression must terminate there.  GHC
	  simply gobbles up the whole expression, parsing like this:
<programlisting>
    (let x = 42 in x == 42 == True)</programlisting>

          The Haskell report is arguably wrong here, but nevertheless
          it's a difference between GHC &amp; Haskell 98.</para>
	</listitem>
      </itemizedlist>
    </sect3>

  <sect3 id="infelicities-exprs-pats">
      <title>Expressions and patterns</title>

	<para>None known.</para>
    </sect3>

    <sect3 id="infelicities-decls">
      <title>Declarations and bindings</title>

      <para>GHC's typechecker makes all pattern bindings monomorphic
      by default; this behaviour can be disabled with
      <option>-XNoMonoPatBinds</option>.  See <xref
      linkend="options-language" />.</para>
    </sect3>
      
      <sect3 id="infelicities-Modules">
	<title>Module system and interface files</title>
	
	<para>GHC requires the use of <literal>hs-boot</literal>
	  files to cut the recursive loops among mutually recursive modules
	  as described in <xref linkend="mutual-recursion"/>.  This more of an infelicity
	    than a bug: the Haskell Report says 
	  (<ulink url="http://haskell.org/onlinereport/modules.html#sect5.7">Section 5.7</ulink>) "Depending on the Haskell
	implementation used, separate compilation of mutually
	recursive modules may require that imported modules contain
	additional information so that they may be referenced before
	they are compiled. Explicit type signatures for all exported
	values may be necessary to deal with mutual recursion. The
	precise details of separate compilation are not defined by
	this Report."

	</para>

    </sect3>

    <sect3 id="infelicities-numbers">
      <title>Numbers, basic types, and built-in classes</title>

      <variablelist>
{'fraction_non_alphanumeric': 0.10330530922492226, 'fraction_numerical': 0.011516756881262236, 'mean_word_length': 3.462487153134635, 'pattern_counts': {'":': 0, '<': 220, '<?xml version=': 2, '>': 220, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7454468', 'n_tokens_mistral': 2815, 'n_tokens_neox': 2478, 'n_words': 879}