Re: [go-nuts] Regarding contracts

After giving this some more thought, i’ve changed my syntax for complex relationships between types. Now it looks like this: contract Node { Edges() []Edge } contract Edge { Nodes() (from, to Node) } func ShortestPath(type N Node, E Edge)(src, dst N) []E Andy > On Oct 25, 2018,

Re: [go-nuts] Regarding contracts

On Thu, Oct 25, 2018 at 10:32 AM Andy Balholm wrote: > > > > On Oct 25, 2018, at 6:45 AM, Marvin Renich wrote: > > The most powerful feature of the contracts described in the original > design draft is the ability to describe interactions between two types > in a type specification. Your proposa

Re: [go-nuts] Regarding contracts

> On Oct 25, 2018, at 6:45 AM, Marvin Renich wrote: > > The most powerful feature of the contracts described in the original > design draft is the ability to describe interactions between two types > in a type specification. Your proposal doesn't seem to allow this. See the section of my gist

Re: [go-nuts] Regarding contracts

* Andy Balholm [181024 17:52]: > What I’m doing with structural contracts is basically the same as what > you’re doing with struct and interface types as contracts, except that > (I hope) the syntax is a little clearer. > > I added the support for operators basically to avoid having the > suppor

Re: [go-nuts] Regarding contracts

On Wed, Oct 24, 2018 at 3:52 PM Andy Balholm wrote: > > What I’m doing with structural contracts is basically the same as what you’re > doing with struct and interface types as contracts, except that (I hope) the > syntax is a little clearer. > > I added the support for operators basically to av

Re: [go-nuts] Regarding contracts

What I’m doing with structural contracts is basically the same as what you’re doing with struct and interface types as contracts, except that (I hope) the syntax is a little clearer. I added the support for operators basically to avoid having the supportsEqual contract as a special case that n

Re: [go-nuts] Regarding contracts

On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm wrote: > > Here’s my attempt at streamlining it, as well as adding a way to deal with > the operator/method dichotomy: > https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2 Thanks! However, I think yours is a somewhat different ap

Re: [go-nuts] Regarding contracts

Here’s my attempt at streamlining it, as well as adding a way to deal with the operator/method dichotomy: https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2 Andy > On Oct 23, 2018, at 9:37 AM, Burak Serdar

Re: [go-nuts] Regarding contracts

Maybe it's worth adding to: https://github.com/golang/go/wiki/Go2GenericsFeedback On Tuesday, 23 October 2018 17:37:40 UTC+1, Burak Serdar wrote: > > I typed this up in a more organized way, and it turned out to be an > alternative declaration for contracts without touching the generics > parts

Re: [go-nuts] Regarding contracts

On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar wrote: > > On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich wrote: > > > > * Burak Serdar [181018 15:08]: > > > tbh, I am not trying to avoid operator overloading, I am trying to > > > avoid the contracts. With operator overloading, you can write: > > >

Re: [go-nuts] Regarding contracts

> Ian Denhardt : > > But I think fundamentally folks have to > > make choice: do we want to be able to write `<` for user defined types, or > > do > > we want to be able to look at the `<` operator and know for certain that > > it's > > not calling a method? You can't have both. You can have alm

Re: [go-nuts] Regarding contracts

On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich wrote: > > * Burak Serdar [181018 15:08]: > > tbh, I am not trying to avoid operator overloading, I am trying to > > avoid the contracts. With operator overloading, you can write: > > > > func F(a,b type T like(int,X)) { > >if a > ... > >

Re: [go-nuts] Regarding contracts

* Burak Serdar [181018 15:08]: > tbh, I am not trying to avoid operator overloading, I am trying to > avoid the contracts. With operator overloading, you can write: > > func F(a,b type T like(int,X)) { >if a ... >} > } > > provided X is a type that supports <. Are you trying to avo

Re: [go-nuts] Regarding contracts

On Sat, Oct 20, 2018 at 9:42 AM Ian Denhardt wrote: > > Quoting Burak Serdar (2018-10-19 17:01:42) > > On Fri, Oct 19, 2018 at 1:09 PM Ian Denhardt wrote: > > > > > > Quoting Burak Serdar (2018-10-19 14:09:46) > > > > > > > It is useful in a linked list. You can instantiate a linked list > > > >

