Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received
Hi Patrick,
I guess it's largely a matter of taste but one of the reasons why I prefer
contracts to interfaces is precisely because you only need one contract for
the type parameters as a whole.
This keeps the type parameter section of the generic function/type
relatively brief when you have more than one parameter as well as tying
things together when you have mutually referential parameters.
Even if a contract could only refer to a single parameter, I'm also not
keen on using the contract name for that parameter which I think would be
relatively verbose. This is because the contract could have a longish name
whereas type parameters typically have short names, often a single upper
case letter.
I'm pleased you liked the simplified syntax for the contract body though :)
Alan
On Monday, October 22, 2018 at 9:16:22 PM UTC+1, Patrick Smith wrote:
>
> On Fri, Oct 19, 2018 at 10:48 AM alanfo >
> wrote:
>
>> In the light of all the feedback there's been, I've put together a
>> proposal which sticks closely to the original design and only changes what
>> most people consider needs to be changed in some way. Some recent ideas
>> which seemed plausible but which I felt had little chance of adoption have
>> been rejected.
>>
>> https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87
>>
>
> I like your simplified syntax for contracts, but I would prefer to see
> contracts specify one type at a time, rather than several. I think this
> will be easier for people to understand when type parameters are
> independent or have only one-way dependencies, and that this case will be
> much more command than the case of mutual dependencies. A suitable syntax
> might be something like
>
> contract Addable {
>
> // Note: using the contract name to represent the type being described
>
> Addable + Addable
>
> }
>
> func SliceSum[type T](s []T) T {
>
> var sum T
>
> for _, t := range s {
>
> sum = sum + t
>
> }
>
> }
>
> contract List[type T] {
>
> func (List) Len() int
>
> func (List) At(int) T
>
> }
>
> func ListSum[type L List[T], T Addable](l L) T {
>
> var sum T
>
> for n := 0; n < l.Len(); n++ {
>
> sum = sum + l.At(n)
>
> }
>
> }
>
> contract Comparable {
>
> func (Comparable) Equal(Comparable) bool
>
> }
>
> contract Hashable {
>
> Comparable // embedding
>
> func (Comparable) Hash() uint64
>
> }
>
> // An associative array using user-defined notions of equality and hashing
> type Map[type K Hashable, V] struct { ... }
>
> contract NodeType[type E] {
>
> func (NodeType) Edges() []E
>
> }
>
> contract EdgeType[type N] {
>
> func (EdgeType) Nodes() (N, N)
>
> }
>
> type Graph[type N NodeType[E], type E EdgeType[N]] struct { ... }
>
> This is somewhat like the "interfaces instead of contracts" proposals, but
> without trying to force everything into interfaces. To enforce one type per
> contract, we could have a rule that every line in a contract that is not an
> embedding of another contract must explicitly use the contract name, and
> the receiver type of a method must be either ContractName or *ContractName.
>
--
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] Proposed changes to the Go draft generics design in the light of feedback received
On Fri, Oct 19, 2018 at 10:48 AM alanfo wrote:
> In the light of all the feedback there's been, I've put together a
> proposal which sticks closely to the original design and only changes what
> most people consider needs to be changed in some way. Some recent ideas
> which seemed plausible but which I felt had little chance of adoption have
> been rejected.
>
> https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87
>
I like your simplified syntax for contracts, but I would prefer to see
contracts specify one type at a time, rather than several. I think this
will be easier for people to understand when type parameters are
independent or have only one-way dependencies, and that this case will be
much more command than the case of mutual dependencies. A suitable syntax
might be something like
contract Addable {
// Note: using the contract name to represent the type being described
Addable + Addable
}
func SliceSum[type T](s []T) T {
var sum T
for _, t := range s {
sum = sum + t
}
}
contract List[type T] {
func (List) Len() int
func (List) At(int) T
}
func ListSum[type L List[T], T Addable](l L) T {
var sum T
for n := 0; n < l.Len(); n++ {
sum = sum + l.At(n)
}
}
contract Comparable {
func (Comparable) Equal(Comparable) bool
}
contract Hashable {
Comparable // embedding
func (Comparable) Hash() uint64
}
// An associative array using user-defined notions of equality and hashing
type Map[type K Hashable, V] struct { ... }
contract NodeType[type E] {
func (NodeType) Edges() []E
}
contract EdgeType[type N] {
func (EdgeType) Nodes() (N, N)
}
type Graph[type N NodeType[E], type E EdgeType[N]] struct { ... }
This is somewhat like the "interfaces instead of contracts" proposals, but
without trying to force everything into interfaces. To enforce one type per
contract, we could have a rule that every line in a contract that is not an
embedding of another contract must explicitly use the contract name, and
the receiver type of a method must be either ContractName or *ContractName.
--
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] Proposed changes to the Go draft generics design in the light of feedback received
I've thought of some other ways of excluding 'string' so that one could
restrict an 'exclude' constraint to just numeric types.
At the expense of adding another line, you could do:
int(T)
or if (say) T * T implied T + T, T - T and T / T (which would certainly be
true) then you could use that instead of T + T.
However, if stuff were used in the contract for which there was no analog
in the function code itself, it would inevitably introduce some opacity and
anyone comparing the contract with the function, who was unaware of such
hacks, might wonder why on earth that had been done.
On the other hand, it would provide some future-proofing as one might later
introduce a function which did use the * operator and could then reuse the
same contract rather than writing another one.
Alan
On Sunday, October 21, 2018 at 12:21:46 AM UTC+1, alanfo wrote:
>
> I think it's fair to say that dealing with untyped numeric constants is
> one of the most opaque areas of the draft design and I remember thinking
> when I first read it that a clearer and more intuitive solution would have
> to be found.
>
> As far as the 'excluded types' idea is concerned, I can't really think of
> any other use cases apart from numeric ranges though it's worth noting in
> my paper I had this example:
>
> contract add1K(T) {
> T + T
> T(unsigned int)
> exclude{string, int8, uint8}(T) // can't add a thousand to these
> }
>
> where I had to explicitly exclude 'string' because it supports both the +
> operator and a conversion from any integer value.
>
> Alan
>
> On Saturday, October 20, 2018 at 11:36:02 PM UTC+1, Ian Denhardt wrote:
>>
>> Quoting alan...@gmail.com (2018-10-20 16:59:52)
>>
>> >I haven't checked them all but I did notice one example which your
>> >paper doesn't appear to cover, namely the add1K example which has
>> been
>> >a stumbling block for a lot of proposals including my own though I
>> did
>> >eventually find a way of dealing with it.
>>
>> This is a fair point. I have a couple of initial thoughts, but will
>> think about it. The contract there actually brings up my other big
>> complaint about contracts besides non-orthogonality; they are not a good
>> expression of intent. For reference:
>>
>> contract add1K(x T) {
>> x = 1000
>> x + x
>> }
>>
>> While it's possible to piece together what has to be true about a type
>> to satisfy this contract, it's really not obvious at the outset what the
>> point of it is. Looking at the contracts in the draft design, I feel
>> like I would generally speaking have to jump through mental hoops to
>> understand what concepts were being expressed by a given contract.
>>
>> >1. If interfaces were used, a way would need to be devised to
>> express
>> >that a type supports a particular operator or operators. To be
>> >compatible with methods something like the following seems best:
>> >� � � +(T, T) T
>> >However, this would mean that someone writing an interface to be
>> used
>> >for generic constraint purposes would have to know and write out the
>> >signature for each operator used.
>>
>> This seems like a relatively minor problem. Eric sketched out a possible
>> syntax, here is another:
>>
>> type Ordered[type T] interface {
>> operator < (other T) bool
>> }
>>
>> func (MyType) operator < (other T) bool { ... }
>>
>> (where `operator` becomes a keyword)
>>
>> I'm not convinced having to remember the type signatures is a
>> problem -- for most operators they are fairly self-evident, and we
>> already have to do this for a wide range of interfaces in the standard
>> library. I think adding a whole new concept to the language is a much
>> bigger cognitive load.
>>
>> >2. As your own paper clearly shows, it is possible to deal with
>> >multiple type parameters which refer to each other using an
>> interface
>> >based approach and even the draft design paper itself admits this is
>> >possible. However, it seems to me to be less elegant than a contract
>> >based approach.
>> >An interface can only express the methods which a single type needs
>> to
>> >satisfy and so a separate interface is needed for each mutually
>> >referential type parameter. A contract on the other hand doesn't
>> have
>> >this constraint and, indeed, the type parameters as a group have to
>> >satisfy a single contract which, to my mind, ties the whole thing
>> >together in a much nicer way.
>>
>> I actually have a fairly clear design in my head for adding associated
>> types to interfaces, which my current design generalizes to cleanly, but
>> I left it out because I'm not convinced that this kind of thing is
>> common enough to be worth optimizing for. My gut is that this kind of
>> contract will be the exception, rather than the rule, and I would err on
>> the side of leaving things out. I think
Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received
I think it's fair to say that dealing with untyped numeric constants is one
of the most opaque areas of the draft design and I remember thinking when I
first read it that a clearer and more intuitive solution would have to be
found.
As far as the 'excluded types' idea is concerned, I can't really think of
any other use cases apart from numeric ranges though it's worth noting in
my paper I had this example:
contract add1K(T) {
T + T
T(unsigned int)
exclude{string, int8, uint8}(T) // can't add a thousand to these
}
where I had to explicitly exclude 'string' because it supports both the +
operator and a conversion from any integer value.
Alan
On Saturday, October 20, 2018 at 11:36:02 PM UTC+1, Ian Denhardt wrote:
>
> Quoting alan...@gmail.com (2018-10-20 16:59:52)
>
> >I haven't checked them all but I did notice one example which your
> >paper doesn't appear to cover, namely the add1K example which has
> been
> >a stumbling block for a lot of proposals including my own though I
> did
> >eventually find a way of dealing with it.
>
> This is a fair point. I have a couple of initial thoughts, but will
> think about it. The contract there actually brings up my other big
> complaint about contracts besides non-orthogonality; they are not a good
> expression of intent. For reference:
>
> contract add1K(x T) {
> x = 1000
> x + x
> }
>
> While it's possible to piece together what has to be true about a type
> to satisfy this contract, it's really not obvious at the outset what the
> point of it is. Looking at the contracts in the draft design, I feel
> like I would generally speaking have to jump through mental hoops to
> understand what concepts were being expressed by a given contract.
>
> >1. If interfaces were used, a way would need to be devised to express
> >that a type supports a particular operator or operators. To be
> >compatible with methods something like the following seems best:
> >� � � +(T, T) T
> >However, this would mean that someone writing an interface to be used
> >for generic constraint purposes would have to know and write out the
> >signature for each operator used.
>
> This seems like a relatively minor problem. Eric sketched out a possible
> syntax, here is another:
>
> type Ordered[type T] interface {
> operator < (other T) bool
> }
>
> func (MyType) operator < (other T) bool { ... }
>
> (where `operator` becomes a keyword)
>
> I'm not convinced having to remember the type signatures is a
> problem -- for most operators they are fairly self-evident, and we
> already have to do this for a wide range of interfaces in the standard
> library. I think adding a whole new concept to the language is a much
> bigger cognitive load.
>
> >2. As your own paper clearly shows, it is possible to deal with
> >multiple type parameters which refer to each other using an interface
> >based approach and even the draft design paper itself admits this is
> >possible. However, it seems to me to be less elegant than a contract
> >based approach.
> >An interface can only express the methods which a single type needs
> to
> >satisfy and so a separate interface is needed for each mutually
> >referential type parameter. A contract on the other hand doesn't have
> >this constraint and, indeed, the type parameters as a group have to
> >satisfy a single contract which, to my mind, ties the whole thing
> >together in a much nicer way.
>
> I actually have a fairly clear design in my head for adding associated
> types to interfaces, which my current design generalizes to cleanly, but
> I left it out because I'm not convinced that this kind of thing is
> common enough to be worth optimizing for. My gut is that this kind of
> contract will be the exception, rather than the rule, and I would err on
> the side of leaving things out. I think it will be common enough that
> we'll want it to be *doable*, but I'm not convinced being a little
> more concise is worth adding conceptual complexity.
>
> >3. Interfaces don't deal with fields at all and so would need to be
> >extended to cope with a struct constraint. To be fair, some people
> have
> >questioned whether such constraints are important enough to be
> catered
> >for at all but the draft design does nevertheless deal with them and
> so
> >does my own paper.
>
> There's an issue on Github that Ian T ha referred to in several threads
> re: adding fields to interfaces, which has been rejected. I think
> the arguments against it all also apply to using contracts to do the
> same thing (see also my complaints about expressing intent) I'm not
> convinced that the fact that contracts can express this is a good thing.
>
> >4. There are a number of minor (though tricky) issues which
> interfaces
> >can't currently deal with but
Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received
Quoting alan.f...@gmail.com (2018-10-20 16:59:52)
>I haven't checked them all but I did notice one example which your
>paper doesn't appear to cover, namely the add1K example which has been
>a stumbling block for a lot of proposals including my own though I did
>eventually find a way of dealing with it.
This is a fair point. I have a couple of initial thoughts, but will
think about it. The contract there actually brings up my other big
complaint about contracts besides non-orthogonality; they are not a good
expression of intent. For reference:
contract add1K(x T) {
x = 1000
x + x
}
While it's possible to piece together what has to be true about a type
to satisfy this contract, it's really not obvious at the outset what the
point of it is. Looking at the contracts in the draft design, I feel
like I would generally speaking have to jump through mental hoops to
understand what concepts were being expressed by a given contract.
>1. If interfaces were used, a way would need to be devised to express
>that a type supports a particular operator or operators. To be
>compatible with methods something like the following seems best:
>� � � +(T, T) T
>However, this would mean that someone writing an interface to be used
>for generic constraint purposes would have to know and write out the
>signature for each operator used.
This seems like a relatively minor problem. Eric sketched out a possible
syntax, here is another:
type Ordered[type T] interface {
operator < (other T) bool
}
func (MyType) operator < (other T) bool { ... }
(where `operator` becomes a keyword)
I'm not convinced having to remember the type signatures is a
problem -- for most operators they are fairly self-evident, and we
already have to do this for a wide range of interfaces in the standard
library. I think adding a whole new concept to the language is a much
bigger cognitive load.
>2. As your own paper clearly shows, it is possible to deal with
>multiple type parameters which refer to each other using an interface
>based approach and even the draft design paper itself admits this is
>possible. However, it seems to me to be less elegant than a contract
>based approach.
>An interface can only express the methods which a single type needs to
>satisfy and so a separate interface is needed for each mutually
>referential type parameter. A contract on the other hand doesn't have
>this constraint and, indeed, the type parameters as a group have to
>satisfy a single contract which, to my mind, ties the whole thing
>together in a much nicer way.
I actually have a fairly clear design in my head for adding associated
types to interfaces, which my current design generalizes to cleanly, but
I left it out because I'm not convinced that this kind of thing is
common enough to be worth optimizing for. My gut is that this kind of
contract will be the exception, rather than the rule, and I would err on
the side of leaving things out. I think it will be common enough that
we'll want it to be *doable*, but I'm not convinced being a little
more concise is worth adding conceptual complexity.
>3. Interfaces don't deal with fields at all and so would need to be
>extended to cope with a struct constraint. To be fair, some people have
>questioned whether such constraints are important enough to be catered
>for at all but the draft design does nevertheless deal with them and so
>does my own paper.
There's an issue on Github that Ian T ha referred to in several threads
re: adding fields to interfaces, which has been rejected. I think
the arguments against it all also apply to using contracts to do the
same thing (see also my complaints about expressing intent) I'm not
convinced that the fact that contracts can express this is a good thing.
>4. There are a number of minor (though tricky) issues which interfaces
>can't currently deal with but contracts can and which I listed in my
>paper. To take one in particular - excluded types - it is difficult to
>see how interfaces could deal with something like that though, as it's
>a novel idea anyway, perhaps some other way could be found to achieve
>the same result.
Are there other use cases for this besides the numeric range issue? If
not I think this falls into the same bucket as the add1k example, and I
will have to think about it.
>5. Finally - and you might think this is a bit silly - but there are a
>lot of people who don't like the idea of generics at all and will
>probably try to avoid them if they can. Now, hopefully they will change
>their minds when they see how convenient generics can be to use.
>Nevertheless, I still think it's important to cater for such people and
>leaving interfaces as they are and confining the generic stuff to
>contracts should help here.
My proposal doesn't really change interfaces
Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received
Ian D, I'm sorry that we had a mis-understanding regarding the introduction to my paper but I hope you now understand why I made the remarks I did. To turn to the technical issues. I haven't checked them all but I did notice one example which your paper doesn't appear to cover, namely the add1K example which has been a stumbling block for a lot of proposals including my own though I did eventually find a way of dealing with it. Perhaps I could go through the reasons why I have concluded that it is better to stick with contracts rather than interfaces even though the two approaches are not completely orthogonal: 1. If interfaces were used, a way would need to be devised to express that a type supports a particular operator or operators. To be compatible with methods something like the following seems best: +(T, T) T However, this would mean that someone writing an interface to be used for generic constraint purposes would have to know and write out the signature for each operator used. In contrast, when writing a contract, it doesn't matter whether the syntax we use is compatible with methods or not as it's a new concept. So writing something like T + T is fine and the writer doesn't even need to know what the signature of '+' is. How to express operators was, of course, identified in the draft design paper itself as a difficulty with interfaces and it was mentioned that there was a subtlety with the == operator which returns an untyped bool rather than a typed bool. 2. As your own paper clearly shows, it is possible to deal with multiple type parameters which refer to each other using an interface based approach and even the draft design paper itself admits this is possible. However, it seems to me to be less elegant than a contract based approach. An interface can only express the methods which a single type needs to satisfy and so a separate interface is needed for each mutually referential type parameter. A contract on the other hand doesn't have this constraint and, indeed, the type parameters as a group have to satisfy a single contract which, to my mind, ties the whole thing together in a much nicer way. 3. Interfaces don't deal with fields at all and so would need to be extended to cope with a struct constraint. To be fair, some people have questioned whether such constraints are important enough to be catered for at all but the draft design does nevertheless deal with them and so does my own paper. 4. There are a number of minor (though tricky) issues which interfaces can't currently deal with but contracts can and which I listed in my paper. To take one in particular - excluded types - it is difficult to see how interfaces could deal with something like that though, as it's a novel idea anyway, perhaps some other way could be found to achieve the same result. 5. Finally - and you might think this is a bit silly - but there are a lot of people who don't like the idea of generics at all and will probably try to avoid them if they can. Now, hopefully they will change their minds when they see how convenient generics can be to use. Nevertheless, I still think it's important to cater for such people and leaving interfaces as they are and confining the generic stuff to contracts should help here. On your last point about unification of generic methods (or the lack of it without operator overloading), I suspect that the Go team will prefer your option 1 (two generic methods, one for the built-ins and the other for types which satisfy an equivalent interface) as far as the standard library is concerned - at least where slices and maps are concerned. Option 3 (operator version only) is clearly an incomplete solution and I doubt whether they'd be keen on option 2 either (method based version only) because wrapping and unwrapping non-scalar types is such a pain. Alan On Saturday, October 20, 2018 at 4:31:09 PM UTC+1, Ian Denhardt wrote: > > Quoting alan...@gmail.com (2018-10-19 16:19:36) > >Ian D, > >The introduction is certainly not intended to be insulting to those > who > >have put serious thought into the problem. If it were, then I'd be > >insulting myself as I've put serious thought into at least two other > >proposals which are nothing like the current one! > > I apologize if I've interpreted things less charitably that I should > have. > > >It's simply a realization I've come to that there's a lot of mileage > in > >the original draft which is the culmination of what two very smart > >people have been working on for years and should not therefore be > >dismissed too readily. > > I certainly agree with this. My own proposal left type parameters > basically untouched, though I have specific criticisms I and many others > have made elsewhere regarding contracts. > > The original draft was indeed *very* thorough, and provided many useful > motivating examples that act as some tests
Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received
Quoting alan.f...@gmail.com (2018-10-19 16:19:36) >Ian D, >The introduction is certainly not intended to be insulting to those who >have put serious thought into the problem. If it were, then I'd be >insulting myself as I've put serious thought into at least two other >proposals which are nothing like the current one! I apologize if I've interpreted things less charitably that I should have. >It's simply a realization I've come to that there's a lot of mileage in >the original draft which is the culmination of what two very smart >people have been working on for years and should not therefore be >dismissed too readily. I certainly agree with this. My own proposal left type parameters basically untouched, though I have specific criticisms I and many others have made elsewhere regarding contracts. The original draft was indeed *very* thorough, and provided many useful motivating examples that act as some tests for alternatives. The discarded ideas section also provides a justification for each. (This makes it very easy to see that your own square brackets suggestion handles the original objection to this idea, which brings it back into the realm of discussion). On to more technical issues. --- Your post mentions: > However, the problem is that contracts can do a lot more things than > interfaces currently can and it is not easy to extend the latter to > meet this shortfall. My own proposal addressed every single example in the examples section of the draft design, as well as the graph example. Can you describe what you think is missing? It's been linked before, but for reference: https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d (You mention that the graph example is "awkward" to express. This is a bit subjective, but the thing I feel more strongly about is that a single slightly subtle encoding does not justify adding an entirely new non-orthogonal construct to the language). > Stepping back a little, is it really such a big deal to have two > functions for anything involving operators - one for the relevant > built-ins and another for user-defined types which satisfy an equivalent > interface? I talked about this in my original proposal, which left out operator overloading, curious to your thoughts: https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#operators -- 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] Proposed changes to the Go draft generics design in the light of feedback received
alan.f...@gmail.com : > I also don't think that Eric was being disrespectful to Ian LT and Robert. > He simply has a profound dislike for the draft generics design and believes > in expressing himself forcibly and at times, comically :) True dat! Your grasp of this nuance is appreciated. -- 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] Proposed changes to the Go draft generics design in the light of feedback received
Ian Denhardt : > Second, I agree with Tristan that Eric's sibling comment is a bit sharp; > let's be careful to keep this civil, as it's clear that some of us are > feeling a bit tense. I was serious when I said I meant no insult, and apologize to any who felt insulted. > Ultimately however I agree with Eric that the proposal focuses on > relatively superficial issues. > > That said I do like the idea of using [type T]; while my own focus has > been on semantics, like many I agree the existing syntax is not very > ergonomic. I will concur with that, too. I would prefer a better solution to the deep problems. Failing that I would prefer a solution syntactically marking the generic formals in the regular signature to a prefix clause. But yes, () to [] would be an improvement in the prefix-clause syntax - more visual distinctness. -- 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] Proposed changes to the Go draft generics design in the light of feedback received
Ian D, The introduction is certainly not intended to be insulting to those who have put serious thought into the problem. If it were, then I'd be insulting myself as I've put serious thought into at least two other proposals which are nothing like the current one! It's simply a realization I've come to that there's a lot of mileage in the original draft which is the culmination of what two very smart people have been working on for years and should not therefore be dismissed too readily. Sure, it's not perfect and that's why I have suggested some changes which no doubt are still far from perfect! I don't think I have dismissed anything without providing some justification for it. FWIW I personally would like to see some form of operator overloading even though I acknowledge it has a lot of problems and we're unlikely to see it. I also don't think that Eric was being disrespectful to Ian LT and Robert. He simply has a profound dislike for the draft generics design and believes in expressing himself forcibly and at times, comically :) Alan On Friday, October 19, 2018 at 8:49:31 PM UTC+1, Ian Denhardt wrote: > First, I find the introduction to this condescending; it amounts to "the > Go developers know what they're doing, stop questioning them plebians!" > It is phrased more politely, but the content is basically there. This > is: > > 1. Insulting to those of us who also have put serious thought >into the problem, and perhaps also have knowledge and experience >in this area of programming language design. > 2. Largely missing the point of the draft designs, which were meant >as a starting point for discussion; the Go developers were >explicitly soliciting feedback. > 3. Ignores the fact that most of us have been raising specific >critiques of the design. While our criticisms are based on >substance, you dismiss them entirely without providing a >justification other than "Ian and Robert know what they're >doing." > > Second, I agree with Tristan that Eric's sibling comment is a bit sharp; > let's be careful to keep this civil, as it's clear that some of us are > feeling a bit tense. > > Ultimately however I agree with Eric that the proposal focuses on > relatively superficial issues. > > That said I do like the idea of using [type T]; while my own focus has > been on semantics, like many I agree the existing syntax is not very > ergonomic. > > Quoting alanfo (2018-10-19 13:48:20) > >My head has been spinning lately after reading the various generic > >counter-proposals and suddenly the original draft design seems a lot > >more attractive than it did :) > >In the light of all the feedback there's been, I've put together a > >proposal which sticks closely to the original design and only changes > >what most people consider needs to be changed in some way. Some > recent > >ideas which seemed plausible but which I felt had little chance of > >adoption have been rejected. > >It's not too long so give it a read and see what you think. > >Here's the link: > >[1]https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87 > >Alan > -- 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] Proposed changes to the Go draft generics design in the light of feedback received
I think we need to focus this thread on comments just about alanfo's suggestion. Let's not start debating how to debate. And, of course, let's remember the code of conduct: https://golang.org/conduct . Thanks. 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] Proposed changes to the Go draft generics design in the light of feedback received
First, I find the introduction to this condescending; it amounts to "the Go developers know what they're doing, stop questioning them plebians!" It is phrased more politely, but the content is basically there. This is: 1. Insulting to those of us who also have put serious thought into the problem, and perhaps also have knowledge and experience in this area of programming language design. 2. Largely missing the point of the draft designs, which were meant as a starting point for discussion; the Go developers were explicitly soliciting feedback. 3. Ignores the fact that most of us have been raising specific critiques of the design. While our criticisms are based on substance, you dismiss them entirely without providing a justification other than "Ian and Robert know what they're doing." Second, I agree with Tristan that Eric's sibling comment is a bit sharp; let's be careful to keep this civil, as it's clear that some of us are feeling a bit tense. Ultimately however I agree with Eric that the proposal focuses on relatively superficial issues. That said I do like the idea of using [type T]; while my own focus has been on semantics, like many I agree the existing syntax is not very ergonomic. Quoting alanfo (2018-10-19 13:48:20) >My head has been spinning lately after reading the various generic >counter-proposals and suddenly the original draft design seems a lot >more attractive than it did :) >In the light of all the feedback there's been, I've put together a >proposal which sticks closely to the original design and only changes >what most people consider needs to be changed in some way. Some recent >ideas which seemed plausible but which I felt had little chance of >adoption have been rejected. >It's not too long so give it a read and see what you think. >Here's the link: >[1]https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87 >Alan > >-- >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 [2]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [3]https://groups.google.com/d/optout. > > Verweise > >1. https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87 >2. mailto:golang-nuts+unsubscr...@googlegroups.com >3. 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.
