Re: Pattern synonyms for 7.8?

Hi,
Wow, so, I thought there would be some back-and-forth, then a decision,
then I would go and walk the last mile and then formally submit the patch
for review - and now I see that in <2 days all that has passed...
Of course I'll make validate pass, I just didn't even know about it.
Likewise, I needed the carrot of 7.8 inclusion dangling before me to start
writing the user docs.
One problem, though, is that I'll be on holiday from tomorrow, so I'll only
have time to look into this tonight before next weekend. I'll try my best
to fix up validate tonight, and I'll write the docs (which I hope will
mostly be an editing job on the wiki) next week. How does that sound?
Thanks,
Gergo
On Jan 8, 2014 3:41 AM, "Austin Seipp"
Hi Gergo,
Thanks for rebasing your changes. Unfortunately, they do not compile cleanly with ./validate, which we really need to have working for all incoming patches.
In particular, ./validate enables -Werror and a slew of warnings that you won't normally see during development, which greatly aids in keeping the code clean. One, for example, is that some of your commits introduce tabs - we ban tabs and validate errors on them!
Another: the problem is that in
https://github.com/gergoerdi/ghc/commit/afefa7ac948b1d7801d622824fbdd75ade2a... , you added a Monoid instance for UniqSet - but this doesn't work correctly. The problem is that UniqSet is just an alias for UniqFM (type UniqSet a = UniqFM a), so the instance is technically seen as an orphan. Orphan instances cause -Werror failures with ./validate (unless you disable them for that module, but here we really shouldn't.)
The fix is to write the Monoid instance for UniqFM directly in UniqFM.hs instead.
Likewise, here's a real bug that -Werror found in your patch in the renamer (by building with ./validate):
compiler/rename/RnBinds.lhs:744:1: Warning: Pattern match(es) are non-exhaustive In an equation for `renameSig': Patterns not matched: _ (PatSynSig _ _ _ _ _)
Indeed, renameSig in RnBinds doesn't check the PatSynSig case! The missing instance looks straightforward to implement, but this could have been a nasty bug waiting.
If you could please take the time to clean up the ./validate failures, I'd really appreciate it. I imagine it'll take very little time, and it will make merging much easier for me. An easy way to do it is just to check out your pattern-synonyms branches, then say:
$ CPUS=X sh ./validate
where 'X' is the number of cores, similar to 'make -jX'
If it fails, you can make a change, and keep going with:
$ CPUS=X sh ./validate --no-clean
and rinse and repeat until it's done.
Note the --no-clean is required, since `./validate` will immediately run `make distclean` by default if you do not specify it.
On Tue, Jan 7, 2014 at 5:50 AM, Dr. ERDI Gergo
wrote: On Mon, 6 Jan 2014, Carter Schonwald wrote:
as long as we clearly communicate that there may be refinements / breaking changes subsequently, i'm all for it, unless merging it in slows down 7.8 hitting RC . (its taken long enough for RC to happen... don't want to drag it out further)
If that helps, I've updated the version at https://github.com/gergoerdi/ghc (and the two sister repos https://github.com/gergoerdi/ghc-testsuite and https://github.com/gergoerdi/ghc-haddock) to be based on top of master as of today.
Bye, Gergo
--
.--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Elvis is dead and I don't feel so good either. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin - PGP: 4096R/0x91384671

On 07/01/14 23:05, Dr. ÉRDI Gergő wrote:
Hi,
Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in <2 days all that has passed...
Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs.
One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound?
Thanks, Gergo
Hi Erdi, I'm hoping to push in some stuff for Haddock in few hours (or rather, have someone do it for me) but I know you have changed a few things in it for the pattern synonyms stuff. I looked at the changes and they weren't big and shouldn't clash. Is it fine with you to push the changes on our side and then have you merge on top of that or would you prefer to have it done another way? Thanks -- Mateusz K.

Of course. That's how I've been keeping up with GHC proper all along.
On Jan 8, 2014 7:09 AM, "Mateusz Kowalczyk"
On 07/01/14 23:05, Dr. ÉRDI Gergő wrote:
Hi,
Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in <2 days all that has passed...
Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs.
One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound?
Thanks, Gergo
Hi Erdi,
I'm hoping to push in some stuff for Haddock in few hours (or rather, have someone do it for me) but I know you have changed a few things in it for the pattern synonyms stuff. I looked at the changes and they weren't big and shouldn't clash. Is it fine with you to push the changes on our side and then have you merge on top of that or would you prefer to have it done another way?
Thanks
-- Mateusz K. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi Gergo,
As pattern synonyms are user-facing, you should update the user manual along with (perhaps) the wiki. The file to edit is docs/users_guide/glasgow_exts.xml. You should also add a note to docs/users_guide/7.8.1_notes.xml.
Apologies if someone has already said this to you.
Richard
On Jan 7, 2014, at 6:05 PM, Dr. ÉRDI Gergő
Hi,
Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in <2 days all that has passed...
Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs.
One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound?
Thanks, Gergo
On Jan 8, 2014 3:41 AM, "Austin Seipp"
wrote: Hi Gergo, Thanks for rebasing your changes. Unfortunately, they do not compile cleanly with ./validate, which we really need to have working for all incoming patches.
In particular, ./validate enables -Werror and a slew of warnings that you won't normally see during development, which greatly aids in keeping the code clean. One, for example, is that some of your commits introduce tabs - we ban tabs and validate errors on them!
Another: the problem is that in https://github.com/gergoerdi/ghc/commit/afefa7ac948b1d7801d622824fbdd75ade2a..., you added a Monoid instance for UniqSet - but this doesn't work correctly. The problem is that UniqSet is just an alias for UniqFM (type UniqSet a = UniqFM a), so the instance is technically seen as an orphan. Orphan instances cause -Werror failures with ./validate (unless you disable them for that module, but here we really shouldn't.)
The fix is to write the Monoid instance for UniqFM directly in UniqFM.hs instead.
Likewise, here's a real bug that -Werror found in your patch in the renamer (by building with ./validate):
compiler/rename/RnBinds.lhs:744:1: Warning: Pattern match(es) are non-exhaustive In an equation for `renameSig': Patterns not matched: _ (PatSynSig _ _ _ _ _)
Indeed, renameSig in RnBinds doesn't check the PatSynSig case! The missing instance looks straightforward to implement, but this could have been a nasty bug waiting.
If you could please take the time to clean up the ./validate failures, I'd really appreciate it. I imagine it'll take very little time, and it will make merging much easier for me. An easy way to do it is just to check out your pattern-synonyms branches, then say:
$ CPUS=X sh ./validate
where 'X' is the number of cores, similar to 'make -jX'
If it fails, you can make a change, and keep going with:
$ CPUS=X sh ./validate --no-clean
and rinse and repeat until it's done.
Note the --no-clean is required, since `./validate` will immediately run `make distclean` by default if you do not specify it.
On Tue, Jan 7, 2014 at 5:50 AM, Dr. ERDI Gergo
wrote: On Mon, 6 Jan 2014, Carter Schonwald wrote:
as long as we clearly communicate that there may be refinements / breaking changes subsequently, i'm all for it, unless merging it in slows down 7.8 hitting RC . (its taken long enough for RC to happen... don't want to drag it out further)
If that helps, I've updated the version at https://github.com/gergoerdi/ghc (and the two sister repos https://github.com/gergoerdi/ghc-testsuite and https://github.com/gergoerdi/ghc-haddock) to be based on top of master as of today.
Bye, Gergo
--
.--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Elvis is dead and I don't feel so good either. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin - PGP: 4096R/0x91384671 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi Gergo,
I went ahead and pushed the preliminary work to a new branch in the
official repositories. GHC, haddock and testsuite now have a
'wip/pattern-synonyms' branch, where you can test the code:
https://github.com/ghc/ghc/commits/wip/pattern-synonyms
https://github.com/ghc/haddock/commits/wip/pattern-synonyms
https://github.com/ghc/testsuite/commits/wip/pattern-synonyms
Any intrepid parties are welcome to try it.
A few things of note:
1) As Richard pointed out, the docs are under docs/users_guide, as
well as the release notes. Please feel free to elaborate however you
want on the feature and the bulletpoint for the release notes.
2) The failures are indeed a result of your code, in particular:
driver T4437 [bad stdout] (normal)
generics GenDerivOutput [stderr mismatch] (normal)
generics GenDerivOutput1_0 [stderr mismatch] (normal)
generics GenDerivOutput1_1 [stderr mismatch] (normal)
rename/should_compile T7336 [stderr mismatch] (normal)
The first four are just tests that need to be updated. T4437 needs to
have PatternSynonyms listed (it tests the available extensions,) and
the generics test have had their output slightly changed. This is
because the generated terms are now annotated with the Origin type,
specifying where they come from. Here's an example from
GenDerivOutput1_1:
----------------------------
instance GHC.Generics.Selector CanDoRep1_1.S1_1_0Dd where
- GHC.Generics.selName _ = "d11d"
+ (Generated, GHC.Generics.selName _ = "d11d")
----------------------------
I'm not actually sure if this is what we want. Should -ddump-deriv
print this? I'm not sure we guarantee the output is syntactically
valid anyway, but it's worth considering. Removing this from the
output would mean these tests don't need any tweaks.
Perhaps Simon or Pedro have something to say.
3) It seems GHCi does not support declaring pattern synonyms at the
REPL. I'm not sure if it's intentional, but if it goes in like this,
please be sure to document it in the release notes. We can file a
ticket later for supporting pattern synonyms at the REPL.
On Wed, Jan 8, 2014 at 1:14 PM, Richard Eisenberg
Hi Gergo,
As pattern synonyms are user-facing, you should update the user manual along with (perhaps) the wiki. The file to edit is docs/users_guide/glasgow_exts.xml. You should also add a note to docs/users_guide/7.8.1_notes.xml.
Apologies if someone has already said this to you.
Richard
On Jan 7, 2014, at 6:05 PM, Dr. ÉRDI Gergő
wrote: Hi,
Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in <2 days all that has passed...
Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs.
One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound?
Thanks, Gergo
On Jan 8, 2014 3:41 AM, "Austin Seipp"
wrote: Hi Gergo,
Thanks for rebasing your changes. Unfortunately, they do not compile cleanly with ./validate, which we really need to have working for all incoming patches.
In particular, ./validate enables -Werror and a slew of warnings that you won't normally see during development, which greatly aids in keeping the code clean. One, for example, is that some of your commits introduce tabs - we ban tabs and validate errors on them!
Another: the problem is that in
https://github.com/gergoerdi/ghc/commit/afefa7ac948b1d7801d622824fbdd75ade2a..., you added a Monoid instance for UniqSet - but this doesn't work correctly. The problem is that UniqSet is just an alias for UniqFM (type UniqSet a = UniqFM a), so the instance is technically seen as an orphan. Orphan instances cause -Werror failures with ./validate (unless you disable them for that module, but here we really shouldn't.)
The fix is to write the Monoid instance for UniqFM directly in UniqFM.hs instead.
Likewise, here's a real bug that -Werror found in your patch in the renamer (by building with ./validate):
compiler/rename/RnBinds.lhs:744:1: Warning: Pattern match(es) are non-exhaustive In an equation for `renameSig': Patterns not matched: _ (PatSynSig _ _ _ _ _)
Indeed, renameSig in RnBinds doesn't check the PatSynSig case! The missing instance looks straightforward to implement, but this could have been a nasty bug waiting.
If you could please take the time to clean up the ./validate failures, I'd really appreciate it. I imagine it'll take very little time, and it will make merging much easier for me. An easy way to do it is just to check out your pattern-synonyms branches, then say:
$ CPUS=X sh ./validate
where 'X' is the number of cores, similar to 'make -jX'
If it fails, you can make a change, and keep going with:
$ CPUS=X sh ./validate --no-clean
and rinse and repeat until it's done.
Note the --no-clean is required, since `./validate` will immediately run `make distclean` by default if you do not specify it.
On Tue, Jan 7, 2014 at 5:50 AM, Dr. ERDI Gergo
wrote: On Mon, 6 Jan 2014, Carter Schonwald wrote:
as long as we clearly communicate that there may be refinements / breaking changes subsequently, i'm all for it, unless merging it in slows down 7.8 hitting RC . (its taken long enough for RC to happen... don't want to drag it out further)
If that helps, I've updated the version at https://github.com/gergoerdi/ghc (and the two sister repos https://github.com/gergoerdi/ghc-testsuite and https://github.com/gergoerdi/ghc-haddock) to be based on top of master as of today.
Bye, Gergo
--
.--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Elvis is dead and I don't feel so good either. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin - PGP: 4096R/0x91384671
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On Thu, Jan 9, 2014 at 9:48 AM, Austin Seipp
The first four are just tests that need to be updated. T4437 needs to have PatternSynonyms listed (it tests the available extensions,) and the generics test have had their output slightly changed. This is because the generated terms are now annotated with the Origin type, specifying where they come from. Here's an example from GenDerivOutput1_1:
---------------------------- instance GHC.Generics.Selector CanDoRep1_1.S1_1_0Dd where - GHC.Generics.selName _ = "d11d" + (Generated, GHC.Generics.selName _ = "d11d") ----------------------------
I'm not actually sure if this is what we want. Should -ddump-deriv print this? I'm not sure we guarantee the output is syntactically valid anyway, but it's worth considering. Removing this from the output would mean these tests don't need any tweaks.
I think it is preferable not to show this Generated stuff. Even if -ddump-deriv is not entirely syntactically valid, it often is, and I found myself copy-pasting from it multiple times before. Cheers, Pedro

Hi, On Thu, 9 Jan 2014, Austin Seipp wrote:
Hi Gergo,
I went ahead and pushed the preliminary work to a new branch in the official repositories. GHC, haddock and testsuite now have a 'wip/pattern-synonyms' branch, where you can test the code:
https://github.com/ghc/ghc/commits/wip/pattern-synonyms https://github.com/ghc/haddock/commits/wip/pattern-synonyms https://github.com/ghc/testsuite/commits/wip/pattern-synonyms
So what's the intended workflow for me from now on? Will master be regularly merged into this branch? Should I base my future work (like fixing the outstanding issues your mail detailed) on top of this branch and continue pushing to my github repo? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Why experiment on animals when there are so many lawyers?

On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote:
I went ahead and pushed the preliminary work to a new branch in the official repositories. GHC, haddock and testsuite now have a 'wip/pattern-synonyms' branch, where you can test the code:
https://github.com/ghc/ghc/commits/wip/pattern-synonyms https://github.com/ghc/haddock/commits/wip/pattern-synonyms https://github.com/ghc/testsuite/commits/wip/pattern-synonyms
So what's the intended workflow for me from now on? Will master be regularly merged into this branch? Should I base my future work (like fixing the outstanding issues your mail detailed) on top of this branch and continue pushing to my github repo?
Oh and also, how do I reword the commit message of the single squashed commit? I'm asking because there are some small fixes I'd like to do on the message. Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Speak the truth, but leave immediately after.

On 13/01/14 11:06, Dr. ERDI Gergo wrote:
On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote:
I went ahead and pushed the preliminary work to a new branch in the official repositories. GHC, haddock and testsuite now have a 'wip/pattern-synonyms' branch, where you can test the code:
https://github.com/ghc/ghc/commits/wip/pattern-synonyms https://github.com/ghc/haddock/commits/wip/pattern-synonyms https://github.com/ghc/testsuite/commits/wip/pattern-synonyms
So what's the intended workflow for me from now on? Will master be regularly merged into this branch? Should I base my future work (like fixing the outstanding issues your mail detailed) on top of this branch and continue pushing to my github repo?
Oh and also, how do I reword the commit message of the single squashed commit? I'm asking because there are some small fixes I'd like to do on the message.
Thanks, Gergo
You can do an interactive rebase and stop at the commit you want to change. Then use git commit --ammend to change the message. You probably don't want to be changing history too much though, it's a pain for anyone working on the same branch. On a somewhat related note, you should probably update your Haddock changes on top of the current master. Let me know if you have problems merging it on top. -- Mateusz K.

On Mon, 13 Jan 2014, Mateusz Kowalczyk wrote:
Oh and also, how do I reword the commit message of the single squashed commit? I'm asking because there are some small fixes I'd like to do on the message.
Thanks, Gergo
You can do an interactive rebase and stop at the commit you want to change. Then use git commit --ammend to change the message. You probably don't want to be changing history too much though, it's a pain for anyone working on the same branch.
I am well aware of the technical tools Git provides for history rewriting. My workflow before the pattern synonyms got on a wip branch was that I was rewriting history all the time, and people basically had a read-only view via a public GitHub repo that I force-pushed to. But now that it is happening on GHC repos that I have no push permissions to, I don't know if someone will for example be willing to force-push any rebased stuff I might end up with. Who do I even contact to pull onto these wip branches anyway? Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Friends help you move; Real friends help you move bodies.

From what I understood, you *should* have all permissions to push to wip/ branches. If not, please contact the admins. (IIRC Austin did this previously).
Cheers,
Gabor
On 1/13/14, Dr. ERDI Gergo
On Mon, 13 Jan 2014, Mateusz Kowalczyk wrote:
Oh and also, how do I reword the commit message of the single squashed commit? I'm asking because there are some small fixes I'd like to do on the message.
Thanks, Gergo
You can do an interactive rebase and stop at the commit you want to change. Then use git commit --ammend to change the message. You probably don't want to be changing history too much though, it's a pain for anyone working on the same branch.
I am well aware of the technical tools Git provides for history rewriting. My workflow before the pattern synonyms got on a wip branch was that I was rewriting history all the time, and people basically had a read-only view via a public GitHub repo that I force-pushed to. But now that it is happening on GHC repos that I have no push permissions to, I don't know if someone will for example be willing to force-push any rebased stuff I might end up with. Who do I even contact to pull onto these wip branches anyway?
Bye, Gergo
--
.--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Friends help you move; Real friends help you move bodies. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On Mon, 13 Jan 2014, Mateusz Kowalczyk wrote:
On a somewhat related note, you should probably update your Haddock changes on top of the current master. Let me know if you have problems merging it on top.
Hi Mateusz, Thanks for the offer, but it seems my patches re-apply on top of Haddock's latest master with no issues at all. Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Ébrenlét: unalmas időszak két szunya között

On Thu, 9 Jan 2014, Austin Seipp wrote:
1) As Richard pointed out, the docs are under docs/users_guide, as well as the release notes. Please feel free to elaborate however you want on the feature and the bulletpoint for the release notes.
Hope to get around to these in the weekend.
2) The failures are indeed a result of your code, in particular:
driver T4437 [bad stdout] (normal) generics GenDerivOutput [stderr mismatch] (normal) generics GenDerivOutput1_0 [stderr mismatch] (normal) generics GenDerivOutput1_1 [stderr mismatch] (normal) rename/should_compile T7336 [stderr mismatch] (normal)
Fixed these.
3) It seems GHCi does not support declaring pattern synonyms at the REPL. I'm not sure if it's intentional, but if it goes in like this, please be sure to document it in the release notes. We can file a ticket later for supporting pattern synonyms at the REPL.
It's definitely not intentional and I have no idea why it would be so. Isn't GHCi a fairly thin wrapper around the GHC internals? Is there any wiki page detailing the differences in GHCi vs GHC code paths? Thanks, Gergo

Check out TcRnDriver.tcRnDeclsi. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 13 January 2014 12:49 | To: Austin Seipp | Cc: Joachim Breitner; GHC Devs | Subject: Re: Pattern synonyms for 7.8? | | On Thu, 9 Jan 2014, Austin Seipp wrote: | | > 1) As Richard pointed out, the docs are under docs/users_guide, as | > well as the release notes. Please feel free to elaborate however you | > want on the feature and the bulletpoint for the release notes. | | Hope to get around to these in the weekend. | | > 2) The failures are indeed a result of your code, in particular: | > | > driver T4437 [bad stdout] (normal) | > generics GenDerivOutput [stderr mismatch] (normal) | > generics GenDerivOutput1_0 [stderr mismatch] (normal) | > generics GenDerivOutput1_1 [stderr mismatch] (normal) | > rename/should_compile T7336 [stderr mismatch] (normal) | | Fixed these. | | > 3) It seems GHCi does not support declaring pattern synonyms at the | > REPL. I'm not sure if it's intentional, but if it goes in like this, | > please be sure to document it in the release notes. We can file a | > ticket later for supporting pattern synonyms at the REPL. | | It's definitely not intentional and I have no idea why it would be so. | Isn't GHCi a fairly thin wrapper around the GHC internals? Is there any | wiki page detailing the differences in GHCi vs GHC code paths? | | Thanks, | Gergo | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

Hi, I've now pushed a re-based version to wip/pattern-synonyms that 1. contains a users_guide entry for -XPatternSynonyms (mostly modelled on the -XViewPatterns docs and the existing Wiki pages for PatternSynonyms) 2. fixes all test failures except for the following two which also occur on master: perf/should_run T5237 [stat not good enough] (normal) th T8633 [bad exit code] (normal) 3. adds a note to the users_guide that pattern synonym declarations don't work in GHCi. Could a native English speaker please read through the documentation changes on wip/pattern-synonyms? Also, I guess this is my official submission of the wip/pattern-synonyms branch for merge into master. Thanks, Gergo On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote:
On Thu, 9 Jan 2014, Austin Seipp wrote:
1) As Richard pointed out, the docs are under docs/users_guide, as well as the release notes. Please feel free to elaborate however you want on the feature and the bulletpoint for the release notes.
Hope to get around to these in the weekend.
2) The failures are indeed a result of your code, in particular:
driver T4437 [bad stdout] (normal) generics GenDerivOutput [stderr mismatch] (normal) generics GenDerivOutput1_0 [stderr mismatch] (normal) generics GenDerivOutput1_1 [stderr mismatch] (normal) rename/should_compile T7336 [stderr mismatch] (normal)
Fixed these.
3) It seems GHCi does not support declaring pattern synonyms at the REPL. I'm not sure if it's intentional, but if it goes in like this, please be sure to document it in the release notes. We can file a ticket later for supporting pattern synonyms at the REPL.
It's definitely not intentional and I have no idea why it would be so. Isn't GHCi a fairly thin wrapper around the GHC internals? Is there any wiki page detailing the differences in GHCi vs GHC code paths?
Thanks, Gergo
-- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' Két pont között a legrövidebb út építés alatt áll.

Austin, I'm away now, so I think you can go ahead and merge. (I guess the two failures below need attention though.) Thanks Gergo Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 18 January 2014 13:37 | To: Austin Seipp | Cc: Joachim Breitner; GHC Devs | Subject: Re: Pattern synonyms for 7.8? | | Hi, | | I've now pushed a re-based version to wip/pattern-synonyms that | | 1. contains a users_guide entry for -XPatternSynonyms (mostly modelled | on | the -XViewPatterns docs and the existing Wiki pages for | PatternSynonyms) | | 2. fixes all test failures except for the following two which also | occur | on master: | | perf/should_run T5237 [stat not good enough] (normal) | th T8633 [bad exit code] (normal) | | 3. adds a note to the users_guide that pattern synonym declarations | don't | work in GHCi. | | Could a native English speaker please read through the documentation | changes on wip/pattern-synonyms? | | Also, I guess this is my official submission of the wip/pattern- | synonyms | branch for merge into master. | | Thanks, | Gergo | | | On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote: | | > On Thu, 9 Jan 2014, Austin Seipp wrote: | > | >> 1) As Richard pointed out, the docs are under docs/users_guide, as | >> well as the release notes. Please feel free to elaborate however you | >> want on the feature and the bulletpoint for the release notes. | > | > Hope to get around to these in the weekend. | > | >> 2) The failures are indeed a result of your code, in particular: | >> | >> driver T4437 [bad stdout] (normal) | >> generics GenDerivOutput [stderr mismatch] (normal) | >> generics GenDerivOutput1_0 [stderr mismatch] | (normal) | >> generics GenDerivOutput1_1 [stderr mismatch] | (normal) | >> rename/should_compile T7336 [stderr mismatch] (normal) | > | > Fixed these. | > | >> 3) It seems GHCi does not support declaring pattern synonyms at the | >> REPL. I'm not sure if it's intentional, but if it goes in like this, | >> please be sure to document it in the release notes. We can file a | >> ticket later for supporting pattern synonyms at the REPL. | > | > It's definitely not intentional and I have no idea why it would be | so. Isn't | > GHCi a fairly thin wrapper around the GHC internals? Is there any | wiki page | > detailing the differences in GHCi vs GHC code paths? | > | > Thanks, | > Gergo | > | | -- | | .--= ULLA! =-----------------. | \ http://gergo.erdi.hu \ | `---= gergo@erdi.hu =-------' | Két pont között a legrövidebb út építés alatt áll.

