In case it's of interest, I've been playing around with an experiment about how Go generic code might be generated. In particular I wanted to see how it looked when code was shared between generic instances with types that share the same memory layout (with respect to internal pointers and alignment). I haven't written any of the front-end generation code, but I hand-generated this code trying to keep the correspondence with the original generic code as close as possible.
A working implementation of graph example from the draft proposal is here: https://github.com/rogpeppe/genericdemo/tree/master/graph The "source" code is in the *-generic.go files (guarded with a "+build ignore" qualifier), and the "generated" code is in the *-generated.go files. The basic idea is that every generic function and method gets a stub function which calls the underlying code, adding a pointer to an "instance" value which provides all the generic entry points needed by the function. Since we can't write Go identifiers like "ShortestPath(*Node, *Edge)", it uses numeric identifiers to identify type parameter tuples (e.g. ShortestPath__10). The typeids.go file holds the crib for the identifiers ( https://github.com/rogpeppe/genericdemo/blob/master/graph/typeids.go). It actually seems to work. :) On Thu, 1 Nov 2018 at 20:04, Jamie Clarkson <jnc7...@gmail.com> wrote: > > > 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. > -- 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.