Re: [go-nuts] Regarding contracts

Quoting robert engels (2018-10-20 12:15:52) >To be clear, this is only for that "performance case", where I don't >want LinkedList to allocate internal nodes to hold the elements but the >reasoning applies when using a simple LinkedList, and I want it to hold >MyObj (which is not a

Re: [go-nuts] Regarding contracts

Agreed, the following is where the disconnect is > On Oct 20, 2018, at 10:40 AM, Ian Denhardt wrote: > >> // Do we need LinkedList(T)? Maybe not.. >> func (l *LinkedList) Add(n *Node) { >> n.next=nil >> if l.head==nil { >>l.head=n >> } else { >>l.head.next=n >> } >> } if I declare a

Re: [go-nuts] Regarding contracts

Quoting Burak Serdar (2018-10-19 17:01:42) > On Fri, Oct 19, 2018 at 1:09 PM Ian Denhardt wrote: > > > > Quoting Burak Serdar (2018-10-19 14:09:46) > > > > > It is useful in a linked list. You can instantiate a linked list > > > template in a package, and use that concrete type in another package

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 1:09 PM Ian Denhardt wrote: > > Quoting Burak Serdar (2018-10-19 14:09:46) > > > It is useful in a linked list. You can instantiate a linked list > > template in a package, and use that concrete type in another package > > without access to the internals of the linked list.

Re: [go-nuts] Regarding contracts

Ian Denhardt : > Quoting Eric S. Raymond (2018-10-19 16:03:02) > > > Both classes want to be selected by a field "name". It's annoying that > > I can't declare an interface that says "has a field 'name'" and instead > > have to declare a getter function with no other point besides sliding > > arou

Re: [go-nuts] Regarding contracts

Quoting Ian Denhardt (2018-10-19 16:29:07) > > Quoting Burak Serdar (2018-10-19 15:13:20) > > Without operator overloading: > > Realized I missed this right after hitting send. Yes, without operator overloading you're restricted to built-in types that already support the operator. The original mot

Re: [go-nuts] Regarding contracts

Quoting Burak Serdar (2018-10-19 15:13:20) > Without operator overloading: > > type X interface { >implements < > } > > means that you want a primitive numeric type or a string. So: This is not quite quite correct; in Eric's proposal, it is possible to define (for example): ``` // A Version

Re: [go-nuts] Regarding contracts

Ian Lance Taylor : > > Both classes want to be selected by a field "name". It's annoying that > > I can't declare an interface that says "has a field 'name'" and instead > > have to declare a getter function with no other point besides sliding > > around that restriction. > > I think you are talki

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 1:03 PM, Eric S. Raymond wrote: > Burak Serdar : >> One other difference between the two is the ability of the "like" >> syntax to use a struct as well as an interface for templates, so you >> can require concrete implementations to have certain fields, instead >> of getter

Re: [go-nuts] Regarding contracts

Burak Serdar : > One other difference between the two is the ability of the "like" > syntax to use a struct as well as an interface for templates, so you > can require concrete implementations to have certain fields, instead > of getter/setters. I'm puzzled that this is not already possible in int

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 1:26 PM Eric S. Raymond wrote: > > Burak Serdar : > > So the question is: do we really need to declare exactly what the > > implementation of a generic needs in the contract, or is it sufficient > > to say "use this with values that are like type X"? > > I think the additio

Re: [go-nuts] Regarding contracts

Burak Serdar : > So the question is: do we really need to declare exactly what the > implementation of a generic needs in the contract, or is it sufficient > to say "use this with values that are like type X"? I think the additional explicitness of "implements" is valuable. And my syntax is light

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 11:48 AM Eric S. Raymond wrote: > > Burak Serdar : > > Where can I read about this "implements"? Link? > > https://groups.google.com/forum/#!topic/golang-nuts/pR5pmql5olM > > After subsequent discussion I would only add these points: > > * The "implements" construct is not

Re: [go-nuts] Regarding contracts

