Avoiding overloading

[Eric Raymond]

I think Ian Denhardt is right to argue that fear of operator overloading is driving people in the generics debate to complicated, ugly workarounds that should not be.

I myself do not  actually want overloading as a surface feature of the language.  In my original "implements" proposal, I accepted it as an implication of using operators to define type classes, because I thought (and still think) it is the simplest possible way to declare contracts.

I think the simplicity of having "implements" as the only contract declaration is too important a win to mortgage to a feature many - including myself - are not actually friendly to.

Therefore, as the author of the "implements" proposal, I am declaring neutrality on whether an "implements" clause should declare an overload at all!

That is, there is a possible future in which "implements <" on type T  does not  make a < b legal on non-primitive type T, but is solely a typeclass declaration associating  T with all other types that implement <; semantically, a Sortable contract.

I would be OK with that future,  It keeps the important part of "implements" - simplest way to declare contracts - while tossing out the part that (not without reason) raise some hackles.

My only caution here is on interface psychology.  If we're going to go this route, users are, to be honest. probably going to bitch that not taking the tiny additional step to overloading is perverse.  We'll need a good strong public argument to counter that.

[Ian Denhardt]

Quoting Eric Raymond (2018-10-19 14:43:51)

> Therefore, as the author of the "implements" proposal, I am declaring
> neutrality on whether an "implements" clause should declare an overload
> at all!
> That is, there is a possible future in which "implements <" on type T�
> does not� make a < b legal on non-primitive type T, but is solely a
> typeclass declaration associating� T with all other types that
> implement <; semantically, a Sortable contract.

What would code making use of a `Sortable` type look like? If you can't
actually use "implements <" to overload `<`, it's not clear to me what
it would actually do?

[Eric S. Raymond]

Ian Denhardt <i...@zenhack.net>:

> What would code making use of a `Sortable` type look like? If you can't
> actually use "implements <" to overload `<`, it's not clear to me what
> it would actually do?

Be available to a Sort function. That is, the requirement "Have a Less()"
would be replaced by "Have an implements-< method".

How this is specified at the callsite is a separate question. I can't
see any simpler way to do it than writing '<', but if anyone hates
overloading enough to invent a syntax they can do it ab nd
I won't complain.

I'm saying I'd prefer that future to heavyweight contracts. Surface
overloading is *not* the important thing about "implements"; having a
lightweight way to refer to typeclasses like "Sortable" is.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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.

[Ian Denhardt]

Quoting Eric S. Raymond (2018-10-19 16:15:25)

> Ian Denhardt <i...@zenhack.net>:
> > What would code making use of a `Sortable` type look like? If you can't
> > actually use "implements <" to overload `<`, it's not clear to me what
> > it would actually do?
>
> Be available to a Sort function. That is, the requirement "Have a Less()"
> would be replaced by "Have an implements-< method".
>
> How this is specified at the callsite is a separate question. I can't
> see any simpler way to do it than writing '<', but if anyone hates
> overloading enough to invent a syntax they can do it ab nd
> I won't complain.
>
> I'm saying I'd prefer that future to heavyweight contracts. Surface
> overloading is *not* the important thing about "implements"; having a
> lightweight way to refer to typeclasses like "Sortable" is.

Ah, so are you just suggesting you'd be able to do (e.g.):

func SortSlice(type T implements <)(slice []T) {
// ...
}

..but not actually be able to redefine `<` for a user-defined type?

[Andy Balholm]

It seems to me that what you are proposing with “implements” is not really a replacement for contracts. It would do something that contracts don’t (unify operators and methods), and it wouldn’t do nearly all of what contracts do (clearly define what is expected of type parameters across a wide range of possible operations).

As I understand it, the most important function of contracts is to produce sensible error messages (as opposed to the ones that C++ templates have become infamous for). If it weren’t for that, we could just leave type parameters unconstrained, and let the generic function’s body be its own contract. If the function uses <, the types passed to it must support <…

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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Eric S. Raymond]

Ian Denhardt <i...@zenhack.net>:

Something like that. Only why require (type T implements <)? The compiler
can figure out whether T implements < or not and throw an error if it doesn't.

Somewhere inside the generic Sort we'd need a way to say "plug in T's
implementation of < here." That's the callsite I was thinking of. The
simplest and most obvuius way to do that is to bite the operator-overloading
bullet and say "<", but I'm saying I could live with some magic syntax to
avoid that if the allergy to operator overloading is insuperable.

I'm in kind of a weird position here, because I want us to do the simplest
possible thing but recognize that there's allergy to it going around.

[Eric S. Raymond]

Andy Balholm <andyb...@gmail.com>:

> It seems to me that what you are proposing with “implements” is not really a replacement for contracts. It would do something that contracts don’t (unify operators and methods), and it wouldn’t do nearly all of what contracts do (clearly define what is expected of type parameters across a wide range of possible operations).

I don't understand the the grounds of this objection. Can you pose some cases
you think implements couldn't cover?

[Andy Balholm]

There are some contracts in the draft design that can’t be expressed with the “implements” syntax as it stands. Some would be fairly simple syntax extensions, but others describe the relationship between two types rather than just the operations on a single type. No extension of interfaces (except perhaps generic interfaces with mutually-referential type parameters) can handle those.

The one called convertible is an example of one that would require a fairly trivial extension: adding a way to declare that a method implements a type conversion.

For an example of the other kind, take G from the graph example. I don’t think any of the alternate proposals can handle that situation (at least not nearly as succinctly):

contract G(n Node, e Edge) {
var _ []Edge = n.Edges()
var from, to Node = e.Nodes()
}

Even if we give up on the ability to define relationships between types, adding extensions for all the other operations that people will want support for will likely take away much of the initial simplicity that makes the “implements” syntax attractive—one trivial extension at a time. The “contract” proposal, on the other hand, is actually a simple, powerful idea; it's working out the implications that ties people’s brains in knots.

Andy

[Ian Denhardt]

Quoting Andy Balholm (2018-10-20 13:30:58)

> There are some contracts in the draft design that can’t be expressed with the “implements” syntax as it stands. Some would be fairly simple syntax extensions, but others describe the relationship between two types rather than just the operations on a single type. No extension of interfaces (except perhaps generic interfaces with mutually-referential type parameters) can handle those.
>
> The one called convertible is an example of one that would require a fairly trivial extension: adding a way to declare that a method implements a type conversion.
>
> For an example of the other kind, take G from the graph example. I don’t think any of the alternate proposals can handle that situation (at least not nearly as succinctly):
>
> contract G(n Node, e Edge) {
> var _ []Edge = n.Edges()
> var from, to Node = e.Nodes()
> }

The graph example is addressed in the context of my proposal here:

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

Granted, it is slightly more verbose -- but I do not think that the
extra concision for this *one* example in the draft is worth introducing
an entirely new non-orthogonal concept.

The convertible example does not seem especially well motivated to me.
FormatUnsigned is defined like this:

func FormatUnsigned(type T convertible(uint64, T))(v T) string {
return strconv.FormatUint(uint64(v), 10)
}

And then used like:

s := FormatUnsigned(rune)('a')

But why not:

func FormatUnsigned(v uint64) string {
return strconv.FormatUint(v, 10)
}

// ...
s := FormatUnsigned(uint64('a'))

I'm quite willing to discard convertible without a more compelling
example.

> Even if we give up on the ability to define relationships between types, adding extensions for all the other operations that people will want support for will likely take away much of the initial simplicity that makes the “implements” syntax attractive—one trivial extension at a time. The “contract” proposal, on the other hand, is actually a simple, powerful idea; it's working out the implications that ties people’s brains in knots.

Eric has said this elsewhere, but his suggestion (and operator
overloading generally) is not a complete solution (nor is it
intended to be). However, it complements my own proposal (see
above) in a way that allows it to abstract over operators as well as
operators. I haven't seen any *compelling* use cases that can be dealt
with using contracts, but not interfaces + operator overloading.

[Andy Balholm]

The examples I gave were just the first examples I ran across in the design draft—not the only ones I could come up with.

The convertible one, in particular, is not particularly significant in itself. It’s just one of probably dozens of types of operations that people will want generic types to be able to support, besides method calls and operators. Adding support for them wouldn’t be very hard either, but by the time you got done, the result might be about as complicated as contracts.

Andy

[Ian Denhardt]

Quoting Andy Balholm (2018-10-20 17:34:15)

> It’s just one of probably dozens of types of operations that people
> will want generic types to be able to support, besides method calls and
> operators. Adding support for them wouldn’t be very hard either, but by
> the time you got done, the result might be about as complicated as
> contracts.

I am not convinced. My proposal goes through *every* example in the
examples section at the end of the draft. Throughout all of the
discussions on this list I have seen very few, if any, compelling
uses that contracts can handle but operator overloading + interfaces
can't (I can't think of one).

It's also not just a question of complexity per se -- it's also
that contracts have too much overlap with interfaces (which are not
going away). I also don't think they provide a very good way of
expressing intent. Even so, as I mentioned above, the interfaces +
operator overloading route covers basically everything I've seen. And
it's still simpler.

-Ian