Re: [go-nuts] Re: Generics as builtin typeclasses

On Tue, Sep 11, 2018 at 4:39 PM Larry Clapp wrote: > Directly accessing a field in a generic struct might be *rare*, but it > seems like it shouldn't be *impossible*. > I think it would be better if it is, but if it introduces additional cost, that cost needs to be weighed against the benefit

Re: [go-nuts] Re: Generics as builtin typeclasses

On Tuesday, September 11, 2018 at 9:24:56 AM UTC-4, Larry Clapp wrote: > > This question frankly struck me odd, given the context. To paraphrase: > "Do I have examples of where accessing a field in a generic struct type > might be useful?" I kind of assumed that, hip-deep as we are in a >

Re: [go-nuts] Re: Generics as builtin typeclasses

Hi, Axel, You're certainly right: we can *get around* not having access to specific fields in generic functions. And my MinKeys example may've been suboptimal, or not a great example to begin with. And the fact that you have to hard-code the field name(s) to be accessed in the contract also

Re: [go-nuts] Re: Generics as builtin typeclasses

Hi Larry, On Tue, Sep 11, 2018 at 3:25 PM Larry Clapp wrote: > This question frankly struck me odd, given the context. To paraphrase: > "Do I have examples of where accessing a field in a generic struct type > might be useful?" I kind of assumed that, hip-deep as we are in a > discussion of

Re: [go-nuts] Re: Generics as builtin typeclasses

This question frankly struck me odd, given the context. To paraphrase: "Do I have examples of where accessing a field in a generic struct type might be useful?" I kind of assumed that, hip-deep as we are in a discussion of generic functions, that such a thing might be understood? I mean,

Re: [go-nuts] Re: Generics as builtin typeclasses

A lot of those just pick out a subset of built-in types (or a type whose underlying type is a built-in). boolean is an obvious example, but arith is just all the numeric types. We already have names for those: int, bool, etc. We just need to combine them with "or". E.g. bool is

Re: [go-nuts] Re: Generics as builtin typeclasses

Do you have actual examples of how that would be useful to you? On Monday, September 10, 2018 at 9:45:12 PM UTC-4, Larry Clapp wrote: > > The conversation here is deep, and I haven't followed all of it. I > *think* y'all are discussing some different contract system than the > actual draft

Re: [go-nuts] Re: Generics as builtin typeclasses

Under the latest version of my own proposal, you'd do it something like this: contract mycont(T) { // ensure T has a field F of whatever type is required (FieldType say) typecheck(T, "struct{F FieldType}") } // sample generic function which takes one parameter and has no return type,

Re: [go-nuts] Re: Generics as builtin typeclasses

The conversation here is deep, and I haven't followed all of it. I *think* y'all are discussing some different contract system than the actual draft proposal? If that's the case: You can't express field-accessors, which is an actual, inarguable reduction > in power that I'm perfectly fine

Re: [go-nuts] Re: Generics as builtin typeclasses

The unambiguous cases aren't ambiguous of course. It's the ambiguous cases I'm concerned about :) My post and this thread contain a bunch of those. They are mostly growing out of builtin functions and things like `range` statements and index-expressions. You can translate all of my

Re: [go-nuts] Re: Generics as builtin typeclasses

Don't worry, I still got the point :) And already yielded that treating pseudo-interfaces as types won't work and that it requires some polish on phrasing :) On Tue, Sep 11, 2018 at 1:16 AM Jonathan Amsterdam wrote: > I'm wrong about `==` here, because it's defined for interface values. >

Re: [go-nuts] Re: Generics as builtin typeclasses

On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote: > > On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam > wrote: > >> FWIW, I think Ian's criticism of not wanting a list of new identifiers to >>> express operator constraints is fair. It is a genuine roadblock to c) and

Re: [go-nuts] Re: Generics as builtin typeclasses