Quoting Burak Serdar (2018-10-19 14:09:46) > It is useful in a linked list. You can instantiate a linked list > template in a package, and use that concrete type in another package > without access to the internals of the linked list. Can you provide an example of what some code using this would

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 12:36 PM Ian Lance Taylor wrote: > > On Thu, Oct 18, 2018 at 10:48 AM, Burak Serdar wrote: > > On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor wrote: > >> > >> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote: > >> > > >> > Instead of specifying the minimal set of

Re: [go-nuts] Regarding contracts

I always assumed that there is no "private" in Go - it is either public or package level. So generic's being able to access same package level accessible things seems to be logical. Andrey On Thursday, October 18, 2018 at 10:21:15 AM UTC-6, Andy Balholm wrote: > > I don’t think that generic fun

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 10:48 AM, Burak Serdar wrote: > On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor wrote: >> >> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote: >> > >> > Instead of specifying the minimal set of operations a type should >> > satisfy, why not describe what the type sh

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 12:01 PM Ian Denhardt wrote: > > Quoting Burak Serdar (2018-10-19 12:34:44) > > Re: Ian Denhardt's proposal: > > > > I agree that it handles all the cases in the official proposal, > > but I think the syntax is too verbose and reminds me of > > Java. For instance, the "sort

Re: [go-nuts] Regarding contracts

Quoting Burak Serdar (2018-10-19 12:46:19) > Where can I read about this "implements"? Link? This is the thread: https://groups.google.com/forum/#!search/go-nuts/golang-nuts/pR5pmql5olM/RPDuL2BsCAAJ -- You received this message because you are subscribed to the Google Groups "golang-nuts" grou

Re: [go-nuts] Regarding contracts

Quoting Burak Serdar (2018-10-19 12:34:44) > Re: Ian Denhardt's proposal: > > I agree that it handles all the cases in the official proposal, > but I think the syntax is too verbose and reminds me of > Java. For instance, the "sorting" example can be written using > the "like" keyword as: > > Temp

Re: [go-nuts] Regarding contracts

Burak Serdar : > Where can I read about this "implements"? Link? https://groups.google.com/forum/#!topic/golang-nuts/pR5pmql5olM After subsequent discussion I would only add these points: * The "implements" construct is not a full generic-type system in itself, nor is it meant to be. It's meant

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 10:38 AM Eric S. Raymond wrote: > > Ian Denhardt : > > I feel like Burak's proposal is falling into the same trap as many others: > > there is a common feeling that operator overloading is a Pandora's box, so > > folks are trying to work around it by solving the problem wit

Re: [go-nuts] Regarding contracts

Ian Denhardt : > I feel like Burak's proposal is falling into the same trap as many others: > there is a common feeling that operator overloading is a Pandora's box, so > folks are trying to work around it by solving the problem without providing > operator overloading. But *the problem itself* is

Re: [go-nuts] Regarding contracts

On Fri, Oct 19, 2018 at 7:13 AM Robert Engels wrote: > > I don’t think it matters, since when writing the generic code using methods > the author has strict control over the precedence. > > Also, for equality testing, the signature would be bool Equals(interface{}) > with required casting. Witho

Re: [go-nuts] Regarding contracts

Andy Balholm : > I don’t think that generic functions should have access to private > fields of their type parameters, regardless of what package they are > in. Agreed. Turns me off this proposal somewhat. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the I

Re: [go-nuts] Regarding contracts

Beoran : > I think the idea we should focus on here is "The type is the contract". > Instead of specifying a contract though operations, just use concrete > types, including primitive types to specify the desired qualities of the > generic type. This is, of course, similar to my "implements" p

Re: [go-nuts] Regarding contracts

I don’t think it matters, since when writing the generic code using methods the author has strict control over the precedence. Also, for equality testing, the signature would be bool Equals(interface{}) with required casting. Without looking for flames, this is how Java does it and it’s never

Re: [go-nuts] Regarding contracts

On Thursday, 18 October 2018 21:51:35 UTC+2, robert engels wrote: > > I guess I don’t understand the problem with using “method names” e.g. > Less() in generic code - yes it is a little more verbose - but it avoids > the traditional problems with operator overloading leading to obtuse code. > >

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 2:02 PM Ian Denhardt wrote: > > Quoting robert engels (2018-10-18 15:22:36) > > Can you explain this a bit more, I must be missing something. Using the > > example: > > > > func F(a,b type T like(int,X)) { > > if a > ... > > } > > } > > > > How do you pass a struct

