"Google ate my homework, sir!"
Let me try again...
On 9/22/18, Ian Denhardt <i...@zenhack.net> wrote:
>
> This is a very good insight. There's no technical reason why Go couldn't
> define a built-in interface, much like `error`, for various operators,
> e.g.
>
> type adder(type T) interface {
> Add(T) T
> }
>
> ..and then the `x + y` just becomes a shorthand for `x.Add(y)`. Note
> that to express this we need the generics, because we need e.g. `int` to
> implement `adder(int)`, while `uint8` implements `adder(uint8)`.
>
This seems itself a very neat approach, in the light of my own intuition.
> Michael Jones's reply articulates a concern that I don't see a clean way
> around other than something like operator overloading: the current
> proposal leaves us with redundant interfaces; you have two ways of
> talking about equality, one for basic types and one for user-defined
> types. Same thing for comparison (people will want to sort both ints and
> user-defined types), and many of the other standard operators.
>
> It seems like the proposal would be massively simplified by operator
> overloading. Many people seem to have a general aversion to the idea,
> but I haven't yet seen the problem articulated in a way that makes sense
> to me. Why is it okay for `Write` to do anything from putting bits on a
> disk, to sending them around the world, to adding them to the state of a
> cryptographic hash function, but not okay for `==` to express equality
> on anything but a small handful of types?
>
> I have a suspicion that for many people (not necessarily), part of the
> concern comes from bad experiences with the way C++ does overloading.
>
The concern I have heard voiced (and agreed with) since the first
release of C++ is that operator overloading creates too great an
opportunity for obfuscation and some may find it irresistible, not
only intentionally, but with malicious intent.
It is a civilising feature of human nature not to release weapons of
mass destruction upon an unsuspecting audience. One also does lose
opportunities in the process and we may be on a cusp right now in
exactly this way.
> One problem is that it allows you to overload essentially *any*
> operator, including things like `&&` and `||` whose short-circuting
> semantics can't be replicated by a method. Thinking of `+` as a method
> call on the other hand is an abstraction that doesn't leak.
>
> I would like to hear a clear argument as to what is actually wrong with
> operator overloading, as it isn't obvious to me and it seems like folks
> are discarding a solution that has the potential to substantially
> simplify the proposal, without a well-articulated reason.
>
Operator overloading, perhaps even a more disciplined equivalent, does
not seem to be sufficient to encompass the entirety of the generics
problem, but it helps to identify the need for an extension to the
"type" concept that the C++ "class" does not define adequately, but
almost certainly aspires to.
I think the approach by Ian above is a step in the right direction: a
formal description not just of a "type" concept, but of practically
any language element in Go that permits us to add attributes to
objects that are not yet covered by existing notations. That is Go's
contribution to programming notations, a disciplined approach such as
would be essential to discourage, not prevent, the obfuscation made
possible by "operator overloading".
In a way, after all, generics are exactly that: each a unique
operation applied to different "type instances" (in defined
combinations) that are expected to have specifically *that operation*
in common. Or, more appropriately, *that operation* is conventionally
believed to serve analogous purposes in different, but also similar,
"namespace" described by their parameters.
In seeking to formalise the mechanism to declare the common
properties, we also identify the differences, such identification
being itself a formalisation. That is the uncharted territory we can
no longer ignore and Go is a door opening into that territory. I don't
think what will be discovered there will leave Go unscathed: I think
there will have to be incompatible adjustments, I'm not sure that the
Go developers have a fall-back plan when their stated intention to
retain backwards compatibility with Go 1 is proven (if it is) to be
impossible to attain.
But the core essence of Go is its simplicity. As long as it remains an
objective and everything possible is done to retain such simplicity as
far as possible, Go will remain the pioneer in its field.
On personal note, at this point there has been a lot of talk around
generics, one may well be led to believe that Go 2 is "just Go with
generics" (error handling in Go 1 is quite good enough for me, I only
gave a cursory glance to the proposal on enhancing that aspect of Go -
nothing else has caught my attention), which does not do the language
and its inventors and developers justice.
I feel Go 1 missed an opportunity to assimilate the principles
espoused by E.J. Dijkstra, in return for which they have provided the
eminently pragmatic language we can actually use without being
mathematically minded. I am hoping a second generation Go, or maybe
even a fork of it, will find more in "The Discipline Of Programming"
to incorporate. It is not the Gospel, it was at the time mere prophesy
:-). Today, we can put it to the test and also improve on it even
further than Go did ten years ago.
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.