I'm wrong about `==` here, because it's defined for interface values. `comparable` could be an interface. But it won't work for other operators like `<` or `+`. On Sunday, September 9, 2018 at 2:49:26 PM UTC-4, Jonathan Amsterdam wrote: > > FWIW, in my pseudo-interface description >>

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam wrote: > FWIW, I think Ian's criticism of not wanting a list of new identifiers to >> express operator constraints is fair. It is a genuine roadblock to c) and >> if we're dead set of setting that as a baseline requirement, I agree that a >>

Re: [go-nuts] Re: Generics as builtin typeclasses

> > FWIW, I think Ian's criticism of not wanting a list of new identifiers to > express operator constraints is fair. It is a genuine roadblock to c) and > if we're dead set of setting that as a baseline requirement, I agree that a > declarative/interface-based approach won't work. > I don't

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 2:03 PM Jonathan Amsterdam wrote: > You and many others have tried to replace contracts with interfaces. > Almost, but not quite. I and others have tried to replace contracts with *something*. Preferably something declarative. ISMT interfaces fit the bill *pretty well*.

Re: [go-nuts] Re: Generics as builtin typeclasses

Sorry, the proposed new keyword is 'typecheck' not 'keycheck'. Alan On Monday, September 10, 2018 at 6:01:12 PM UTC+1, alanfo wrote: > > I've revised my feedback on this topic yet again in the light of > criticisms made by Ian which I thought were justified. > > Briefly, I'm now proposing that

Re: [go-nuts] Re: Generics as builtin typeclasses

I've revised my feedback on this topic yet again in the light of criticisms made by Ian which I thought were justified. Briefly, I'm now proposing that there should only be one additional contextual keyword 'keycheck' though a number of other changes have been made to fit in with this. The

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 12:46 AM Ian Lance Taylor wrote: > To me contracts aren't implicit or roundabout at all, at least not > when it comes to which types they permit. They are very direct and > straightforward, and they really could not be simpler. But clearly > many people disagree. Perhaps

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, September 9, 2018 at 3:52:24 AM UTC-4, Ian Lance Taylor wrote: > > On Sat, Sep 8, 2018 at 7:53 PM, Jonathan Amsterdam > > wrote: > >> When is it important to not just express what operations are > >> required for a type, but also to try to rule out some types? > > > > > I

Re: [go-nuts] Re: Generics as builtin typeclasses

You're right, I apologize. It not only wasn't nice, it also was an ineffective way to make my point. So let me try to make that point as clearly as I can. You and many others have tried to replace contracts with interfaces. But if generics are to have operator constraints like T == T, then

Re: [go-nuts] Re: Generics as builtin typeclasses

Sorry to have duplicated your idea, rog, particularly as I did read your feedback what now seems "years" ago! Frankly, there has been so much feedback and so may lengthy threads on this topic that I'm losing track of what's been suggested and by whom :( Alan On Monday, September 10, 2018 at

Re: [go-nuts] Re: Generics as builtin typeclasses

On 10 September 2018 at 09:46, wrote: > I don't know whether anyone has suggested this before but why not disallow > direct method calls on a contract's type arguments altogether and force > people to use interfaces instead? I suggested that here FWIW:

[go-nuts] Re: Generics as builtin typeclasses

In the draft design paper it says: "There are a few aspects to a method call that can not be shown in a simple assignment statement like the ones shown above. There is no way to specify that a method does not return any values. There is no way to specify that a method takes variadic

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 12:47 AM Randall O'Reilly wrote: > WRT the objection of introducing a bunch of new keywords to explicitly > specify what is otherwise indirectly specified by contracts, there is > already a full explicit list of such things in the reflect.Kind type. > Could we not just

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, 9 September 2018 18:46:55 UTC+2, Eric Raymond wrote: > > > This morning, casting about for a "how to do it right" example, I > invented a way to implement sum types using composition and some > simple field-resolution rules. Zero new syntax. If I'm feeling brave when > my Python

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, 9 September 2018 15:50:17 UTC+2, Robert Engels wrote: > > Which is why I believe this can happen with existing interfaces and > compiler magic. (along with my other proposal regarding carrying the > concrete type in slices). > > I think this is an admirable objective, if it can be

Re: [go-nuts] Re: Generics as builtin typeclasses

The implicit nature of contracts seems like a major sticking point. If you are writing something like 1 << t to express “unsigned integer” then it seems like it would obviously be more explicit to directly state “unsigned integer”. contracts look really elegant, powerful, and well-defined

Re: [go-nuts] Re: Generics as builtin typeclasses

> > I get that it avoids introducing those properties directly into the > > language but it also locks the language into those properties. You can > > never change https://github.com/golang/go/issues/19113 after > > introducing contracts because there could be a contract somewhere that > > uses 1

Re: [go-nuts] Re: Generics as builtin typeclasses

I don't think saying that is is productive. contracts are more than just "identifiers used as constraints", they are also a syntactic construct to specify those. I specifically don't allow that and that's the whole point I'm making. So this doesn't seem like a particularly nice way to have a

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 11:08 PM Jonathan Amsterdam wrote: > func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to >> Node) []Edge >> > > I don't think this syntax is valid according to the draft design, or your > blog post. Node and Edge are used before they are declared. > I

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote: > > On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam > wrote: > >> The problem is that this program seems to type-check, but it is invalid. >> The == operator is specified to work on operands of the same type, and it >> is

