<div dir="auto"><br></div><div dir="auto"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)">On 2018-05-16 04:24:15 UTC 2018, Bardur Arantsson wrote:</pre></div><div dir="auto">> <span style="white-space:pre-wrap;background-color:rgb(255,255,255)">An interesting post, but I don't see any mention of laws. This seems </span><span style="white-space:pre-wrap;background-color:rgb(255,255,255)">like it could be an... issue.</span></div><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)"><div dir="auto">>
> (Not that we specify laws in the code anyway right now, but at least there's some idea of a "thing" we can attach the laws to and where we can document them.)</div></pre><div dir="auto"><br></div><div dir="auto">Thanks Bardur, I don't see an issue. Currently the laws are specified in terms of equivalences between method calls, not in terms of classes. Furthermore the laws might involve methods from many different classes. So we can attach the laws to the methods.</div><div dir="auto"><br></div><div dir="auto">For example, the Monad laws mention not only `return` and (>>=) but also `fmap`, `pure`, (*>), etc. Note that the classes in the Prelude are all single parameter, in compliance with H98; so it's unambiguous which type instantiation the laws are talking about.</div><div dir="auto"><br></div><div dir="auto">That can all be handled I think through the 'supermethod methods' I talked about (which play the role of superclass constraints). For example in making the Num class redundant, we require (+) to be a supermethod of (*); and (*) to be a supermethod of (/). </div><div><br></div><div dir="auto"><br></div><div dir="auto">AntC</div>