On Thursday, November 1, 2018 at 6:19:58 PM UTC, Mandolyte wrote: > > Ah, I see. the albrow/fo package is the equivalent of just pasting the > entire function into the contract. > > Could you expand on this a little, I'm not sure I follow? Would it handle the Graph contract?
I agree, I had mixed feelings about contracts too at first. But I came to > appreciate, in descending order: > > - It would be good documentation in godoc > - It enables much better error messages (a problem with albrow/fo and > is also stated in the proposal) > - Robust enough to handle the "edge" cases (pun intended) > > I have seen some proposals that look interesting on operator overloading, > but I could live without them. There are other ways to handle the cases > where they would be nice to have. A good godoc goes a long way! > > I'm still not totally convinced by the contracts in the draft but I think with some tweaks they could be good. I agree on the operators, I really really don't want overloading which can be abused and happily live without them but I reckon there will end up with some form of restricted overloads. > Cheers. > > On Thursday, November 1, 2018 at 10:04:08 AM UTC-4, Jamie Clarkson wrote: >> >> Thanks, that looks like a cool project - however I'd disagree that not >> using contracts is relevant to the question. >> >> My interest was mainly in what would need to be implicitly generated by >> the compiler in order to support contracts (such as the mutual recursive >> types above), not specifically the generated code. In fact it would be >> cool to see if the contract mechanism could be implemented on top of Fo >> since that already provides the parametrics. >> >> The generated code is relevant too of course but it's fairly mechanically >> obvious (ignoring tedious details :) ) how to translate basic parametric >> polymorphism or basic adhoc. In the dictionaries approach above this seems >> similar to how Haskell implements typeclasses but for implicitly satisfied >> constraints (from the contract). >> >> Initially I didn't like the contracts proposal but the more I think of it >> in the way of implicitly generating types (and esp. typeclass-like >> constructs) the more I like it and the more it feels like Go where >> interfaces are implicitly satisfied. >> >> Cheers, >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