Hi Gergo,
Thanks a bunch. I have a ./validate tree running which is almost done,
so I will merge it shortly!
On Sun, Jan 19, 2014 at 3:12 PM, Simon Peyton Jones
Austin, I'm away now, so I think you can go ahead and merge. (I guess the two failures below need attention though.)
Thanks Gergo
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 18 January 2014 13:37 | To: Austin Seipp | Cc: Joachim Breitner; GHC Devs | Subject: Re: Pattern synonyms for 7.8? | | Hi, | | I've now pushed a re-based version to wip/pattern-synonyms that | | 1. contains a users_guide entry for -XPatternSynonyms (mostly modelled | on | the -XViewPatterns docs and the existing Wiki pages for | PatternSynonyms) | | 2. fixes all test failures except for the following two which also | occur | on master: | | perf/should_run T5237 [stat not good enough] (normal) | th T8633 [bad exit code] (normal) | | 3. adds a note to the users_guide that pattern synonym declarations | don't | work in GHCi. | | Could a native English speaker please read through the documentation | changes on wip/pattern-synonyms? | | Also, I guess this is my official submission of the wip/pattern- | synonyms | branch for merge into master. | | Thanks, | Gergo | | | On Mon, 13 Jan 2014, Dr. ERDI Gergo wrote: | | > On Thu, 9 Jan 2014, Austin Seipp wrote: | > | >> 1) As Richard pointed out, the docs are under docs/users_guide, as | >> well as the release notes. Please feel free to elaborate however you | >> want on the feature and the bulletpoint for the release notes. | > | > Hope to get around to these in the weekend. | > | >> 2) The failures are indeed a result of your code, in particular: | >> | >> driver T4437 [bad stdout] (normal) | >> generics GenDerivOutput [stderr mismatch] (normal) | >> generics GenDerivOutput1_0 [stderr mismatch] | (normal) | >> generics GenDerivOutput1_1 [stderr mismatch] | (normal) | >> rename/should_compile T7336 [stderr mismatch] (normal) | > | > Fixed these. | > | >> 3) It seems GHCi does not support declaring pattern synonyms at the | >> REPL. I'm not sure if it's intentional, but if it goes in like this, | >> please be sure to document it in the release notes. We can file a | >> ticket later for supporting pattern synonyms at the REPL. | > | > It's definitely not intentional and I have no idea why it would be | so. Isn't | > GHCi a fairly thin wrapper around the GHC internals? Is there any | wiki page | > detailing the differences in GHCi vs GHC code paths? | > | > Thanks, | > Gergo | > | | -- | | .--= ULLA! =-----------------. | \ http://gergo.erdi.hu \ | `---= gergo@erdi.hu =-------' | Két pont között a legrövidebb út építés alatt áll.
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On Thu, 9 Jan 2014, Austin Seipp wrote:
3) It seems GHCi does not support declaring pattern synonyms at the REPL. I'm not sure if it's intentional, but if it goes in like this, please be sure to document it in the release notes. We can file a ticket later for supporting pattern synonyms at the REPL.
In GHCi, it seems to fail in the parser. So I thought, well that makes sense, isn't the REPL in GHCi supposed to be something like the inside of a 'do' block? But I tried creating a datatype in GHCi and that worked.. so my point is, I am now aware that I am confused about GHCi's behaviour. Given the time constraints, for the initial release I unfortunately have to decide *not* to support the GHCi REPL. I'll put that in the docs when I write them. -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo@erdi.hu =-------' I had my car's alignment checked. It's chaotic evil!

