Re: [go-nuts] Code generated by generics draft

On Mon, 5 Nov 2018 at 14:36, Jamie Clarkson wrote: > > Yes that does help, looks like a really good solution. In your opinion > would the resulting code be worthwhile (including all the dictionaries, > stubs etc.) when compared to the C++ code expansion method? I can see that > it would save

Re: [go-nuts] Code generated by generics draft

Yes that does help, looks like a really good solution. In your opinion would the resulting code be worthwhile (including all the dictionaries, stubs etc.) when compared to the C++ code expansion method? I can see that it would save for the basic types and types derived from them but once you

Re: [go-nuts] Code generated by generics draft

On Mon, 5 Nov 2018 at 13:19, Jamie Clarkson wrote: > I was more thinking about your Graph example which you posted where you're > using an item(type Node,Edge) struct {}, not accessing the members of the > Node and Edge types (which I agree is a dubious corner case) - looking at > it again

Re: [go-nuts] Code generated by generics draft

I was more thinking about your Graph example which you posted where you're using an item(type Node,Edge) struct {}, not accessing the members of the Node and Edge types (which I agree is a dubious corner case) - looking at it again though it looks like you're boxing with interface{} in the

Re: [go-nuts] Code generated by generics draft

On Mon, 5 Nov 2018 at 11:38, Jamie Clarkson wrote: > 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

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

On Sat, Nov 3, 2018 at 2:12 PM Wojciech S. Czarnecki wrote: > > > Future: I'll consider Burak Sedar's **like Type** within CGG contract. fyi: I got some useful feedback on this, especially from Scott Cotton, and I am working on some sort of formal framework (using go 1) where I can test if this

Re: [go-nuts] Code generated by generics draft

On Sat, 3 Nov 2018 11:21:30 + roger peppe wrote: > In case it's of interest, I've been playing around with an experiment about > how Go generic code might be generated. I've been playing around in the CGG proposal context, too. Unfortunately my spare time shrunk recently. You did more so I

Re: [go-nuts] Code generated by generics draft

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 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

Re: [go-nuts] Code generated by generics draft

>Ah, I see. the albrow/fo package is the equivalent of just pasting the >entire function into the contract. It's not actually -- the rules seem to be those of the draft design, with the contracts mechanism simply omitted. So e.g. there's no way to write a max function; see:

Re: [go-nuts] Code generated by generics draft

Sorry for the ambiguity. As I understand it, the "fo" compiler simply rewrites the generic function/method using the supplied type parameters and then tries to compile it. It would be an interesting exercise to try the Graph example, but as it is, I'm not certain how it would handle it, or if

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

It looks like it will treat it as generic type definition only if T is not defined elsewhere: https://play.folang.org/p/lN2b6QfgH38 * Commenting out const Size = ... -- results in an error about a missing type parameter * Deleting the Size constant and declaring a function named Size --

Re: [go-nuts] Code generated by generics draft

Ah, I see. the albrow/fo package is the equivalent of just pasting the entire function into the 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

Re: [go-nuts] Code generated by generics draft

I didn't encounter this when I experimented with the package (here ). So not sure. However, as an array, T cannot be a variable, it must be a constant... so perhaps it can be figured out - see https://play.golang.org/ On Thursday, November 1, 2018 at 11:54:31 AM

Re: [go-nuts] Code generated by generics draft

Quoting Mandolyte (2018-11-01 06:30:30) > - it uses square brackets instead of (type .. ) for the type parameters What does it do with `type Foo [T] int`? The draft design cites this ambiguity (is it a generic type with an unused parameter, or an array of length T?) as the reason for not using

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

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()

Re: [go-nuts] Code generated by generics draft

On Tue, Oct 30, 2018 at 8:39 AM, 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

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

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,

Re: [go-nuts] Code generated by generics draft

On Tue, Oct 30, 2018 at 8:15 AM, Jamie Clarkson 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

Re: [go-nuts] Code generated by generics draft

Thanks Ian, I appreciate none of this has been implemented, just trying to understand the design space (including what the generated code will look like and how to get from the input contract definition & generic to the output code :) ). Also I realize that the compiler is free to do all

Re: [go-nuts] Code generated by generics draft

On Tue, Oct 30, 2018 at 6:13 AM, Jamie Clarkson wrote: > > Apologies if this is covered somewhere, have searched and not found. > > I'm curious about the Go2 generics draft, how does the team envisage the > code generated for the ShortestPath (without code expansion like C++ > templates where

[go-nuts] Code generated by generics draft

Hi gophers, Apologies if this is covered somewhere, have searched and not found. I'm curious about the Go2 generics draft, how does the team envisage the code generated for the ShortestPath (without code expansion like C++ templates where it's obvious)? I can come up with two so far. i)