subject:"\[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.
>
> Can you provide an example of what some code using this would look like?
> The discussion in the abstract just isn't sticking to my brain...


I've been thinking about this for the last couple of hours, and I
have to admit, I got really close to giving up. Maybe a linked
list is not the best example to illustrate this. Anyway

You would normally implement a linked list like this using parameterized types:

package linkedlist

type Node(type T) struct {
  next *Node(T)
  Stuff T
}

type LinkedList(type T) struct {
  head *Node(T)
}

func (l *LinkedList(T)) Add(n *Node(T)) {
  n.next=nil
  if l.head==nil {
l.head=n
  } else {
l.head.next=n
  }
}

func (l LinkedList(T)) Itr(f func(*Node(T))) {
  for node:=l.head;node!=nil;node=node.next {
f(node)
  }
}


Then use this as:

var myList linkedlist.LinkedList(int)


However, using the "like" keyword, the following should also
be possible, which I think is more interesting than the above. I
needed something like this more than once during my Java days:

(this is different from the linkedlist I had earlier in the thread)

package linkedlist

// Define Node as a template that should satisfy the given struct contract
type Node like struct {
  next *Node
}

// LinkedList is a parameterized type, it will use nodes that look like a Node
type LinkedList(type T like(Node))  struct {
  head *T
}

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

func (l LinkedList) Itr(f func(n *Node)) {
  for node:=l.head;node!=nil;node=node.next {
f(node)
  }
}

package mypkg

type MyNode linkedList.Node {
  next *MyNode
  Stuff DataType
}

func f() {
  var myList linkedlist.LinkedList(MyNode)

  myList.Add({})
}


Let me know if this makes sense. There is still a lot that needs
to be figured out, and I wouldn't be surprised if the idea
collapses completely.

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

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
> > around that restriction.
> >
> > But precisely because this could easily be patched into interfaces,
> > I think it's not much of an argument for your plan.
> 
> To spell out how this would for anyone who doesn't immediately see the
> design, you could e.g. extend interfaces to be able to have fields like
> so:
> 
> type HasName interface {
> Name string
> }

I think it could be simpler than that. The Name part isn't necessary;
anything that isn't a fieldname should be syntactically
distinguishable.

> I am neutral-to-against doing this, as normally when abstracting over
> something, it is a behavior, not a field. But if being able to specify
> "must have this field," is deemed necessary, I agree this is the way to
> do it.

Quite.  Alas, ianlancetaylor's explanation of why this feature was rejected
is sufficient.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

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 represents a semver-style version number
type Version struct {
Major, Minor, Micro int
}