I think that's fine. But yes, the REPL does support top-level declarations. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 15 January 2014 11:27 | To: Austin Seipp | Cc: Joachim Breitner; GHC Devs | Subject: Re: Pattern synonyms for 7.8? | | On Thu, 9 Jan 2014, Austin Seipp wrote: | | > 3) It seems GHCi does not support declaring pattern synonyms at the | > REPL. I'm not sure if it's intentional, but if it goes in like this, | > please be sure to document it in the release notes. We can file a | > ticket later for supporting pattern synonyms at the REPL. | | In GHCi, it seems to fail in the parser. So I thought, well that makes | sense, isn't the REPL in GHCi supposed to be something like the inside | of a 'do' block? But I tried creating a datatype in GHCi and that | worked.. so my point is, I am now aware that I am confused about GHCi's | behaviour. | Given the time constraints, for the initial release I unfortunately have | to decide *not* to support the GHCi REPL. I'll put that in the docs when | I write them. | | -- | | .--= ULLA! =-----------------. | \ http://gergo.erdi.hu \ | `---= gergo@erdi.hu =-------' | I had my car's alignment checked. It's chaotic evil! | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
participants (8)
-
Austin Seipp
-
Dr. ERDI Gergo
-
Dr. ÉRDI Gergő
-
Gabor Greif
-
José Pedro Magalhães
-
Mateusz Kowalczyk
-
Richard Eisenberg
-
Simon Peyton Jones