dmacqueen
commented
4 years ago I agree. Parameterized signatures (signature functors) are an obvious extension that presents no obvious problems.
Dave
On Jul 10, 2019, at 1:12 AM, Pauli Jaakkola notifications@github.com wrote:
As previously discussed https://github.com/SMLFamily/Successor-ML/issues/8#issuecomment-207718055, parameterized signatures would cut down on typical where type boilerplate. Given that we already have type constructors and functors it would actually be less surprising to users that signatures could also be parameterized.
Signature members https://github.com/SMLFamily/Successor-ML/issues/39 would take us most of the way (e.g. functor MkSig (M: sig type t end) :> sig signature S = sig type t = M.t end end = ... and signature SIG = MkSig(type t = int).S but such encodings are still annoying.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SMLFamily/Successor-ML/issues/40?email_source=notifications&email_token=AAGXNPIMZSFQQBFO632CYBTP6WKWNA5CNFSM4H7MVO62YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G6JDYCA, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGXNPODKUIYRL7HM7IQINDP6WKWNANCNFSM4H7MVO6Q.
David MacQueen dmacqueen@mac.com
As previously discussed, parameterized signatures would cut down on typical
where typeboilerplate. Given that we already have type constructors and functors it would actually be less surprising to users that signatures could also be parameterized.Signature members would take us most of the way (e.g.
functor MkSig (M: sig type t end) :> sig signature S = sig type t = M.t end end = ...andsignature SIG = MkSig(type t = int).Sbut such encodings are still annoying.