Proposal: put Happy and Alex discussion/patches/etc under the libraries@haskell.org domain, even though they're not technically libraries. (their purpose is very similar to Parsec's, for example, which is a library; and GHC depends on them, though from the end-user's point of view it's not quite as strong a dependency as the boot-libs) This patch is bugfixes for Happy that I discovered when trying to make GHC's code more portable (so I was testing using happy without -agc for the first time) (I sent this first to cvs-ghc@haskell.org but I figured I should really ask the community anyway). (I have a more controversial topic/patch to propose for Alex and Happy later...) ~Isaac Thu Dec 27 07:57:38 EST 2007 Isaac Dupree * bugfix: allow multi-word token-type using parentheses everywhere needed Thu Dec 27 11:54:46 EST 2007 Isaac Dupree * refactor HappyReduction-generating code (no semantic change) Thu Dec 27 12:04:54 EST 2007 Isaac Dupree * self-expand HappyReduction for more Haskell98 compliance It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? To: cvs-ghc@haskell.org From: Isaac Dupree Subject: darcs patch: bugfix: allow multi-word token-type usin... (and 2 more) X-Mail-Originator: Darcs Version Control System X-Darcs-Version: 1.0.9 (release) DarcsURL: http://darcs.haskell.org/happy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_" --=_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thu Dec 27 07:57:38 EST 2007 Isaac Dupree * bugfix: allow multi-word token-type using parentheses everywhere needed Thu Dec 27 11:54:46 EST 2007 Isaac Dupree * refactor HappyReduction-generating code (no semantic change) Thu Dec 27 12:04:54 EST 2007 Isaac Dupree * self-expand HappyReduction for more Haskell98 compliance It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? --=_ Content-Type: text/x-darcs-patch; name="bugfix_-allow-multi_word-token_type-using-parentheses-everywhere-needed.dpatch" Content-Transfer-Encoding: quoted-printable Content-Description: A darcs patch for your repository! New patches: [bugfix: allow multi-word token-type using parentheses everywhere needed Isaac Dupree **20071227125738] { hunk ./src/ProduceCode.lhs 85 +> token =3D brack token_type hunk ./src/ProduceCode.lhs 148 -> . str "happyInTok :: " . str token_type . str " -> " . bhappy_item +> . str "happyInTok :: " . token . str " -> " . bhappy_item hunk ./src/ProduceCode.lhs 151 -> . str "happyOutTok :: " . bhappy_item . str " -> " . str token_type +> . str "happyOutTok :: " . bhappy_item . str " -> " . token hunk ./src/ProduceCode.lhs 177 -> . str "\n\t=3D HappyTerminal " . str token_type +> . str "\n\t=3D HappyTerminal " . token hunk ./src/ProduceCode.lhs 232 -> token =3D brack token_type hunk ./src/ProduceCode.lhs 707 -> . str token_type +> . token hunk ./src/ProduceCode.lhs 720 -> . str token_type . str " -> " = +> . token . str " -> " = } [refactor HappyReduction-generating code (no semantic change) Isaac Dupree **20071227165446] { hunk ./src/ProduceCode.lhs 201 -> str "type HappyReduction m =3D \n\t" -> . str " " -> . intMaybeHash -> . str " \n\t-> " . token -> . str "\n\t-> HappyState " -> . token -> . str " (HappyStk HappyAbsSyn -> " . tokens . result -> . str ")\n\t" -> . str "-> [HappyState " -> . token -> . str " (HappyStk HappyAbsSyn -> " . tokens . result -> . str ")] \n\t-> HappyStk HappyAbsSyn \n\t-> " -> . tokens -> . result -> . str "\n\n" +> happyReductionDefinition . str "\n\n" hunk ./src/ProduceCode.lhs 206 -> . intMaybeHash -> . str " -> HappyReduction (" . str monad_tycon . str ")\n\n" +> . intMaybeHash . str " -> " . happyReductionValue . str "\n\n" hunk ./src/ProduceCode.lhs 211 -> . str " :: " . str monad_context . str " =3D> HappyReduction (" . st= r monad_tycon . str ")\n\n" = +> . str " :: " . str monad_context . str " =3D> " +> . happyReductionValue . str "\n\n" hunk ./src/ProduceCode.lhs 222 -> result =3D (str "m HappyAbsSyn") +> happyReductionDefinition =3D +> str "type HappyReduction m =3D " +> . happyReduction (str "m") +> happyReductionValue =3D +> str "HappyReduction " +> . brack monad_tycon +> happyReduction m =3D +> str "\n\t " +> . intMaybeHash +> . str " \n\t-> " . token +> . str "\n\t-> HappyState " +> . token +> . str " (HappyStk HappyAbsSyn -> " . tokens . result +> . str ")\n\t" +> . str "-> [HappyState " +> . token +> . str " (HappyStk HappyAbsSyn -> " . tokens . result +> . str ")] \n\t-> HappyStk HappyAbsSyn \n\t-> " +> . tokens +> . result +> where result =3D m . str " HappyAbsSyn" } [self-expand HappyReduction for more Haskell98 compliance Isaac Dupree **20071227170454 It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? ] { hunk ./src/ProduceCode.lhs 223 -> str "type HappyReduction m =3D " +> str "{- to allow type-synonyms as our monads (likely\n" +> . str " - with explicitly-specified bind and return)\n" +> . str " - in Haskell98, it seems that with\n" +> . str " - /type M a =3D .../, then /(HappyReduction M)/\n" +> . str " - is not allowed. But Happy is a\n" +> . str " - code-generator that can just substitute it.\n" +> . str "type HappyReduction m =3D " hunk ./src/ProduceCode.lhs 231 +> . str "\n-}" hunk ./src/ProduceCode.lhs 233 -> str "HappyReduction " +> str "({-" +> . str "HappyReduction " hunk ./src/ProduceCode.lhs 236 +> . str " =3D -}" +> . happyReduction (brack monad_tycon) +> . str ")" } Context: [update following recent Cabal changes Simon Marlow **20071026150947] = [TAG 1.17 RELEASE Simon Marlow **20071023145501] = Patch bundle hash: 7b85a9d0b16a315f2996831afcf214299b4bd4cb --=_-- .