Re: [go-nuts] Avoiding overloading
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 -- 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] Avoiding overloading
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.
--
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] Avoiding overloading
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
> On Oct 19, 2018, at 9:18 PM, Eric S. Raymond wrote:
>
> 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).
>
> I don't understand the the grounds of this objection. Can you pose some cases
> you think implements couldn't cover?
> --
> 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] Avoiding overloading
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). I don't understand the the grounds of this objection. Can you pose some cases you think implements couldn't cover? -- 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] Avoiding overloading
Ian Denhardt :
> Quoting Eric S. Raymond (2018-10-19 16:15:25)
> > Ian Denhardt :
> > > 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?
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.
--
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] Avoiding overloading
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 > On Oct 19, 2018, at 1:15 PM, Eric S. Raymond wrote: > > Ian Denhardt : >> 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. > -- > 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. -- 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] Avoiding overloading
Quoting Eric S. Raymond (2018-10-19 16:15:25)
> Ian Denhardt :
> > 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?
--
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] Avoiding overloading
Ian Denhardt : > 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. -- 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] Avoiding overloading
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? -- 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] Avoiding overloading
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. -- 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.
