[m-rev.] for post-commit review: clarify some parts of the reference manual

Zoltan Somogyi zoltan.somogyi at runbox.com
Fri Feb 9 20:03:04 AEDT 2024


On 2024-02-07 23:38 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
> 
> On Wed, 7 Feb 2024, Zoltan Somogyi wrote:
> 
>> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
>> index 0aa356ce5..5f2edc148 100644
>> --- a/doc/reference_manual.texi
>> +++ b/doc/reference_manual.texi
>> @@ -7223,12 +7223,16 @@ The @code{typeclass} declaration
>>  gives the name of the type class that it is defining,
>>  the names of the type variables which are parameters to the type class,
>>  and the operations (i.e.@: methods) which form the interface of the type class.
>> -For each method, all parameters of the typeclass must be determined by
>> -the type variables appearing in the type signature of the method.
>> -A variable is determined by a type signature
>> -if it appears in the type signature,
>> -but if functional dependencies are present,
>> -then it may also be determined from the other variables
>> +For each method, all parameters of the typeclass must be determined
>> +by the type declaration of the method.
>> +The values of @emph{most} parameter type variables
>> +are determined by having them occur
>> +in the declared type of an argument of the method.
>> +However, in the presence of functional dependencies,
>> + at c where exactly? The possibilities are the typeclass declaration and
>> + at c the method itself; are both allowed?
> 
> Functional dependencies can only occur on typeclass declarations. They are not
> allowed on methods. Any FDs that are used to determine type parameters need to
> be from the typeclass declaration or inherited from any superclasses.

I am committing this diff:

--- a/doc/reference_manual.texi
+++ b/doc/reference_manual.texi
@@ -7228,11 +7228,9 @@ by the type declaration of the method.
 The values of @emph{most} parameter type variables
 are determined by having them occur
 in the declared type of an argument of the method.
-However, in the presence of functional dependencies,
- at c where exactly? The possibilities are the typeclass declaration and
- at c the method itself; are both allowed?
-then the value of a variable
-may also be implied by the values of other variables
+However, if either the typeclass named in the constraint, or its superclasses,
+include any functional dependencies, then
+the value of a variable may also be implied by the values of other variables
 (@pxref{Functional dependencies}).

For your post-commit review.

> The reference manual doesn't mention if other (i.e non-FD) typeclass
> constraints are allowed on individual methods (i.e. what Haskell, or at least
> GHC, calls constrained class methods), although doing so appears to work. (If
> this support is intentional we should probably mention it somewhere in the
> reference manual.)

Given the mess of the code that parses constraints, I think "accidental"
is more likely than "intentional".

Zoltan.


More information about the reviews mailing list