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.
