On Sunday, 28 October 2018 15:13:23 UTC+2, Scott Cotton wrote: > > Hi Marvin, > > I think a lot of us like the fact that when we see "a == b" in Go we know > what it is without looking up a redefinition somewhere. > To me, "a (==) b" is better if there is operator overloading, but I don't > like it in any case. > > I second that, unconditionally. The parentheses look absolutely redundant.
> One problem with operator overloading is that, to use operator overloading > for numeric types, one needs to be able to overload > constants (like Pi) in addition to operators for many numeric > representations. Non numeric operator overloading is not something I want > to see proliferate in Go code. Operator overloading for numeric types, on > the other hand, I think would be nice. > > My initial suggestion to Ian Taylor was that arithmetic should be yanked out of Go and interpreted by an external tool like, say, an APL interpreter. He didn't really like it, but he was very polite about it. > Also, wanted to suggest that there is already in the draft proposal an > alternative to the contract-local keywords you propose below: there could > be a core Go library package with a list of such contracts defined there > that could grow over time without changing the parser. > > I didn't pick that up. And now I'm so confused buy all the stuff that's gone past, I am positively quaking at the thought of even looking at the draft proposal. I battle to grasp interfaces and modules are going to really test my comprehension. That said, it seems to me that if we adopt the approach you mention, we're doing nothing different from formalising the process by which the compiler resolves the existing polymorphism of intrinsic types and operators (and I ought to get back to the bit about operators) and making it available to the developer. If we do that, we have the solution being sought. I think that means (a) that there could be many solutions or approaches, only a few of them really palatable and we'll be lucky if we hit on the best of those in the first few iterations, but this process is the best way to reach something aesthetically pleasing to start with; (b) that Go may undergo many alterations in the quest to deal Generics that will force a deviation from the Go1 promise which, after all, should not be made to apply to Go2 anyway. OT, mostly: As for the bit about operators, it is clear to me that we are a little stuck with something that is a (badly adopted) mathematical notation (formulas - do we blame FORTRAN?) shoe-horned into a notation for algorithms and trying to keep the two species under one hat is awkward and becoming more awkward as the concepts being modeled diverge further and further from the clinical environment of Science and Business towards the Arts and the Humanities. We have infix binary operators, prefix unary operators, operator precedences and a plethora of possibilities (my most recent discoveries hinge around Go's "time" package, specifically the Time and Duration types and methods that could be consistent, but are not) for attributes that afflict such objects. On top of which, we could eliminate the inconsistency that addition is commutative and subtraction is not (which means that "-" has different properties, in the Generics discussion, from "+"), but having only "-" and a negation operator, the problem goes away: a.Plus(b) becomes -a.Minus(b) - "a.UnaryMinus.Minus(b)": just a flight of fancy, really, on my part, one reflected by Time and Duration, though: why should t.Add(d) not have an equivalent d.Add(t) and are the results both of type time.Time? Maybe all this has driven me to delusions :-). 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.
