On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
>
> I think the thing everyone who likes operator overloading like mainly
> is being able to do infix and postfix syntax, instead of only prefix
> (function).
My own reason for wanting this is not really about syntax, so much as
being able to define functions etc. which e.g. check for equality,
without having to write too versions -- one that uses `==` and one
that calls some method custom types. The syntax isn't really the point;
there's an underlying notion of equality that we want to be able to talk
about for more than just built-in types. We could define an interface
for this:
// The Equatable interface wraps the basic Equals method.
//
// x.Equals(y) tests whether x and y are "the same." The predicate
// Equals should obey a few common sense rules:
//
// 1. It should be reflexive: x.Equals(x) should always return true
// (for any x).
// 2. It should be symmetric: x.Equals(y) should be the same as
// y.Equals(x)
// 3. It should be transitive: if x.Equals(y) and y.Equals(z), then
// x.Equals(z).
//
// It generally does not make sense for a type to implement
// Equatable where the type parameter T is something other than
// itself.
type Equatable(T) interface {
Equals(T) bool
}
What I am suggesting is merely that `==` desugars to a use of this
interface.
An important litmus test for any operator we consider for overloading is
whether we can come up with a clearly specified interface for it like
the above. If not, it does not make sense to allow the operator to be
overloaded, since it is not clear what overloaders should do. I believe
this is the source of most of the problems with operator overloading in
other languages.
I think if we stick to this things will stay under control; there's
currently nothing stopping folks from defining an instance of
io.Writer that does something utterly in conflict with what is described
in its documentation -- but that hasn't seemed to be a problem in
practice.
Quoting Michael Jones (2018-09-22 13:14:21)
> the reason i wrote something like "...operator overloading, but wait,
> don't get excited..." was to bring awareness of a core problem without
> (hopefully) having people bring the burden of experience. i say burden
> because bad experiences can shadow the 'why' that was good with the
> 'how' that was bad. let the why foremost to "break these chains, rise
> up, and move beyond" as in Callicles' famous speech.
> the essential meaning of operator overloading and go interfaces and
> Smalltalk messaging is a way to bind code to intent. (in general intent
> is named uniquely ("==") for simplicity but that is independent.)
> Generics raise the need a way to say how the standard intentions play
> out for our types. Imagine our gopher attired as a waiter, politely
> asking questions of a custom type:
>
> gopher: Will you want to test for equality, madam?
>
> type: Yes, thank you.
>
> gopher: How would you prefer that test to be done?
>
> type: Hmm... I'll try 'IsEqualWithOddName(a, b *type)" for now.
>
> gopher: very good, madam.
>
> This mutual understanding needs to happen. how is open to discussion.
> go interfaces use standard method names. operator overloading uses
> standard symbols. macro expansion uses arguments. no matter how it
> manifests, the power of generics relies on understanding related parts.
> we should talk about what kinds of parts deserve awareness.
>
> On Sat, Sep 22, 2018 at 8:46 AM Lucio <[1]lucio.d...@gmail.com> wrote:
>
> > It's good that you brought that up, because another issue I
remember
> from C++ V1.0 days, is that operator overloading did not allow for
> changes in operator precedence, an arbitrary sop to some weird
> decisions taken in earlier centuries. What I see as pertinent here, is
> that precedence is yet another "type" property, this time not of the
> arguments to an operator, but the operator itself.
> As I pointed out in private correspondence to Ian Taylor, the entire
> mess of arithmetic operations ought to be delegated to an APL-like
> interpreter and all the complexities, of which being "generic"
> functionality is not the only one, becomes one less problem for the Go
> compiler. If APL is too obscenely obscure in the Go context, no doubt
> there will be alternatives: it did not take Rob Pike long to produce
> Ivy.
> Of course, we also have indexing, indirection and a few other features
> of Go whose role could be examined and formalised, perhaps more
> successfully once the obscurity contributed by the arithmetic features
> is expelled from the language.
> Ian's response will remain with me for as long as I live, as I think it
> is very apt summary: that would not be Go. I entirely agree with him.
> �
>
> But then also what do you do about interfaces that also implement an
> operator interface? I'd guess biggest reason to not do it is�
> 1) no human readable distinction between actual operations and one has
> to decompose the code quite a lot as both types have to be known before
> you can attach it to an interface
> 2) there is very few cases where being able to use infix operators
> makes that much difference to readability, it's like you want some
> mathematical notation but it's still all in lines. Chaining
> pass-through methods works just as well and the types are much easier
> to identify before you even fully parse it.
>
> Once we treat mathematical expressions as orthogonal to the language,
> we get brand new choices, possibly opportunities: what is Boolean? What
> is a string that is not an array? Etc. A whole new chapter opens, for
> better or for worse.
> 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 [2]golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> --
>
> Michael T. Jones
> [4]michael.jo...@gmail.com
>
> --
> 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 [5]golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit [6]https://groups.google.com/d/optout.
>
> Verweise
>
> 1. mailto:lucio.d...@gmail.com
> 2. mailto:golang-nuts+unsubscr...@googlegroups.com
> 3. https://groups.google.com/d/optout
> 4. mailto:michael.jo...@gmail.com
> 5. mailto:golang-nuts+unsubscr...@googlegroups.com
> 6. 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.
