On 9/22/18, Michael Jones <michael.jo...@gmail.com> wrote: > these seem excellent points all around. > > one area of difficulty seems to me the lack of operator overloading. now, > hold your breath, i'm not arguing for it here. but it highlights a kind of > structural issue that is in the air around the discussion of generics. > consider: > > i instantiate a tree type to handle uin64 data. under the proposal, this > should work because guards assert that the type proposed must allow "==" to > be used. > > i instantiate with some custom type that needs its own custom > "isEqual(a,b)" -- that will not instantiate because there is no "==" > operator for my custom type, even though there is an equality tester but > its name is not "==" and i can't overload "Operator==" to say so. > > > this is not an argument for operator overloading but rather the observation > that what the generic tree code actually wants is not an "==" for > instantiated types but the more general and less specific notion of "what > can i call to determine equivalence?" > > one way is to have operator overloading so my type has equivalence testing > under a standard name. (==) > That's the APL approach, before operator overloading was invented. It *nearly* got there, but the concept of "overloading" wasn't sufficiently evolved yet. Naturally, there are other issues involved there as well.
> one way is to instantiate with the type name and a "test for equal" > function pointer that when nil means "just use ==" > That's an interesting idea that makes a lot of sense in the Go 1 context, but it is a bit of compromise to convention that may have shortcomings. Or maybe the exact opposite, it may well be the broadest possible application. > one way is to annotate my type's "isEqual()" a la json annotation with a > hint saying "use this for equality testing" > This has been my thought for a while: a type is nothing more than a variable attribute, which in some sense makes a property such as "testable for equality" just such an analogous attribute for a type. In fact, then pointers and indexing can also be reduced to analogous properties and in due course one arrives at "mutable types" and a whole new way to look at the compiler's job. I know that's a stretch, but even if Go 2 does not provide for the full extent of such a step, applying "attributes" to a language's elements does open opportunities and in a disciplined environment (which is where Go has the lead, in my opinion), a lot can be achieved that has been much harder until now (sorry, I can't help being a bit immodest about these "insights"). > > there may be many ways. but it seems generics would be simpler and more > generic if there was a way to be clear about such things. that is, to be > generic we want to ignore inessential differences in instantiation, but > extraneous difference (the name of equality testing) makes the essential > and inessential more confused. > I think we've "overloaded" types for a long time without consideration for the "essence" of a "type". My approach suggests that some attributes that we use to qualify language elements do not fall squarely under "type attributes", but need a few additional categories and the discipline that only formalising them can produce. Examples would be "immutable", "units" (the Go "time" type is a case in point) and of course indirection and indexing. There probably are others, as yet undiscovered, as much as pointers were a novel idea back in the 1960s. Once we break out of that box, we may desperately need to find ways to control that genie, though :-). 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.
