| My proposal: | | > pattern P :: (Num a) => (Eq a, Ord Bool, Show c) => c -> Bool -> T a | > Bool | | My previous comment about bizarre scoping is that the universal | variables -- which (in my opinion) go with the required constraints -- | scope over both sets of constraints. The existential variables go with | the provided constraints and scope over only the provided constraints. | So, Simon's ordering means that the scope of the second (lexically) | listed constraints have a *smaller* scope than the first listed | constraints. With my ordering, the size of the scope increases as you | read to the right, as it normally does.
I _think_ you mean that you _could_ write P's type like this: | > pattern P :: forall a. (Num a) => forall c. (Eq a, Ord Bool, Show c) => c -> Bool -> T a I'm not sure we really would give it that nested structure, but it would be reasonable to do so. Richard's point is that the match-required constraints can *only* mention the universally quantified type variables. So yes, I think Richard is probably right. Incidentally ote that pattern P x = (3,x) would have type pattern P :: Num a => () => b -> (a,b) But since the "match-provided but no match-required" case must look simple, the "match-required but no match-provided" case is bound to look odd. OK, Gergo, I think you are good to go now. Simon | On Nov 10, 2014, at 4:07 PM, Simon Peyton Jones | <simo...@microsoft.com> wrote: | | > | Whatever syntax we choose, I would highly recommend putting in a | > | helpful link to more information in error messages. | > | > In principle I like this very much, but I have always stumbled on | > - writing links that will remain stable for ever (and are hence | > release-specific) | > - keeping them up to date when the version changes | > - making them easy to test e.g. in my build tree | > | > Separate question really, but would need some systematic attention | to make it work properly in general. | | Is there a way of pulling the version from DynFlags? If so, it would | be easy to include the version number in an SDoc. Then, we could make | the link go to the user manual. It would be easy to write a function | `userManualLink :: String -> SDoc` that takes the last bit of the link | and produces a link to the manual for the version at hand. (It | wouldn't work for non-released versions, but I'm OK with that.) | | Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs