I agree with Chris here. Let me expand upon my counter-proposal:
* A datatype declaration gets a standalone kind signature whenever at least one of its type arguments has a kind other than Type. * A class declaration gets a standalone kind signature whenever at least one of its type arguments has a kind other than Type.(*) * A closed type family always gets a standalone kind signature. * A type synonym gets a standalone kind signature whenever either at least one of its arguments has a kind other than Type or its result has a kind other than Type. (*) The class rule has an exception: if a class has a superclass constraint using Monad, Functor, Applicative, Foldable, or Traversable (or some other class whose name textually includes one of those names, such as MonadIO), we understand that the constrained variable must have kind Type -> Type. If that type variable is the only one without kind Type -> Type, then the standalone kind signature is optional. In cases other than those covered above, the standalone kind signature is optional, at the discretion of the programmer. This suggests that Dict gets a signature, Eq does not, Fix does, and Either does not. Richard > On May 21, 2021, at 12:37 PM, Chris Smith <cdsm...@gmail.com> wrote: > > On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal <baldur...@gmail.com > <mailto:baldur...@gmail.com>> wrote: > > encouraging the use of a standalone signature for type declarations where > > at least one parameter of the datatype does not have kind Type. > > So Dict, Eq both get a sig but Fix and Either do not? > > type Dict :: Constraint -> Type > type Eq :: Type -> Constraint > type Fix :: (Type -> Type) -> Type > > That's not how I understand Richard's criteria. Dict and Fix have non-Type > parameters (Dict has a Constraint parameter, and Fix has a (Type -> Type) > parameter. On the other hand, Eq and Either have only Types as parameters. > This seems to match my intuition about when a kind signature might be > helpful, as well as yours as far as I can tell from what you wrote. > > That's not to say I am advocating any kind of rule. As I'm not really > involved in GHC development, I refrain from having any opinion. I just think > you may have misread Richard's suggestion.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