Re: [go-nuts] Re: Generics as builtin typeclasses

> > > func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to > Node) []Edge > I don't think this syntax is valid according to the draft design, or your blog post. Node and Edge are used before they are declared. Maybe func ShortestPath(type Node, Edge, G Graph(Node,

Re: [go-nuts] Re: Generics as builtin typeclasses

This is where the “compiler magic” happens… the interfaces are checked internally - if the compiler can find a method where the receiver type matches the parameter type, and it returns a value which is the receiver type, it can use the + operator on it, if not it is a compiler error. As others

Re: [go-nuts] Re: Generics as builtin typeclasses

The reason I'm trying to keep things separate (at least in my head) is that it allows to split the implementations. For example, it would be possible to first add type-parameters, then add constraints (however) and then add a way to allow constraints enabling operators (however). Each step would

Re: [go-nuts] Re: Generics as builtin typeclasses

Oh, I actually wanted to add something about this: Whether or not this will *actually* end up being static or dynamic dispatch is, AIUI, intentionally left open in the proposal. The current thinking, AIUI, is

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 12:18 PM, 'Axel Wagner' via golang-nuts wrote: > > I disagree with the premise that we need operators for generics - when I > think of "generics", I usually think of "type-safe, constrained, parametric > polymorphism". Without operators, generic code would still fulfill

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam wrote: > The problem is that this program seems to type-check, but it is invalid. > The == operator is specified to work on operands of the same type, and it > is being used on operands of different types. > Good point. I have to think about it.

Re: [go-nuts] Re: Generics as builtin typeclasses

True. You can get static dispatch by func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to Node) []Edge On Sun, Sep 9, 2018 at 8:21 PM Jonathan Amsterdam wrote: > >> FWIW, in my pseudo-interface description >> , >> >

Re: [go-nuts] Re: Generics as builtin typeclasses

On Saturday, September 8, 2018 at 11:58:46 PM UTC-4, Robert Engels wrote: > > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as > methods, e.g. operator + is > > pseudo generic interface - not really

Re: [go-nuts] Re: Generics as builtin typeclasses

> > FWIW, in my pseudo-interface description > ... > You mention that comparable is a pseudo-interface, which means the type supports the == and != operators. You say that comparable and the other pseudo-interfaces are types. So

Re: [go-nuts] Re: Generics as builtin typeclasses

