Here's a version that runs in the playground. https://play.golang.org/p/DciTAl8dAxO
On Sat, 3 Nov 2018 at 11:45, roger peppe <rogpe...@gmail.com> 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 <rogpe...@gmail.com 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 <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.
