Pattern synonyms for 7.8?

Austin Seipp austin at well-typed.com
Thu Jan 9 08:48:55 UTC 2014 

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 <eir at cis.upenn.edu> wrote:
> 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ő <gergo at erdi.hu> 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" <aseipp at pobox.com> 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/afefa7ac948b1d7801d622824fbdd75ade2ada3f,
>> 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 <gergo at erdi.hu> 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 at erdi.hu =-------'
>> > Elvis is dead and I don't feel so good either.
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
>> >
>>
>>
>>
>> --
>> Regards,
>> Austin - PGP: 4096R/0x91384671
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

More information about the ghc-devs mailing list