> > > FWIW, in my pseudo-interface description > , > Unrelated to this particular issue, but since you link to your blog post, I just want to mention that in your graph example, func ShortestPath(type Node, Edge) (g Graph(Node,

Re: [go-nuts] Re: Generics as builtin typeclasses

robert engels : > Which is why I believe this can happen with existing interfaces and compiler > magic. (along with my other proposal regarding carrying the concrete type in > slices). > > You can do operator overloading and type conversion with interfaces. > (although not a big fan of

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 6:51 AM, Ignazio Di Napoli wrote: > > Thank you, I see your point. This is less powerful than contracts, but Go > proved me that less is more, as long as it is enough. My point is: do we > really need a so powerful version of generics or maybe operators and > interfaces

Re: [go-nuts] Re: Generics as builtin typeclasses

Thank you, I see your point. This is less powerful than contracts, but Go proved me that less is more, as long as it is enough. My point is: do we really need a so powerful version of generics or maybe operators and interfaces are enough? For the many keywords added and to manage conversions,

Re: [go-nuts] Re: Generics as builtin typeclasses

Which is why I believe this can happen with existing interfaces and compiler magic. (along with my other proposal regarding carrying the concrete type in slices). You can do operator overloading and type conversion with interfaces. (although not a big fan of operator overloading…) Method

Re: [go-nuts] Re: Generics as builtin typeclasses

Ian Lance Taylor : > As I've said before, I would very much like to avoid adding many > different names to the language. I've been staying out of the forward-looking language-design discussions so far, and intend to keep pretty quiet on that front until I feel my grasp on idomatic Go as she is

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 9:35 AM Ian Lance Taylor wrote: > As I've said before, I would very much like to avoid adding many > different names to the language. Also, there are many different cases > to handle. Consider type conversions, for example; how do you express > that you want to have two

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sat, Sep 8, 2018 at 7:53 PM, Jonathan Amsterdam wrote: >> When is it important to not just express what operations are >> required for a type, but also to try to rule out some types? > > > I think the short answer is: numeric code. That's when one thinks about > which types make sense for an

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sat, Sep 8, 2018 at 6:10 PM, Rob Pike wrote: > "A contract is a compile-time description of which types are permitted > for a polymorphic function or type." > > No, it's not. It's a collection of statement-like operations that must be > legally compilable, under restricted circumstances, by

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sat, Sep 8, 2018 at 2:23 PM, jimmy frasche wrote: > > I get that it avoids introducing those properties directly into the > language but it also locks the language into those properties. You can > never change https://github.com/golang/go/issues/19113 after > introducing contracts because

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sat, Sep 8, 2018 at 3:47 PM, Ignazio Di Napoli wrote: > I'd really like to read a reply to Lucio's argument about operator > overloading. > > Once we define that: > 1. a 2. a==b is the same as a.Equals(b); > 3. the other comparaison operators are defined using these two (e.g.: a>b is >

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, 9 September 2018 05:58:46 UTC+2, Robert Engels wrote: > > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as > methods, e.g. operator + is > > The point is that without "intrinsic generics"

Re: [go-nuts] Re: Generics as builtin typeclasses

For the math operator, since Go already doesn’t do automatic numeric conversions, all of the operators are almost trivially implemented as methods, e.g. operator + is pseudo generic interface - not really required type PlusOperator interface { Plus(A) A } and given type MyStruct

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, 9 September 2018 04:53:00 UTC+2, Jonathan Amsterdam wrote: > > When is it important to not just express what operations are >> required for a type, but also to try to rule out some types? >> > > I think the short answer is: numeric code. That's when one thinks about > which types

Re: [go-nuts] Re: Generics as builtin typeclasses

I don't think Go will add operator overloading, even if it simplifies generics. Go has a core principle that doesn't get written down very much: syntax is hard-coded. If you see a piece of syntax in Go, it will never execute user code. (The obvious exception, of course, is a function call.)

Re: [go-nuts] Re: Generics as builtin typeclasses

> > When is it important to not just express what operations are > required for a type, but also to try to rule out some types? > I think the short answer is: numeric code. That's when one thinks about which types make sense for an algorithm, not just which operations. I'm not exactly sure

Re: [go-nuts] Re: Generics as builtin typeclasses

"A contract is a compile-time description of which types are permitted for a polymorphic function or type." No, it's not. It's a collection of statement-like operations that must be legally compilable, under restricted circumstances, by the type at the point of instantiation, plus some special

Re: [go-nuts] Re: Generics as builtin typeclasses

Ps: as for point 4, we'd maybe need b and c to be integers, and also a SetIndex method. We'd also need a Key, SetKey and DeleteKey to mimic map operators. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Re: Generics as builtin typeclasses

I'd really like to read a reply to Lucio's argument about operator overloading. Once we define that: 1. ab is !a.Less(b) && !a.Equals(b)); 4. a.Index(b) is the same as a[b] and a.Index2(b, c) is the same as a[b:c]; 5. maybe some more? Would we really need contracts and the added complexity in

Re: [go-nuts] Re: Generics as builtin typeclasses

"Any unsigned number" would allow generic versions of the math/bits functions, though they'd have to dispatch on unsafe.Sizeof internally, as a type switch would miss type Uint uint But that would presumably be DCE'd if specialized. Allowing more types than intended isn't always bad. If I have

Re: [go-nuts] Re: Generics as builtin typeclasses

OK, fair enough, but the only way you could have a standard package on those lines without the compiler doing more inference would be to list expressions for every single operator or conversion that the relevant types support. That should be doable but I'm not sure whether a particular

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sat, Sep 8, 2018 at 6:29 AM, alanfo wrote: > > As it's clear now that Ian wants to stick with 'full-blooded' contracts if > it can be made to work, I've been trying to think of ways to make them > easier to work with and to solve some of the issues they currently have. > > Reading through the

Re: [go-nuts] Re: Generics as builtin typeclasses

As it's clear now that Ian wants to stick with 'full-blooded' contracts if it can be made to work, I've been trying to think of ways to make them easier to work with and to solve some of the issues they currently have. Reading through the draft for the umpteenth time, one point that

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sat, Sep 8, 2018 at 5:54 AM, Wojciech S. Czarnecki wrote: > On Sat, 8 Sep 2018 03:59:45 -0700 > Ian Lance Taylor wrote: > >> Why is it useful to say "this polymorphic function may >> only be instantiated with unsigned integer types?" > > E.g. because an algorithm needs this constraint. OK,

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 9:19 PM, Lucio wrote: > > PS: Maybe I should add a thought to clarify what I'm imagining. Am I > mistaken in my belief that user-defined methods and functions are much less > likely to appear within contracts than operators on intrinsic types? And > that the "generic"

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 5:29 PM, Rob Pike wrote: > > Would this work? > > contract unsigned(u T) { > 1 << u > } > > It's another infelicitous horror, but I believe it exploits the only place > in the language where an unsigned integer is required. Yes, that would also work (pace issue #19113).

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 5:28 PM, Rob Pike wrote: > > contract unsigned(v T) { > // Require T to be an integer type. > v % 1 > // This is satisfied by any unsigned integer type, but not by a > signed integer type. > v = 1<<(unsafe.Sizeof(v) * 8 - 1) > } > > That requires an import,

Re: [go-nuts] Re: Generics as builtin typeclasses

On Saturday, 8 September 2018 06:19:09 UTC+2, Lucio wrote: > What my uneducated eye sees at the core of the proposed contracts is a > new, extended approach to defining *types*, that assigns categories to them > (classes, of course) based - as interfaces are, for user-defined types - > on

Re: [go-nuts] Re: Generics as builtin typeclasses

On Friday, 7 September 2018 20:47:42 UTC+2, Ian Lance Taylor wrote: > > > I think your contracts do require signedness and unsignedness. When > you ask whether `i << 1` should permit shifting by values other than > 1, you are going back to the question of what generic function bodies > are

Re: [go-nuts] Re: Generics as builtin typeclasses

Would this work? contract unsigned(u T) { 1 << u } It's another infelicitous horror, but I believe it exploits the only place in the language where an unsigned integer is required. -rob -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Re: Generics as builtin typeclasses

contract unsigned(v T) { // Require T to be an integer type. v % 1 // This is satisfied by any unsigned integer type, but not by a signed integer type. v = 1<<(unsafe.Sizeof(v) * 8 - 1) } That requires an import, not to mention unsafe, which raises the issue of whether a contract

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 11:39 AM, Axel Wagner wrote: > On Fri, Sep 7, 2018 at 3:10 PM Ian Lance Taylor wrote: >> >> This does surprise me. I'm certainly too close to the problem, but to >> me it always seems quite clear which type arguments a contract allows >> and excludes. It's exactly the set

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 10:51 AM, jimmy frasche wrote: > > To describe a sufficiently-tight contract you need to be able to come > up with an elaborate conjunction of properties that allow everything > needed while disallowing everything that would cause your code to > break. To read such a

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 3:10 PM Ian Lance Taylor wrote: > This does surprise me. I'm certainly too close to the problem, but to > me it always seems quite clear which type arguments a contract allows > and excludes. It's exactly the set of types that type check successfully. I yield that it's

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 6:10 AM Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 4:29 PM, Axel Wagner > wrote: > > > > The other day I had a lengthy conversation with Rog Peppe, David Crawshaw > > and Nate Finch on twitter and I'd argue that neither of us would really > > count as a Go-novice

Re: [go-nuts] Re: Generics as builtin typeclasses

> > "If the contract body uses a type in a certain way, the actual > function is permitted to use the type in the same way." > I like the idea of this, and it feels like it *should* be intuitive, > but the problem is that "in a certain way" needs to be very well > defined. "This is

Re: [go-nuts] Re: Generics as builtin typeclasses

The key sentence from the draft is this: "If the contract body uses a type in a certain way, the actual function is permitted to use the type in the same way." I like the idea of this, and it feels like it *should* be intuitive, but the problem is that "in a certain way" needs to be very well

Re: [go-nuts] Re: Generics as builtin typeclasses

Never mind, I found it. The draft proposal says To validate the type arguments, each of the contract’s parameter types is > replaced with the corresponding type argument [...]. The body of the > contract is then type checked as though it were an ordinary function. If > the type checking

Re: [go-nuts] Re: Generics as builtin typeclasses

> > contract { var _ map[T]bool } Would this contract allow T to be used in a map to some other type than bool? e.g. map[T]int? If so, why? Why is bool a stand-in for "any type"? (I apologize if this has been dealt with elsewhere; this is a big topic.) On Thursday, September 6, 2018 at

Re: [go-nuts] Re: Generics as builtin typeclasses

I think the 90% rule applies… if we can have a simple solution that covers 90%, rather than a complex one to cover 100%, go with the simple. There are always trade-offs in development - having simple, easy to understand tools always wins out IMO - because greater adoption and usage is key. >

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 4:29 PM, Axel Wagner wrote: > > The other day I had a lengthy conversation with Rog Peppe, David Crawshaw > and Nate Finch on twitter and I'd argue that neither of us would really > count as a Go-novice and we *still* weren't always clear what types certain > contracts

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 9:29 AM 'Axel Wagner' via golang-nuts wrote: > On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor wrote: >> Interesting point. But is there any way to solve it short of >> explicitly listing types? Is there any generics system in any >> language that avoids this problem? >

Re: [go-nuts] Re: Generics as builtin typeclasses

Aha, I see what the other set of operators are. While what I thought still stands: All of these operators should be handled by the compiler, the user no need to think about them at all - let the compiler retrieves them implicitly from the function body. In terms of convertible, I think it is

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 2:00 AM xingtao zhao wrote: > Try to raise my point here (from another thread): > > I think all of the operator constraints should be retrieved implicitly. > The proposal of the contract on operators seems a design flaw to me: why do > we express that if < is in the

Re: [go-nuts] Re: Generics as builtin typeclasses

Try to raise my point here (from another thread): I think all of the operator constraints should be retrieved implicitly. The proposal of the contract on operators seems a design flaw to me: why do we express that if < is in the contract, all other operators are also allowed? I think we do not

Re: [go-nuts] Re: Generics as builtin typeclasses

On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor wrote: > On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner > wrote: > Interesting point. But is there any way to solve it short of > explicitly listing types? Is there any generics system in any > language that avoids this problem? > I'm not saying

Re: [go-nuts] Re: Generics as builtin typeclasses

> > Hypothetically, if Go introduced generics where you couldn't write > > min/max but included min/max builtins, what's the next smallest > > example where operators are necessary? > > // Contains returns whether v is in the slice s. > func Contains(type T)(s []T, v T) bool { > for _, x :=

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner wrote: > > On Thu, Sep 6, 2018 at 9:45 PM Ian Lance Taylor wrote: >> >> On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche >> wrote: >> >> This is clearly a key issue. I happen to think that contracts are >> fairly clear for the reader: take your type

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 2:35 PM, jimmy frasche wrote: > >> It's not necessary to support fields but I think it really is >> necessary to support operators. I claim that, other than type safe >> data structures, the number one generic function that people want to >> write is Min (or Max). I don't

Re: [go-nuts] Re: Generics as builtin typeclasses

My point was that type-classes don't really help in and off itself. What helps is that operators are methods (i.e. Haskell has operator overloading). If Go had operator methods, that would work too (obviously), because you could write an interface for them. Anyway :) On Fri, Sep 7, 2018 at

Re: [go-nuts] Re: Generics as builtin typeclasses

I meant without having to use a wrapper but still accepting all three. I certainly agree that it not the Go way or the way to go. On Thu, Sep 6, 2018 at 3:16 PM Axel Wagner wrote: > > On Thu, Sep 6, 2018 at 11:36 PM jimmy frasche wrote: >> >> To unify those cases you need something like

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 11:36 PM jimmy frasche wrote: > To unify those cases you need something like haskell-style typeclasses > where you can say this type satisfies this contract using these > methods/operators. > FWIW, the Go way of doing that is embedding it in a new struct and overwriting

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 2:32 PM, wrote: > > Here's a few points which I noticed when reading through the draft design > which I thought people might have trouble getting their heads around: > > 1. The use of untyped numeric constants where you might need to specify the > exact value needed to get

Re: [go-nuts] Re: Generics as builtin typeclasses

Hi Ian, On Thu, Sep 6, 2018 at 9:45 PM Ian Lance Taylor wrote: > On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche > wrote: > > This is clearly a key issue. I happen to think that contracts are > fairly clear for the reader: take your type argument and see if the > contract body works. I feel

Re: [go-nuts] Re: Generics as builtin typeclasses

> This is clearly a key issue. I happen to think that contracts are > fairly clear for the reader: take your type argument and see if the > contract body works. I feel that everyone who knows Go will be able > to do that. But maybe that's just me. For complicated contracts—and I mean even ones

Re: [go-nuts] Re: Generics as builtin typeclasses

Ian, Here's a few points which I noticed when reading through the draft design which I thought people might have trouble getting their heads around: 1. The use of untyped numeric constants where you might need to specify the exact value needed to get the thing to work. I don't think anyone

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 1:21 PM, Caleb Spare wrote: > On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor wrote: >> >> Personally I think an important feature of the current design draft is >> that it adds relatively few new concepts to the language. While >> concepts are of course a new feature, a

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 8:20 AM, wrote: > > > > As I wasn't happy with some aspects of it, I've rewritten my feedback on the > > Go 2 Generics draft and deleted the original gist. Here's the link to the > > new gist for anybody who's

Re: [go-nuts] Re: Generics as builtin typeclasses

On Thu, Sep 6, 2018 at 12:05 PM, alanfo wrote: > > So, yes, there'd be a lot to learn but there'd also be a lot to learn to > write 'full-blooded' contracts effectively some aspects of which are quite > subtle. I would like to more clearly understand which aspects seem subtle when reading the

  1   2   >