Thanks Rog, yes that seems to be very similar to what I was converging on - I see you're combining the dictionaries per-implied-type (as I suggested above) into a single dictionary per generic function with one set of funcs for each instantiation. Makes sense.
I've skimmed over your code but maybe you could explain something that I was pondering over the weekend: since the draft specifies that type parameters in types (e.g. a struct) will not be boxed how do you handle the differing offsets of members for any generic functions using them? (generating stub accessors or something?) Cheers, Jamie On Saturday, November 3, 2018 at 11:45:59 AM UTC, rog wrote: > > Ah, I should mention it relies on a slightly modified version of the > compiler that allow conversion of function values to and from > unsafe.Pointer. It can be done without that, but not without extra heap > allocations AFAIK, and part of the point of this exercise was to measure > runtime overheads. > > On Sat, 3 Nov 2018, 11:21 am roger peppe <rogp...@gmail.com <javascript:> > wrote: > >> 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 <jnc...@gmail.com >> <javascript:>> 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...@googlegroups.com <javascript:>. >>> 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.
