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. > > I've not looked too closely but not sure I follow this? Is it able to handle the Graph example constraint with the mutual Node and Edge types?
> 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.
