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
--=_--
.
