From 625c02e2464078c5c95fbb7a6be0e2b9740935fd Mon Sep 17 00:00:00 2001 From: Hai <35925806+BestYeen@users.noreply.github.com> Date: Mon, 2 Mar 2026 22:16:46 +0100 Subject: [PATCH 1/3] Update introduction.rst Small edits for readability --- doc/introduction.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/introduction.rst b/doc/introduction.rst index 75ff7817..bad0d2fb 100644 --- a/doc/introduction.rst +++ b/doc/introduction.rst @@ -10,13 +10,13 @@ Like yacc, it takes a file containing an annotated BNF specification of a gramma single: yacc Happy is flexible: you can have several Happy parsers in the same program, and each parser may have multiple entry points. -Happy can work in conjunction with a lexical analyser supplied by the user (either hand-written or generated by another program), +Happy can work in conjunction with a lexical analyser supplied by the user (either handwritten or generated by another program), or it can parse a stream of characters directly (but this isn't practical in most cases). In a future version we hope to include a lexical analyser generator with Happy as a single package. Parsers generated by Happy are fast; generally faster than an equivalent parser written using parsing combinators or similar tools. -Furthermore, any future improvements made to Happy will benefit an existing grammar, without need for a rewrite. +Furthermore, any future improvements made to Happy will benefit an existing grammar, without the need for a rewrite. Happy is sufficiently powerful to parse full Haskell --- `GHC `__ itself uses a Happy parser. @@ -52,7 +52,7 @@ The types of parser supported are: This is the fastest/smallest option for GHC users. If you're using GHC, the optimum flag settings are ``-agc`` (see :ref:`Invoking `). -Happy can also generate parsers which will dump debugging information at run time, +Happy can also generate parsers which will dump debugging information at runtime, showing state transitions and the input tokens to the parser. .. _sec-compatibility: From d0df3cf5cecd190b8e492b9a365022580f1ee7a4 Mon Sep 17 00:00:00 2001 From: Hai <35925806+BestYeen@users.noreply.github.com> Date: Mon, 2 Mar 2026 22:19:05 +0100 Subject: [PATCH 2/3] Update using.rst Small edits for readability --- doc/using.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/using.rst b/doc/using.rst index ac3557b3..2d331115 100644 --- a/doc/using.rst +++ b/doc/using.rst @@ -30,7 +30,7 @@ In a grammar file, Haskell code is always contained between curly braces to dist In this case, the parser will be a standalone program so we'll call the module ``Main``. -Next comes a couple of declarations: +Next come a couple of declarations: .. code-block:: none @@ -341,7 +341,7 @@ Sequences with separators ~~~~~~~~~~~~~~~~~~~~~~~~~ A common type of sequence is one with a *separator*: -for instance function bodies in C consist of statements separated by semicolons. +for instance, function bodies in C consist of statements separated by semicolons. To parse this kind of sequence we use a production like this: .. code-block:: none @@ -1058,7 +1058,7 @@ the use of the two-action form of the ``%error`` directive The directive specifies a pair of functions ``abort`` and ``report`` which are necessary to handle multiple parse errors. -The generated parser parses errorneous input such as ``1+;+1;(1+;1`` as +The generated parser parses erroneous input such as ``1+;+1;(1+;1`` as ``["1 + catch", "catch + 1", "catch", "1"]``, with one list element per parsed statement. To a first approximation, one can think of ``catch`` as standing in for the @@ -1119,7 +1119,7 @@ A couple of notes: Note that defining a good AST representation for syntax errors is entirely up to the user of happy; the example above simply emitted the string ``catch`` -whenever it stands-in an for an errorneous AST node. +whenever it stands-in an for an erroneous AST node. A more reasonable implementation would be similar to typed holes in GHC. .. _sec-multiple-parsers: From 14ab2537762c2a2b50284a5c5a49b44fa9b24391 Mon Sep 17 00:00:00 2001 From: Hai <35925806+BestYeen@users.noreply.github.com> Date: Mon, 2 Mar 2026 22:20:33 +0100 Subject: [PATCH 3/3] Update tips.rst Small edits for readability --- doc/tips.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/tips.rst b/doc/tips.rst index 320573dc..f5464c25 100644 --- a/doc/tips.rst +++ b/doc/tips.rst @@ -36,7 +36,7 @@ so here's some tips on making things more sensible: - Include as little code as possible in the module trailer. This code is included verbatim in the generated parser, so if any of it can go in a separate module, do so. -- Give :index:`type signatures ` for everything (see :ref:`Type Signatures `. +- Give :index:`type signatures ` for everything (see :ref:`Type Signatures `). This is reported to improve things by about 50%. If there is a type signature for every single non-terminal in the grammar, then Happy automatically generates type signatures for most functions in the parser. @@ -62,7 +62,7 @@ An info file (generated by the ``-i`` option) can be helpful here. .. index:: single: type; signatures in grammar -Type signature sometimes help by pinning down the particular error to the place where the mistake is made, not half way down the file. +Type signatures sometimes help by pinning down the particular error to the place where the mistake is made, not halfway down the file. For each production in the grammar, there's a bit of code in the generated file that looks like this: .. code-block:: haskell