// We define a custom definition of `<` that checks which version is
// older.
func (v Version) Less(other Version) bool implements < {
switch {
case v.Major < other.Major:
return true
case v.Major > other.Major:
return false
case v.Minor < other.Minor:
return true
case v.Minor > other.Minor:
return false
default:
return v.Micro < other.Micro
}
}
```

..and then use `<` to compare Versions. By contrast, your proposal does
not make it possible to define custom notions of `<` on user defined
types.

> Another thing that motivated me to start this thread in the first
> place was imagining myself sitting late at night trying to figure out
> how to convert a huge chunk of code to a generic type, and reading
> through to figure out exactly what the contract is. With the "like"
> syntax, I could simply add "like X" to my arguments, and be done with
> it. With interfaces containing "implements", I have to write those
> interfaces and figure out exactly what I need.

With interfaces using implements, you can start off just specifying no
constraints on your generic parameters, and then follow the type errors
until you've added all of the necessary methods.

While pinning down exactly what the contract needs to be is a bit of
extra up-front work, I think it is important to keep these contracts
clear; one of my biggest concerns with the draft design is that I do not
believe it encourages thinking about intent.

> With contracts, I imagine someone would come up with a tool to build
> that from the source if it comes to that.

This could also be built for the interface version; just see what
methods are called and put them in an interface that the parameter must
implement.

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
> around that restriction.
>
> But precisely because this could easily be patched into interfaces,
> I think it's not much of an argument for your plan.

To spell out how this would for anyone who doesn't immediately see the
design, you could e.g. extend interfaces to be able to have fields like
so:

type HasName interface {
Name string
}

To implement this, a type would have to have a field Name with the type
string.

I am neutral-to-against doing this, as normally when abstracting over
something, it is a behavior, not a field. But if being able to specify
"must have this field," is deemed necessary, I agree this is the way to
do it.

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

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 talking about https://golang.org/issue/23796 (which
> was not accepted).

Thank you, Ian, that explanation is very clarifying.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

Re: [go-nuts] Regarding contracts

2018-10-19 Thread Ian Lance Taylor

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/setters.
>
> I'm puzzled that this is not already possible in interfaces.
>
> In the translation from Python I'm working on, I cave two different
> classes, One, VCS, represents an importer/exporter pair for a given
> version-control system that speaks the git import stram
> format. Another, Extractor, bundles methods for mining data from a
> repository by harnessing its native client tools.
>
> 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.
>
> But precisely because this could easily be patched into interfaces,
> I think it's not much of an argument for your plan.

I think you are talking about https://golang.org/issue/23796 (which
was not accepted).

Ian

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

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

In the translation from Python I'm working on, I cave two different
classes, One, VCS, represents an importer/exporter pair for a given
version-control system that speaks the git import stram
format. Another, Extractor, bundles methods for mining data from a
repository by harnessing its native client tools.

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.

But precisely because this could easily be patched into interfaces,
I think it's not much of an argument for your plan.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

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 additional explicitness of "implements" is valuable.  And
> my syntax is lighter-weight than yours - which in a language like Go
> that highly values parsimony has some significance.

I don't agree.

>
> That said, the shared idea of defining contracts via implied typeclasses
> is, I think, more important than the ways in which our proposals differ.

I agree.

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.

> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
>
>

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

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 lighter-weight than yours - which in a language like Go
that highly values parsimony has some significance.

That said, the shared idea of defining contracts via implied typeclasses
is, I think, more important than the ways in which our proposals differ.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

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 a full generic-type system in
> itself, nor is it meant to be.  It's meant to be an orthogonal piece
> that replaces heavyweight contracts proposals, and needs to be mated
> with a system ot parametric polymorphism and one of type composition

I agree that "implements" construct solves a lot of problems.

However:

Without operator overloading:

type X interface {
   implements <
}

means that you want a primitive numeric type or a string. So:

type Y like(int,string)

Even though it is not as precise as the interface with implements, it
means the same thing.

Assuming you have operator overloading, the X interface will
accept any primitive or struct type that implements <, whereas Y
won't. However, when you have operator overloading, you can still use:

type Y like(X)

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

Another thing that motivated me to start this thread in the first
place was imagining myself sitting late at night trying to figure out
how to convert a huge chunk of code to a generic type, and reading
through to figure out exactly what the contract is. With the "like"
syntax, I could simply add "like X" to my arguments, and be done with
it. With interfaces containing "implements", I have to write those
interfaces and figure out exactly what I need. With contracts, I
imagine someone would come up with a tool to build that from the
source if it comes to that.
.
>
> * To the compiler, the contract implied by each operator is just its type
> signature (e.g '<' has the signature a.(T).func(b T) bool) and
> precedence.  The semantics of what each possible operator means
> (e.g. < is for sorting, + is a concatenation operator) is a social
> convention expressed by how the operator is used by the standard
> library and packages.
>
> * Other considerations in the language imply a rule that operators on pointer
> types cannot have implements methods (but non-pointer types can have 
> implements
> methods with pointer receivers).
>
> * There is room for debate about which operators can be the subject of
> an implements clause. Everybody clearly wants < + - == | & (what you
> need to do set algebra) and I think ! is important. There is a
> general feeling that =+ =- and friends should not be overloadable but
> should be considered lexical abbreviations in the obvious way.
>
> * There is debate about whether there should be implied overloading - that is
> if a method foo(a T, b T) implements == should it be the case that not
> only a == b translates to foo(a, b) but a != b translates to !foo(a, b).
>
> I'm not strongly attached to a position on either of the debates. I
> note howvever that I do not want a < b to imply !(b > a) because I do
> things with graphs and lattice algebra and want to be able to express
> partial (not just total) ordering.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
>
>

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

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 look like?
The discussion in the abstract just isn't sticking to my brain...

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

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 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 known way, like the Graph/Node/Edge case in the
> >> design draft.
> >
> >
> > Still discussing the details, but the graph case in the design draft
> > can look like this:
> >
> > type Node like interface {
> >Edges() []Edge
> > }
> >
> > type Edge like interface {
> >Nodes() (Node,Node)
> > }
> >
> > type Graph like struct {
> >Nodes []*Node
> > }
> >
> > func New(nodes []*Node) *Graph {
> >   return {Nodes:nodes}
> > }
> >
> >
> > The instantiation:
> >
> > type MyNode struct {...}
> >
> > func (m MyNode) Edges() []MyEdge {...}
> >
> > type MyEdge  struct { ...}
> >
> > func (e MyEdge) Nodes() (*MyNode,*MyNode) {...}
> >
> > type MyGraph graph.Graph {
> >   Nodes []*MyNodes
> > }
> >
> > x:=graph.New(MyGraph)(myNodes)
>
> Thanks.  I note the subtlety whereby the name Edge in the generic code
> gets attached to the name MyEdge in the non-generic code, although it
> does not appear anywhere in the call to graph.New.  There is a type
> mapping happening somewhere.

This is still work in progress, but:

graph.New(MyGraph)(myNodes) maps MyGraph to graph.Graph. From
MyGraph.Nodes, MyNode (not MyNodes, there is a typo in the example)
maps to graph.Node, and from MyNode.Edges(), MyEdge maps to
graph.Edge.


I wrote

type MyGraph graph.Graph {
}

for the declaration of the MyGraph type as an instantiation of the
template graph.Graph, and that also could be used for the same type
inference.

>
> Ian

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

Re: [go-nuts] Regarding contracts

2018-10-19 Thread Ian Lance Taylor

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 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 known way, like the Graph/Node/Edge case in the
>> design draft.
>
>
> Still discussing the details, but the graph case in the design draft
> can look like this:
>
> type Node like interface {
>Edges() []Edge
> }
>
> type Edge like interface {
>Nodes() (Node,Node)
> }
>
> type Graph like struct {
>Nodes []*Node
> }
>
> func New(nodes []*Node) *Graph {
>   return {Nodes:nodes}
> }
>
>
> The instantiation:
>
> type MyNode struct {...}
>
> func (m MyNode) Edges() []MyEdge {...}
>
> type MyEdge  struct { ...}
>
> func (e MyEdge) Nodes() (*MyNode,*MyNode) {...}
>
> type MyGraph graph.Graph {
>   Nodes []*MyNodes
> }
>
> x:=graph.New(MyGraph)(myNodes)

Thanks.  I note the subtlety whereby the name Edge in the generic code
gets attached to the name MyEdge in the non-generic code, although it
does not appear anywhere in the call to graph.New.  There is a type
mapping happening somewhere.

Ian

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

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 "sorting" example can be written using
> > the "like" keyword as:
> >
>
> > Template:
> >
> > type orderedSlice []like (int,string)
> >
> > func (s orderedSlice) Len() int   { return len(s) }
> > func (s orderedSlice) Less(i, j int) bool { return s[i] > func (s orderedSlice) Swap(i, j int)  { s[i], s[j] = s[j], s[i] }
> >
> > // There is no need for an OrderedSlice function
> >
> > Concerete use:
> >
> > type mySlice orderedSlice []int64
> >
> > v:=mySlice{1,2,3}
> > sort.Slice(v)
>
> This example in my proposal was intended to show the minimal change
> needed from the draft design, but I also mentioned that you actually
> didn't need `orderedSlice` at all to sort slices. If you combine it
> with Eric's proposal for operator overloading, you can just write
>
> v := []int64{1,2,3}
> sort.Slice(v)
>
> ..with no boilerplate type/method definitions, or casts, at all.
>
> > However, one limitation of using interfaces to specify contracts
> > is that you can't use a struct type as a basis for your
> > contract. For instance, going back to the linked list example:
> >
> > type Node like struct {
> >next *Node
> > }
> >
> > With interfaces as contracts, this becomes:
> >
> > type Node(type E) interface {
> >GetNext()
> >SetNext(*Node(E))
> > }
>
> This is true; exposing the next-pointer structure of a linked list
> through an interface is more verbose. However I'm not convinced there
> are good uses for this; Can you provide an example where such a template
> would actually be useful?

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.

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

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

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

> Template:
>
> type orderedSlice []like (int,string)
>
> func (s orderedSlice) Len() int   { return len(s) }
> func (s orderedSlice) Less(i, j int) bool { return s[i] func (s orderedSlice) Swap(i, j int)  { s[i], s[j] = s[j], s[i] }
>
> // There is no need for an OrderedSlice function
>
> Concerete use:
>
> type mySlice orderedSlice []int64
>
> v:=mySlice{1,2,3}
> sort.Slice(v)

This example in my proposal was intended to show the minimal change
needed from the draft design, but I also mentioned that you actually
didn't need `orderedSlice` at all to sort slices. If you combine it
with Eric's proposal for operator overloading, you can just write

v := []int64{1,2,3}
sort.Slice(v)

..with no boilerplate type/method definitions, or casts, at all.

> However, one limitation of using interfaces to specify contracts
> is that you can't use a struct type as a basis for your
> contract. For instance, going back to the linked list example:
>
> type Node like struct {
>next *Node
> }
>
> With interfaces as contracts, this becomes:
>
> type Node(type E) interface {
>GetNext()
>SetNext(*Node(E))
> }

This is true; exposing the next-pointer structure of a linked list
through an interface is more verbose. However I'm not convinced there
are good uses for this; Can you provide an example where such a template
would actually be useful?

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

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 to be an orthogonal piece
that replaces heavyweight contracts proposals, and needs to be mated
with a system ot parametric polymorphism and one of type composition.

* To the compiler, the contract implied by each operator is just its type
signature (e.g '<' has the signature a.(T).func(b T) bool) and
precedence.  The semantics of what each possible operator means
(e.g. < is for sorting, + is a concatenation operator) is a social
convention expressed by how the operator is used by the standard
library and packages.

* Other considerations in the language imply a rule that operators on pointer
types cannot have implements methods (but non-pointer types can have implements
methods with pointer receivers).

* There is room for debate about which operators can be the subject of
an implements clause. Everybody clearly wants < + - == | & (what you
need to do set algebra) and I think ! is important. There is a
general feeling that =+ =- and friends should not be overloadable but
should be considered lexical abbreviations in the obvious way.

* There is debate about whether there should be implied overloading - that is
if a method foo(a T, b T) implements == should it be the case that not
only a == b translates to foo(a, b) but a != b translates to !foo(a, b).

I'm not strongly attached to a position on either of the debates. I
note howvever that I do not want a < b to imply !(b > a) because I do
things with graphs and lattice algebra and want to be able to express
partial (not just total) ordering.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

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 without providing
> > operator overloading. But *the problem itself* is not being able to abstract
> > over operators, so this approach is doomed to failure. You just result in a
> > clumsy design that can't decide if it's trying to allow operators to be
> > abstracted over or not, since the whole point is to allow this, but the
> > particulars of the design are motivated by a fear of actually doing so.
> >
> > I there is a fundamental conflict here. You can express the same concepts
> > as with operator overloading if you're willing to wrap the basic types and 
> > use
> > methods like .Less() in generic code. 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.
>
> Ian has just unpacked my "unwelcome conclusion" very nicely.  This is 
> *exactly*
> the insight that led me to design "implements".
>
> This is why I confidently predict that nobody will find a simpler way
> to approximate contracts than "implements".  Ever. (In particular,
> Burak's way is, though clever and interesting, not simpler.) Because
> "implements" is the dead bare minimum expression of abstracting over
> operators; anything else you do to go near that has to be more
> complicated and roundabout.

Where can I read about this "implements"? Link?

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

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 not being able to abstract
> over operators, so this approach is doomed to failure. You just result in a
> clumsy design that can't decide if it's trying to allow operators to be
> abstracted over or not, since the whole point is to allow this, but the
> particulars of the design are motivated by a fear of actually doing so.
> 
> I there is a fundamental conflict here. You can express the same concepts
> as with operator overloading if you're willing to wrap the basic types and use
> methods like .Less() in generic code. 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.

Ian has just unpacked my "unwelcome conclusion" very nicely.  This is *exactly*
the insight that led me to design "implements".

This is why I confidently predict that nobody will find a simpler way
to approximate contracts than "implements".  Ever. (In particular,
Burak's way is, though clever and interesting, not simpler.) Because
"implements" is the dead bare minimum expression of abstracting over
operators; anything else you do to go near that has to be more
complicated and roundabout.

Of course "implements" is not an entire generic system; we need syntax
and semantics for parametric polymorphism and parametric types, too.
But it's a *good thing* that "implements" can be described without any
reference to these concerns; it means we have *orthogonality*.

I would go further than that and say any proposal that has  to specify all
three extensions (contracts, parametric polymorphism, parametric types)
at once in order for any of it to work is too complex, fails orthogonality
forever, and should be regarded with deep suspicion that it is overcommitting
the language in a wrong direction.

The "implements" proposal adds just one keyword. *One,* and the syntax
is trivial. That's not just parsimony on the surface, it's a
fundamental clue that we have found the simplest way possible to
express what it gives us access to.

-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

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. Without looking for flames, this is how Java does it 
> and it’s never been a problem. You could go farther and define bool 
> T.Equality(T) and have Equals defer to that when the type casts pass, or have 
> the compiler perform the check and make the call.
>
> So I’m not sure of the problem.

I don't have strong opinions about operator overloading vs. using
methods for operators. The point of this thread was to offer an
alternative to contracts, and the alternative offered is still
valid with or without operator overloading.

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:

Template:

type orderedSlice []like (int,string)

func (s orderedSlice) Len() int   { return len(s) }
func (s orderedSlice) Less(i, j int) bool { return s[i]
> On Oct 19, 2018, at 7:59 AM, Lucio  wrote:
>
> 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.
>>
> The issue that has not been raised yet, but is bound to come up, is that 
> operators compose into expressions whereas methods have a much simpler, much 
> more restrictive composition paradigm. Add operator precedence to the mix and 
> stand well back.
>
> I frankly prefer methods to operators, but the need here is to retain the 
> features of operators within generics and that means dealing with precedence 
> as well as conversion, not just within the arithmetic realm, but specially 
> across the operation, like when == transforms practically any compatible 
> operands to a boolean result.
>
> Just adding my two cents of accelerant to a flammable mixture. Feel free to 
> point out, if applicable, that I'm off topic and, specially instructive, why. 
> But make it simple, there has been quite a bit written here I don't think 
> I'll ever get my head around.
>
> Lucio.
>
> --
> 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.

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

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 Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

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" proposal in that it uses
the semantic richness of primitive types to carve up contract space, rather
than defining an extension language to describe contracts from the ground up.

I still like "implements" better because it's simpler - just one new keyword.
Also I think the granularity of "like this operator" is more appropriate than
the granularity of "like this type".  That said, I like Burak's design better
than anything I've seen yet *except* "implements".
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


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

Re: [go-nuts] Regarding contracts

2018-10-19 Thread Robert Engels

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 been a problem. You could go farther and define bool T.Equality(T) 
and have Equals defer to that when the type casts pass, or have the compiler 
perform the check and make the call. 

So I’m not sure of the problem. 

> On Oct 19, 2018, at 7:59 AM, Lucio  wrote:
> 
>> 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. 
>> 
> The issue that has not been raised yet, but is bound to come up, is that 
> operators compose into expressions whereas methods have a much simpler, much 
> more restrictive composition paradigm. Add operator precedence to the mix and 
> stand well back.
> 
> I frankly prefer methods to operators, but the need here is to retain the 
> features of operators within generics and that means dealing with precedence 
> as well as conversion, not just within the arithmetic realm, but specially 
> across the operation, like when == transforms practically any compatible 
> operands to a boolean result.
> 
> Just adding my two cents of accelerant to a flammable mixture. Feel free to 
> point out, if applicable, that I'm off topic and, specially instructive, why. 
> But make it simple, there has been quite a bit written here I don't think 
> I'll ever get my head around.
> 
> Lucio.
> -- 
> 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.

Re: [go-nuts] Regarding contracts

2018-10-19 Thread Lucio

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. 
>
> The issue that has not been raised yet, but is bound to come up, is that 
operators compose into expressions whereas methods have a much simpler, 
much more restrictive composition paradigm. Add operator precedence to the 
mix and stand well back.

I frankly prefer methods to operators, but the need here is to retain the 
features of operators within generics and that means dealing with 
precedence as well as conversion, not just within the arithmetic realm, but 
specially across the operation, like when == transforms practically any 
compatible operands to a boolean result.

Just adding my two cents of accelerant to a flammable mixture. Feel free to 
point out, if applicable, that I'm off topic and, specially instructive, 
why. But make it simple, there has been quite a bit written here I don't 
think I'll ever get my head around.

Lucio.

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

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 to F because < isn’t valid on structs ???
> >
> > Which is why I proposed that < maps to Less() and then the primitives 
> > simplicity implement these various methods, and user defined structs MIGHT.
> >
> > That way you write the code using Less(), and it works with primitives as 
> > well.
>
> This is what I was getting at; simply making the operators correspond to
> methods is a well-known and fairly straightforward solution to the
> problem, and it seems like the idea proposed in this thread is much more
> complex.
>
> Once you allow operators to simply correspond to methods, you can just
> worry about how to abstract over methods, which you can do with
> interfaces. My proposal outlines a variant of this that is fairly
> simple, yet (once adding something like operator overloading) is still
> able to handle every single example in the draft.
>
> You can either give the primitive types methods, or allow methods to
> override operators; both approaches work.
>
> Burak, apologies if I've misinterpreted your own line of thinking.

You did not misinterpret what I said. I agree that your proposal is
quite similar to mine.

One crucial difference between the two is, I think, my line of
thinking is based on templates, and yours is on interfaces. So using
my approach, you can require that a type contains certain members, not
just methods. I don't know how important that is, but after working
with Java for many years, I developed a strong dislike for
getter/setters.

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

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Ian Denhardt

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 < maps to Less() and then the primitives 
> simplicity implement these various methods, and user defined structs MIGHT.
>
> That way you write the code using Less(), and it works with primitives as 
> well.

This is what I was getting at; simply making the operators correspond to
methods is a well-known and fairly straightforward solution to the
problem, and it seems like the idea proposed in this thread is much more
complex.

Once you allow operators to simply correspond to methods, you can just
worry about how to abstract over methods, which you can do with
interfaces. My proposal outlines a variant of this that is fairly
simple, yet (once adding something like operator overloading) is still
able to handle every single example in the draft.

You can either give the primitive types methods, or allow methods to
override operators; both approaches work.

Burak, apologies if I've misinterpreted your own line of thinking.

-Ian

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

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 more verbose - but it avoids the traditional 
problems with operator overloading leading to obtuse code.

> On Oct 18, 2018, at 2:28 PM, Burak Serdar  wrote:
> 
> 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 that said "provided X is a type that supports <".
> This was a hypothetical case where we could define < for X.
> 
> 
>> 
>> Which is why I proposed that < maps to Less() and then the primitives 
>> simplicity implement these various methods, and user defined structs MIGHT.
>> 
>> That way you write the code using Less(), and it works with primitives as 
>> well.
>> 
>> 
>> 
>> 
>>> 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 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 elegantly and would allow us to unify 
>>> the strings and bytes packages into one generic package.
>>> 
>>> --
>>> 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.

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

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 that said "provided X is a type that supports <".
This was a hypothetical case where we could define < for X.


>
> Which is why I proposed that < maps to Less() and then the primitives 
> simplicity implement these various methods, and user defined structs MIGHT.
>
> That way you write the code using Less(), and it works with primitives as 
> well.
>
>
>
>
> > 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 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 elegantly and would allow us to unify 
> > the strings and bytes packages into one generic package.
> >
> > --
> > 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.

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

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 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 elegantly and would allow us to unify 
> the strings and bytes packages into one generic package.
> 
> -- 
> 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.

[go-nuts] Regarding contracts

2018-10-18 Thread Beoran

Let's get serious about this. I started a GitHub repository to work on this 
proposal. https://github.com/beoran/go-like-generics-proposal/ 
You are all cordially invited to help out fleshing out this proposal.

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

Re: [go-nuts] Regarding contracts

2018-10-18 Thread bjorn . de . meyer

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 elegantly and would allow us to unify the 
strings and bytes packages into one generic package.

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

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, my own proposal for "just using interfaces" covered the graph use
> case. The code doesn't look far off from what Burak sketched in a
> sibling comment, but does have some key differences that I think are
> important to bridge the gap:
>
> 
> https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters
>
> I think adding operators to that proposal actually covers every use case
> covered by the draft design. I left them out originally because of a
> snafu with the == operator, but ESR has offered a way around that.
>
> ---
>
> 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 not being able to abstract
> over operators, so this approach is doomed to failure. You just result in a
> clumsy design that can't decide if it's trying to allow operators to be
> abstracted over or not, since the whole point is to allow this, but the
> particulars of the design are motivated by a fear of actually doing so.


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
> I there is a fundamental conflict here. You can express the same concepts
> as with operator overloading if you're willing to wrap the basic types and use
> methods like .Less() in generic code. 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.
>
> -Ian

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

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Ian Denhardt

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
case. The code doesn't look far off from what Burak sketched in a
sibling comment, but does have some key differences that I think are
important to bridge the gap:

https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters

I think adding operators to that proposal actually covers every use case
covered by the draft design. I left them out originally because of a
snafu with the == operator, but ESR has offered a way around that.

---

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 not being able to abstract
over operators, so this approach is doomed to failure. You just result in a
clumsy design that can't decide if it's trying to allow operators to be
abstracted over or not, since the whole point is to allow this, but the
particulars of the design are motivated by a fear of actually doing so.

I there is a fundamental conflict here. You can express the same concepts
as with operator overloading if you're willing to wrap the basic types and use
methods like .Less() in generic code. 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.

-Ian

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

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Andy Balholm

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  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 known way, like the Graph/Node/Edge case in the
> design draft.
> 
> Ian
> 
> -- 
> 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.

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 this approach can handle multiple types that need to
> work together in some known way, like the Graph/Node/Edge case in the
> design draft.


Still discussing the details, but the graph case in the design draft
can look like this:

type Node like interface {
   Edges() []Edge
}

type Edge like interface {
   Nodes() (Node,Node)
}

type Graph like struct {
   Nodes []*Node
}

func New(nodes []*Node) *Graph {
  return {Nodes:nodes}
}


The instantiation:

type MyNode struct {...}

func (m MyNode) Edges() []MyEdge {...}

type MyEdge  struct { ...}

func (e MyEdge) Nodes() (*MyNode,*MyNode) {...}

type MyGraph graph.Graph {
  Nodes []*MyNodes
}

x:=graph.New(MyGraph)(myNodes)




>
> Ian

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

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Ian Lance Taylor

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 known way, like the Graph/Node/Edge case in the
design draft.

Ian

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

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 
> source of Y and look at how xyz is documented (hopefully), and then hope the 
> implementation never changes… That’s a lot of hoping.

Maybe we're thinking this all wrong. So far we've been talking about
template functions, but not template types.


Let's write the linked list type contract:

package linkedlist

type LinkedList like struct {
  head *like Node
}

type Node like struct {
  next *like Node
}

func (l *LinkedList) Add(in *Node) {
  ...
}


Now let's use the linked list:

type TheLinkedList linkedlist.LinkedList {
  head *TheNode
}

type TheNode linkedlist.Node {
  next *TheNode
  more stuff
}

var myLinkedList TheLinkedList


myLinkedList.Add() works now.

I do not like the "type name templatename" syntax, something else is
needed there.

>
> > On Oct 18, 2018, at 11:08 AM, Burak Serdar  wrote:
> >
> > 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 not correct. This does not require that everything should be
> > in the same package. It requires that the private fields must be
> > accessible where the template is instantiated.
> >
> > If the Add function is declared in package A and used in package B,
> > then Add() would have access to all private fields of package B,
> > because that's where it is instantiated.
> >
> >>
> >> Field access just seems unworkable to me. To much to understand (and 
> >> document) rather than just using interfaces which already need to be 
> >> understood and documented.
> >>
> >> Only allow interfaces as types and I’m fine. The primitives just need 
> >> pseudo interfaces defined for their operations and all is good.
> >>
> >> granted, you would never write a LinkedList like that with embedded 
> >> pointers in the elements - not if you want safe code - but it was just 
> >> used an example of the abuse that will occur.
> >>
> >>
> >> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
> >>
> >> 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 
> >> containing T, is far different than X being a T, and I am not sure the 
> >> semantics of the function will hold.
> >>
> >> Imagine a
> >>
> >> type Node struct {
> >>  link *Node
> >> }
> >>
> >> then you have a linked list
> >>
> >> type LinkedList struct {
> >>   head *node
> >> }
> >>
> >> with
> >>
> >> func (LinkedList *) Add(n like Node){ blah..}
> >>
> >> passing a
> >>
> >> struct MyNode {
> >>  Node
> >>  value int
> >> }
> >>
> >> will not work, because the reference passed to Add() points to inner 
> >> instance.
> >>
> >>
> >> In this example, neither LinkedList nor Node are templates, but Add is
> >> a template. Let's try to write the Add function.
> >>
> >> func (l *LinkedList) Add(n type *T like(Node)) {
> >> if l.head==nil {
> >>   l.head=n
> >>   n.link=nil
> >>   return
> >> }
> >> tail:=l.head
> >> for tail.link!=nil {
> >>tail=tail.link
> >> }
> >> n.link=nil
> >> tail.link=n
> >> }
> >>
> >> This should compile for:
> >>
> >> l.Add({value:1})
> >>
> >> if private values of MyNode is accessible where it is used. That means
> >> the following won't work:
> >>
> >> package A
> >>
> >> struct MyNode {private fields}
> >>
> >> package B
> >>
> >> l.Add({})
> >>
> >> However, if private fields of MyNode is accessible where Add() is
> >> instantiated, Add should compile without any errors.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> you would need to create:
> >>
> >> struct MyNode {
> >>   Link *Node
> >>   value int
> >> }
> >>
> >> and make link exported - meaning you need to understand the internal 
> >> details of LinkedList in order to use it.
> >>
> >> At least I think so… :)
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
> >>
> >> 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 certainly requires dynamic access to 
> >> fields, essentially making all method and field access dynamic, and I 
> >> don’t think the Go performance hounds will go for

Re: [go-nuts] Regarding contracts

2018-10-18 Thread 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. 

Andy


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

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 then hope the 
implementation never changes… That’s a lot of hoping.

> On Oct 18, 2018, at 11:08 AM, Burak Serdar  wrote:
> 
> 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 not correct. This does not require that everything should be
> in the same package. It requires that the private fields must be
> accessible where the template is instantiated.
> 
> If the Add function is declared in package A and used in package B,
> then Add() would have access to all private fields of package B,
> because that's where it is instantiated.
> 
>> 
>> Field access just seems unworkable to me. To much to understand (and 
>> document) rather than just using interfaces which already need to be 
>> understood and documented.
>> 
>> Only allow interfaces as types and I’m fine. The primitives just need pseudo 
>> interfaces defined for their operations and all is good.
>> 
>> granted, you would never write a LinkedList like that with embedded pointers 
>> in the elements - not if you want safe code - but it was just used an 
>> example of the abuse that will occur.
>> 
>> 
>> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
>> 
>> 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 
>> containing T, is far different than X being a T, and I am not sure the 
>> semantics of the function will hold.
>> 
>> Imagine a
>> 
>> type Node struct {
>>  link *Node
>> }
>> 
>> then you have a linked list
>> 
>> type LinkedList struct {
>>   head *node
>> }
>> 
>> with
>> 
>> func (LinkedList *) Add(n like Node){ blah..}
>> 
>> passing a
>> 
>> struct MyNode {
>>  Node
>>  value int
>> }
>> 
>> will not work, because the reference passed to Add() points to inner 
>> instance.
>> 
>> 
>> In this example, neither LinkedList nor Node are templates, but Add is
>> a template. Let's try to write the Add function.
>> 
>> func (l *LinkedList) Add(n type *T like(Node)) {
>> if l.head==nil {
>>   l.head=n
>>   n.link=nil
>>   return
>> }
>> tail:=l.head
>> for tail.link!=nil {
>>tail=tail.link
>> }
>> n.link=nil
>> tail.link=n
>> }
>> 
>> This should compile for:
>> 
>> l.Add({value:1})
>> 
>> if private values of MyNode is accessible where it is used. That means
>> the following won't work:
>> 
>> package A
>> 
>> struct MyNode {private fields}
>> 
>> package B
>> 
>> l.Add({})
>> 
>> However, if private fields of MyNode is accessible where Add() is
>> instantiated, Add should compile without any errors.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> you would need to create:
>> 
>> struct MyNode {
>>   Link *Node
>>   value int
>> }
>> 
>> and make link exported - meaning you need to understand the internal details 
>> of LinkedList in order to use it.
>> 
>> At least I think so… :)
>> 
>> 
>> 
>> 
>> 
>> 
>> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
>> 
>> 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 certainly requires dynamic access to 
>> fields, essentially making all method and field access dynamic, and I don’t 
>> think the Go performance hounds will go for it. I am
>> 
>> 
>> I don't understand this concern either.
>> 
>> func F(in like T)
>> 
>> is a template. When the compiler instantiates F with a concrete type
>> T, a new copy of F is compiled using that type. There is no dynamic
>> access involved there, everything is statically resolved.
>> 
>> not even certain it can be done without runtime reflection.
>> 
>> 
>> But still a developer having to create a Bar with all of the exported 
>> methods and fields of Foo seems daunting.
>> 
>> 
>> --
>> 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

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 not correct. This does not require that everything should be
in the same package. It requires that the private fields must be
accessible where the template is instantiated.

If the Add function is declared in package A and used in package B,
then Add() would have access to all private fields of package B,
because that's where it is instantiated.

>
> Field access just seems unworkable to me. To much to understand (and 
> document) rather than just using interfaces which already need to be 
> understood and documented.
>
> Only allow interfaces as types and I’m fine. The primitives just need pseudo 
> interfaces defined for their operations and all is good.
>
> granted, you would never write a LinkedList like that with embedded pointers 
> in the elements - not if you want safe code - but it was just used an example 
> of the abuse that will occur.
>
>
> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
>
> 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 
> containing T, is far different than X being a T, and I am not sure the 
> semantics of the function will hold.
>
> Imagine a
>
> type Node struct {
>   link *Node
> }
>
> then you have a linked list
>
> type LinkedList struct {
>head *node
> }
>
> with
>
> func (LinkedList *) Add(n like Node){ blah..}
>
> passing a
>
> struct MyNode {
>   Node
>   value int
> }
>
> will not work, because the reference passed to Add() points to inner instance.
>
>
> In this example, neither LinkedList nor Node are templates, but Add is
> a template. Let's try to write the Add function.
>
> func (l *LinkedList) Add(n type *T like(Node)) {
>  if l.head==nil {
>l.head=n
>n.link=nil
>return
>  }
>  tail:=l.head
>  for tail.link!=nil {
> tail=tail.link
>  }
>  n.link=nil
>  tail.link=n
> }
>
> This should compile for:
>
> l.Add({value:1})
>
> if private values of MyNode is accessible where it is used. That means
> the following won't work:
>
> package A
>
> struct MyNode {private fields}
>
> package B
>
> l.Add({})
>
> However, if private fields of MyNode is accessible where Add() is
> instantiated, Add should compile without any errors.
>
>
>
>
>
>
>
> you would need to create:
>
> struct MyNode {
>Link *Node
>value int
> }
>
> and make link exported - meaning you need to understand the internal details 
> of LinkedList in order to use it.
>
> At least I think so… :)
>
>
>
>
>
>
> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
>
> 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 certainly requires dynamic access to 
> fields, essentially making all method and field access dynamic, and I don’t 
> think the Go performance hounds will go for it. I am
>
>
> I don't understand this concern either.
>
> func F(in like T)
>
> is a template. When the compiler instantiates F with a concrete type
> T, a new copy of F is compiled using that type. There is no dynamic
> access involved there, everything is statically resolved.
>
> not even certain it can be done without runtime reflection.
>
>
> But still a developer having to create a Bar with all of the exported methods 
> and fields of Foo seems daunting.
>
>
> --
> 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.
>
>

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

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 document) 
rather than just using interfaces which already need to be understood and 
documented.

Only allow interfaces as types and I’m fine. The primitives just need pseudo 
interfaces defined for their operations and all is good.

granted, you would never write a LinkedList like that with embedded pointers in 
the elements - not if you want safe code - but it was just used an example of 
the abuse that will occur.


> On Oct 18, 2018, at 10:56 AM, Burak Serdar  wrote:
> 
> 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 
>> containing T, is far different than X being a T, and I am not sure the 
>> semantics of the function will hold.
>> 
>> Imagine a
>> 
>> type Node struct {
>>   link *Node
>> }
>> 
>> then you have a linked list
>> 
>> type LinkedList struct {
>>head *node
>> }
>> 
>> with
>> 
>> func (LinkedList *) Add(n like Node){ blah..}
>> 
>> passing a
>> 
>> struct MyNode {
>>   Node
>>   value int
>> }
>> 
>> will not work, because the reference passed to Add() points to inner 
>> instance.
> 
> In this example, neither LinkedList nor Node are templates, but Add is
> a template. Let's try to write the Add function.
> 
> func (l *LinkedList) Add(n type *T like(Node)) {
>  if l.head==nil {
>l.head=n
>n.link =nil
>return
>  }
>  tail:=l.head
>  for tail.link !=nil {
> tail=tail.link 
>  }
>  n.link =nil
>  tail.link =n
> }
> 
> This should compile for:
> 
> l.Add({value:1})
> 
> if private values of MyNode is accessible where it is used. That means
> the following won't work:
> 
> package A
> 
> struct MyNode {private fields}
> 
> package B
> 
> l.Add({})
> 
> However, if private fields of MyNode is accessible where Add() is
> instantiated, Add should compile without any errors.
> 
> 
> 
> 
> 
> 
>> 
>> you would need to create:
>> 
>> struct MyNode {
>>Link *Node
>>value int
>> }
>> 
>> and make link exported - meaning you need to understand the internal details 
>> of LinkedList in order to use it.
>> 
>> At least I think so… :)
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
>>> 
>>> 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 certainly requires dynamic access to 
 fields, essentially making all method and field access dynamic, and I 
 don’t think the Go performance hounds will go for it. I am
>>> 
>>> I don't understand this concern either.
>>> 
>>> func F(in like T)
>>> 
>>> is a template. When the compiler instantiates F with a concrete type
>>> T, a new copy of F is compiled using that type. There is no dynamic
>>> access involved there, everything is statically resolved.
>>> 
>>> not even certain it can be done without runtime reflection.
 
 But still a developer having to create a Bar with all of the exported 
 methods and fields of Foo seems daunting.
>>> 
>>> --
>>> 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.

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

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 
> containing T, is far different than X being a T, and I am not sure the 
> semantics of the function will hold.
>
> Imagine a
>
> type Node struct {
>link *Node
> }
>
> then you have a linked list
>
> type LinkedList struct {
> head *node
> }
>
> with
>
> func (LinkedList *) Add(n like Node){ blah..}
>
> passing a
>
> struct MyNode {
>Node
>value int
> }
>
> will not work, because the reference passed to Add() points to inner instance.

In this example, neither LinkedList nor Node are templates, but Add is
a template. Let's try to write the Add function.

func (l *LinkedList) Add(n type *T like(Node)) {
  if l.head==nil {
l.head=n
n.link=nil
return
  }
  tail:=l.head
  for tail.link!=nil {
 tail=tail.link
  }
  n.link=nil
  tail.link=n
}

This should compile for:

l.Add({value:1})

if private values of MyNode is accessible where it is used. That means
the following won't work:

package A

struct MyNode {private fields}

package B

l.Add({})

However, if private fields of MyNode is accessible where Add() is
instantiated, Add should compile without any errors.






>
> you would need to create:
>
> struct MyNode {
> Link *Node
> value int
> }
>
> and make link exported - meaning you need to understand the internal details 
> of LinkedList in order to use it.
>
> At least I think so… :)
>
>
>
>
>
>
> > On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
> >
> > 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 certainly requires dynamic access to 
> >> fields, essentially making all method and field access dynamic, and I 
> >> don’t think the Go performance hounds will go for it. I am
> >
> > I don't understand this concern either.
> >
> > func F(in like T)
> >
> > is a template. When the compiler instantiates F with a concrete type
> > T, a new copy of F is compiled using that type. There is no dynamic
> > access involved there, everything is statically resolved.
> >
> > not even certain it can be done without runtime reflection.
> >>
> >> But still a developer having to create a Bar with all of the exported 
> >> methods and fields of Foo seems daunting.
> >
> > --
> > 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.

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 the 
semantics of the function will hold.

Imagine a

type Node struct {
   link *Node
}

then you have a linked list

type LinkedList struct {
head *node
}

with

func (LinkedList *) Add(n like Node){ blah..}

passing a 

struct MyNode {
   Node
   value int
}

will not work, because the reference passed to Add() points to inner instance.

you would need to create:

struct MyNode {
Link *Node
value int
}

and make link exported - meaning you need to understand the internal details of 
LinkedList in order to use it.

At least I think so… :)






> On Oct 18, 2018, at 10:03 AM, Burak Serdar  wrote:
> 
> 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 certainly requires dynamic access to 
>> fields, essentially making all method and field access dynamic, and I don’t 
>> think the Go performance hounds will go for it. I am
> 
> I don't understand this concern either.
> 
> func F(in like T)
> 
> is a template. When the compiler instantiates F with a concrete type
> T, a new copy of F is compiled using that type. There is no dynamic
> access involved there, everything is statically resolved.
> 
> not even certain it can be done without runtime reflection.
>> 
>> But still a developer having to create a Bar with all of the exported 
>> methods and fields of Foo seems daunting.
> 
> -- 
> 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.

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 certainly requires dynamic access to 
> fields, essentially making all method and field access dynamic, and I don’t 
> think the Go performance hounds will go for it. I am

I don't understand this concern either.

func F(in like T)

is a template. When the compiler instantiates F with a concrete type
T, a new copy of F is compiled using that type. There is no dynamic
access involved there, everything is statically resolved.

not even certain it can be done without runtime reflection.
>
> But still a developer having to create a Bar with all of the exported methods 
> and fields of Foo seems daunting.

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

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 certainly requires dynamic access to 
> fields, essentially making all method and field access dynamic, and I don’t 
> think the Go performance hounds will go for it. I am not even certain it can 
> be done without runtime reflection.
>
> But still a developer having to create a Bar with all of the exported methods 
> and fields of Foo seems daunting.

That is not intended for copy paste. That is intended for the following case:

type S struct {
   blah...
}

func (s S) F() { ... }


func W(in like S) {
}

type K struct {
 S
}


You can call W(K{})

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

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 and field access dynamic, and I don’t 
think the Go performance hounds will go for it. I am not even certain it can be 
done without runtime reflection. 

But still a developer having to create a Bar with all of the exported methods 
and fields of Foo seems daunting. 

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

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 methods does Bar need to implement ? All of the methods of Foo - hard to 
> determine as a developer - easily anyway.


I don't think the problem you described exists. Let's take this one
step further:

(I'll continue using the "like" keyword for now until something better
comes up. Also, Andy is right, the syntax has problems. I'll use a
syntax similar to the one given in the official proposal)

A type template is declared like this:

type T like (X,Y,...)

This means that any one of X, Y, ... can be substituted in place of
T. In effect, it is the intersection of the operations defined on X,
Y, ...

  - If X is a primitive type such as int, any type derived from int
can be substituted.
  - If X is an interface type, any type implementing X can be substituted
  - If X is a struct type, any type implementing all the methods of X and
containing all the fields of X can be substituted

I think the above specification solves the problem Robert mentioned:
for a template using a user defined type Foo, you can substitute any
type that implements Foo.

  - If X is an array type, map type, or channel type, then any
array/map/channel type derived from X can be substituted.
That is:

  type ArrType []int

can be substituted for

  type T like []int

but not for:

  type T like []int64


Based on the above, the following should also be meaningful within templates:

   map: this would be a map template whose values are
   described by T.
   []like int : An array of int-like values


Function template is declared like this:

  func F(a, b type T like (X, Y)) T

or if T is already defined as a type template:

  func F(a,b T) T

An interface template can be defined like this:

type I interface_template {
  F(a type T like(int)) T
}

A function with an interface template in its signature becomes a template:

func F(in I)


Need to work on some real examples to see how this develops...

>
> > On Oct 18, 2018, at 8:09 AM, Burak Serdar  wrote:
> >
> >> 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 latter as I need to implement all of them in order to 
> >> be an interface.
> >>
> >> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
> >>
> >> 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.
> >
> >
> > I don't understand why that would be a problem. For a method
> > declaration of the form:
> >
> > func f(type T like (int64,float64)(a,b))
> >
> > the compiler compiles f twice: once as func f(a,b int64) and once as
> > func f(a,b float64). In general, for a function f with multiple
> > parameterized types containing multiple "like" types, f is compiled
> > for all combinations of those "like" types.
> >
> > So the compiler doesn't need to know all the operations a type has.
> >
> >>
> >> On Oct 18, 2018, at 2:20 AM, Beoran  wrote:
> >>
> >> 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:
> >>>
> >>> 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 single like for any type T, something like func
> >>> f(in T like int) (out T), then you get the type safety on return.
> >>>
> >>> Of course, this takes you back essentially to contracts, but with an
> >>> alternative declaration for the type characteristics.
> >>>
> >>> Maybe it would be possible to use like in contracts in place of the
> >>> example-base approach.
> >>>
>  On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote:
>  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

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 - hard to 
determine as a developer - easily anyway. 

> On Oct 18, 2018, at 8:09 AM, Burak Serdar  wrote:
> 
>> 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 latter as I need to implement all of them in order to 
>> be an interface.
>> 
>> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
>> 
>> 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.
> 
> 
> I don't understand why that would be a problem. For a method
> declaration of the form:
> 
> func f(type T like (int64,float64)(a,b))
> 
> the compiler compiles f twice: once as func f(a,b int64) and once as
> func f(a,b float64). In general, for a function f with multiple
> parameterized types containing multiple "like" types, f is compiled
> for all combinations of those "like" types.
> 
> So the compiler doesn't need to know all the operations a type has.
> 
>> 
>> On Oct 18, 2018, at 2:20 AM, Beoran  wrote:
>> 
>> 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:
>>> 
>>> 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 single like for any type T, something like func
>>> f(in T like int) (out T), then you get the type safety on return.
>>> 
>>> Of course, this takes you back essentially to contracts, but with an
>>> alternative declaration for the type characteristics.
>>> 
>>> Maybe it would be possible to use like in contracts in place of the
>>> example-base approach.
>>> 
 On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote:
 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 superior in that regard.
 
 But replacing contracts with “like” definitely sounds like something
 worth investigating.
 
 Andy
 
>> 
>> --
>> 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.
>> 
>> --
>> 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.

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

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 latter as I need to implement all of them in order to be 
> an interface.
>
> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
>
> 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.


I don't understand why that would be a problem. For a method
declaration of the form:

func f(type T like (int64,float64)(a,b))

the compiler compiles f twice: once as func f(a,b int64) and once as
func f(a,b float64). In general, for a function f with multiple
parameterized types containing multiple "like" types, f is compiled
for all combinations of those "like" types.

So the compiler doesn't need to know all the operations a type has.

>
> On Oct 18, 2018, at 2:20 AM, Beoran  wrote:
>
> 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:
>>
>> 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 single like for any type T, something like func
>> f(in T like int) (out T), then you get the type safety on return.
>>
>> Of course, this takes you back essentially to contracts, but with an
>> alternative declaration for the type characteristics.
>>
>> Maybe it would be possible to use like in contracts in place of the
>> example-base approach.
>>
>> On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote:
>> > 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 superior in that regard.
>> >
>> > But replacing contracts with “like” definitely sounds like something
>> > worth investigating.
>> >
>> > Andy
>> >
>
> --
> 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.
>
> --
> 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.

Re: [go-nuts] Regarding contracts

2018-10-18 Thread Beoran

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 lookup has to be done anyway.

But if it tuns out a problem then we could limit it to interfaces + complex 
native types only, which will cover operators on those native types also.


Op donderdag 18 oktober 2018 14:22:00 UTC+2 schreef Robert Engels:
>
> 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. 
>
>

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

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

> On Oct 18, 2018, at 7:21 AM, Robert Engels  wrote:
> 
> 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, at 2:20 AM, Beoran  wrote:
>> 
>> 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:
>>> 
>>> 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 single like for any type T, something like func 
>>> f(in T like int) (out T), then you get the type safety on return. 
>>> 
>>> Of course, this takes you back essentially to contracts, but with an 
>>> alternative declaration for the type characteristics. 
>>> 
>>> Maybe it would be possible to use like in contracts in place of the 
>>> example-base approach. 
>>> 
>>> On Wed, 2018-10-17 at 14:21 -0700, Andy Balholm wrote: 
>>> > 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 superior in that regard. 
>>> > 
>>> > But replacing contracts with “like” definitely sounds like something 
>>> > worth investigating. 
>>> > 
>>> > Andy 
>>> > 
>> 
>> -- 
>> 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.

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

Re: [go-nuts] Regarding contracts