Ah, I see. the albrow/fo package is the equivalent of just pasting the entire function into the 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! 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, > > Jamie > > On Thursday, November 1, 2018 at 10:30:30 AM UTC, Mandolyte wrote: >> >> You can use https://github.com/albrow/fo and see what code it generates. >> Conceptually, I imagine will it be close to what the draft spec would >> produce. Some differences and limitations: >> - it uses square brackets instead of (type .. ) for the type parameters >> - it is limited to a single main() package >> - doesn't use contracts (but not relevant for your question since >> contracts are for compile time) >> >> On Tuesday, October 30, 2018 at 12:14:42 PM UTC-4, Jamie Clarkson wrote: >>> >>> Replying to myself but I've got a different method with a dictionary per >>> type instead of the interface per value: >>> >>> iv) Dictionary based: https://play.golang.org/p/t6GBTEgq_g6 >>> >>> (that one based on reflect but could use the slice interfaces or similar) >>> >>> On Tuesday, October 30, 2018 at 3:39:09 PM UTC, Jamie Clarkson wrote: >>>> >>>> Ah ok, sorry I don't want to waste your time getting into the >>>> nitty-gritty of a hypothetical situation but are you meaning the >>>> code for (say): >>>> >>>> func (u *_UserEdge) Nodes() _SliceN { >>>> nodes := u.UserEdge.Nodes() // type []UserNode >>>> return _SliceUserNode(nodes) >>>> } >>>> >>>> ? >>>> >>>> On Tuesday, October 30, 2018 at 3:19:42 PM UTC, Ian Lance Taylor wrote: >>>>> >>>>> On Tue, Oct 30, 2018 at 8:15 AM, Jamie Clarkson <jnc...@gmail.com> >>>>> wrote: >>>>> > >>>>> > I'm not sure what you meant by conversion of non-interface to >>>>> interface >>>>> > types to handle results? I can see the usual conversions working >>>>> fine at >>>>> > the call site for input parameters but the actual ShortestPath func >>>>> seems to >>>>> > need to use interface throughout? >>>>> >>>>> I mean in converting the slice returned by Edge.Nodes to the >>>>> implicitly generated slice interface type. >>>>> >>>>> Ian >>>>> >>>> -- 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.