Re: [go-nuts] Regarding contracts

Quoting robert engels (2018-10-18 15:22:36) > Can you explain this a bit more, I must be missing something. Using the > example: > > func F(a,b type T like(int,X)) { > if a ... > } > } > > How do you pass a struct to F because < isn’t valid on structs ??? > > Which is why I proposed that <

Re: [go-nuts] Regarding contracts

Sorry, it is confusing… because then someone chimes in and says ‘no’ to operator overloading which would make that impossible, which makes the example impossible for arbitrary X. I guess I don’t understand the problem with using “method names” e.g. Less() in generic code - yes it is a little mo

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 1:22 PM robert engels wrote: > > Can you explain this a bit more, I must be missing something. Using the > example: > > func F(a,b type T like(int,X)) { > if a ... > } > } > > How do you pass a struct to F because < isn’t valid on structs ??? You missed the part t

Re: [go-nuts] Regarding contracts

Can you explain this a bit more, I must be missing something. Using the example: func F(a,b type T like(int,X)) { if a On Oct 18, 2018, at 2:13 PM, bjorn.de.me...@gmail.com wrote: > > I don't think this is fear, but rather KISS. The reason many people dislike > contracts from the official prop

Re: [go-nuts] Regarding contracts

I don't think this is fear, but rather KISS. The reason many people dislike contracts from the official proposal is that they are complex and don't have a very Go-like syntax. I like this like syntax because I feel it is more Go-like, but also because it solves the operator problem rather eleg

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 12:28 PM Ian Denhardt wrote: > > Quoting Andy Balholm (2018-10-18 14:00:52) > > > That would also be a weakness of most of the other proposals, > > including my own to add operators to interfaces. Contracts are more > > powerful, at the expense of extra complexity. > > Fwiw

Re: [go-nuts] Regarding contracts

Quoting Andy Balholm (2018-10-18 14:00:52) > That would also be a weakness of most of the other proposals, > including my own to add operators to interfaces. Contracts are more > powerful, at the expense of extra complexity. Fwiw, my own proposal for "just using interfaces" covered the graph use

Re: [go-nuts] Regarding contracts

That would also be a weakness of most of the other proposals, including my own to add operators to interfaces. Contracts are more powerful, at the expense of extra complexity. Andy > On Oct 18, 2018, at 10:34 AM, Ian Lance Taylor wrote: > > On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrot

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor wrote: > > On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote: > > > > Instead of specifying the minimal set of operations a type should > > satisfy, why not describe what the type should look like: > > > > func f(in like T) > > I don't see how

Re: [go-nuts] Regarding contracts

On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote: > > Instead of specifying the minimal set of operations a type should > satisfy, why not describe what the type should look like: > > func f(in like T) I don't see how this approach can handle multiple types that need to work together in some

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 10:13 AM robert engels wrote: > > I guess you could do it that way, but still, then you need to document every > private field as if it were public, leading to very brittle code… imagine the > compiler error - struct X does not have field xyz… ? Then I need to go to the

Re: [go-nuts] Regarding contracts

I don’t think that generic functions should have access to private fields of their type parameters, regardless of what package they are in. Andy -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

Re: [go-nuts] Regarding contracts

I guess you could do it that way, but still, then you need to document every private field as if it were public, leading to very brittle code… imagine the compiler error - struct X does not have field xyz… ? Then I need to go to the source of Y and look at how xyz is documented (hopefully), and

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 10:03 AM robert engels wrote: > > Right, that is a big limitation - that means that internal details must be > made public, or everything in the same package - which is even worse, because > then you have other private details accessible. Breaks encapsulation. That is no

Re: [go-nuts] Regarding contracts

Right, that is a big limitation - that means that internal details must be made public, or everything in the same package - which is even worse, because then you have other private details accessible. Breaks encapsulation. Field access just seems unworkable to me. To much to understand (and docu

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 9:37 AM robert engels wrote: > > That is true, it would be done that way, so not an issue. Sorry for the > tangent. > > I still don’t understand when ‘like T’ when T is a concrete type. It seems > daunting, unless you use the containment as outlined previously - but a X

Re: [go-nuts] Regarding contracts

That is true, it would be done that way, so not an issue. Sorry for the tangent. I still don’t understand when ‘like T’ when T is a concrete type. It seems daunting, unless you use the containment as outlined previously - but a X containing T, is far different than X being a T, and I am not sure

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 8:53 AM Robert Engels wrote: > > > > > On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote: > > > > If X is a struct type, any type implementing all the methods of X and > >containing all the fields of X can be substituted > > The above is the problem. This almost certainl

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 8:53 AM Robert Engels wrote: > > > > > On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote: > > > > If X is a struct type, any type implementing all the methods of X and > >containing all the fields of X can be substituted > > The above is the problem. This almost certainl

Re: [go-nuts] Regarding contracts

> On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote: > > If X is a struct type, any type implementing all the methods of X and >containing all the fields of X can be substituted The above is the problem. This almost certainly requires dynamic access to fields, essentially making all method

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 8:01 AM Robert Engels wrote: > > Try it with a user defined type. The only point of generic is to write a > method once. So when I call it with another type it works correctly. So if > you write the generic method with a like Foo but I want to call it with a Bar > what m

Re: [go-nuts] Regarding contracts

Try it with a user defined type. The only point of generic is to write a method once. So when I call it with another type it works correctly. So if you write the generic method with a like Foo but I want to call it with a Bar what methods does Bar need to implement ? All of the methods of Foo -

Re: [go-nuts] Regarding contracts

On Thu, Oct 18, 2018 at 6:35 AM Robert Engels wrote: > > I meant to say contract not interface. Also as a user of said generic routine > how do I know all of the available method on a type I would need to implement > as I don’t know which ones the method may be using... > > Interfaces solve the

Re: [go-nuts] Regarding contracts

How so? When you do foo := foo.Foo{} foo.Bar() The compiler also has to look up Bar() for the type Foo, nothing special or difficult about that. In Go, the places where the compiler has to look are quite limited, I think. Furthermore with the currently proposed contracts, much the same look

Re: [go-nuts] Regarding contracts

I meant to say contract not interface. Also as a user of said generic routine how do I know all of the available method on a type I would need to implement as I don’t know which ones the method may be using... Interfaces solve the latter as I need to implement all of them in order to be an inte

Re: [go-nuts] Regarding contracts

I think the problem with the proposal is that it is going to be very hard for the compiler to know all of the operations a type can perform since for concrete types the methods can be spread across multiple files. With an interface it is only declared in a single location. > On Oct 18, 2018, a

Re: [go-nuts] Regarding contracts

I think the idea we should focus on here is "The type is the contract". Instead of specifying a contract though operations, just use concrete types, including primitive types to specify the desired qualities of the generic type. Op donderdag 18 oktober 2018 08:52:30 UTC+2 schreef kortschak: >

Re: [go-nuts] Regarding contracts

If you require that a single like type applies to all the labels in the parameter declaration, such that func f(a, b T like int, c, d T2 like string) means a and be must be like T's instantiating type, and c and d must be like T2's unstantiating type, then you get that. If you only require a singl

Re: [go-nuts] Regarding contracts

I think there are serious issues with your syntax for functions and “templates.” For example, there doesn’t seem to be a way to specify that two parameters to a function need to be the same type, or that the return type will be the same as the parameter. The syntax from the official proposal is

Re: [go-nuts] Regarding contracts

On Wed, Oct 17, 2018 at 1:47 PM Andy Balholm wrote: > > That’s a very interesting idea. It would probably need to be extended to > allow specifying that a type is like multiple types. Then the effective > “contract” would be the intersection of the operations provided by those > types. For exam

Re: [go-nuts] Regarding contracts

That’s a very interesting idea. It would probably need to be extended to allow specifying that a type is like multiple types. Then the effective “contract” would be the intersection of the operations provided by those types. For example, we would want to be able to specify a type that is like bo

Re: [go-nuts] Regarding contracts

Burak Serdar : > Instead of specifying the minimal set of operations a type should > satisfy, why not describe what the type should look like: I don't know if this can be followed through to a full proposal, but I like the out-of-the-box thinking. -- http://www.catb.org/~esr/";>Er