On Sunday, 9 September 2018 15:50:17 UTC+2, Robert Engels wrote:
>
> Which is why I believe this can happen with existing interfaces and
> compiler magic. (along with my other proposal regarding carrying the
> concrete type in slices).
>
> I think this is an admirable objective, if it can be achieved. Where are
the mathematicians? My gut feel is that the magic is there, but now its
tricks need to be explicitly revealed to be just "sufficiently advanced
Science".
Let me not be obscure: the compiler deals with operator overloading
already, I believe it is done by exceptions (consider "+" as a string
concatenator). It may or may not be possible to provide formal expression
for these exceptions; if that needs to be restricted to only some
operators, it will be instructive to determine why.
Here lies my realisation that the current proposal is exactly opposed to
operator overolading: if "%" uniquely identifies both its operands as
integers, once the proposal is accepted, nothing even cataclysmic can allow
"%" to be defined for a new purpose. That may make a lot of sense in the
present context, but is it really something that future generations can
live with?
> You can do operator overloading and type conversion with interfaces.
> (although not a big fan of operator overloading…)
>
> Is anybody really a fan of operator overloading? I think it occasionally
can make a difference, but every descendant of APL has shown that it is not
sustainable (pity that, actually!).
Method overloading requires no new keywords.
>
>
> Generic collections can probably be implemented with interfaces (Iterable
> for the range keyword, Equality, Comparable) and some compiler magic.
>
No new keywords or syntax needed.
>
> What the current proposal does, is use compiler idioms (for Rob Pike will
no doubt recognise them as such) to categorise types, by this means
avoiding the introduction of official "type categories", at the expense of
(1) understanding, as I'm sure I'm not unique in not quite knowing every
possible corner possibility in Go and, be warned, there are (few,
thankfully) implementation issues that may prevent the "absolute
comprehension" necessitated by such an approach to contracts.
Ian hinted at this by asking us not to focus on what contracts can
prohibit, but rather on what they can permit. That he needs to do that is a
suggestion that the proposal is itself insufficiently clear on this aspect.
(2) (Yes, I tend to ramble) Casting in stone language "syntactic sugar"
that, no matter how deeply conventional, is only syntactic sugar after all.
I refer the reader to a parallel discussion about the use of Unicode
symbols instead of keywords that took place in this forum. Again, APL uses
different symbols for multiplication and exponentiation, which I just
happen to prefer, too.
But what I see here, is the presumption that operators with identical
representation actually need to have "analogous semantics" for what can
only be a very loose meaning of "analogous" (cf. "+" for strings, yet
again). And also that only the compiler has the right to define such
semantics.
I am NOT advocating operator overloading by this - although it is clear
that the "prohibition of operator overloading" is based on a false premise
- but rather that we consider in depth how to extend the existing, but
inaccessible overloading capability of the compiler to user-defined
operations (not operators, but operations such as functions) and formalise
it so as to retain the type-safety and similar characteristics of the Go
language. If it opens the door to operator overloading, I think it ought to
be looked upon as a boon, not a curse, to be used with due caution.
But the unquestioned belief that by dint of being represented differently,
operators are in some manner special, needs to be revisited: it is blocking
more pertinent developments from taking place and, in the particular case
of the current generics proposal, it is presenting a total red herring (as
I think Rob Pike intuitively pick up) that type categorisation should be
implemented based on the set-theoretical properties (union, intersection
and disjunction) of chimeric "operators".
In summary: "operators" are syntactic sugar, they don't seem to deserve to
be promoted to play king-making roles in the contracts proposal; if they
do, Ian's hope that we may focus on one aspect (inclusion) and not the
opposite (exclusion) of the proposal will only be attained (this is only a
gut-feeling) at some high cost we have not yet identified. Far from me,
though, to stop the experimentation that is clearly needed to go forward
from here. Even if it leads to total rejection, once and for all, of any
possibility to include "generics" (which no doubt will be much more clearly
identified, by then) as an extension of the Go language.
I'd like to see the extremely simple operations APL calls floor (I bet my
memory fails me, so I'll use "Min" instead) implemented as simply as
possible:
func (x) Greater(y) bool {
return x > y
}
func (x) Min(y) (z) {
if x.Greater(y) {
return y
}
return x
}
All that's missing is some prescription (type or supertype) around the
various function arguments. I have no idea what the options really ought to
be, or how to pick the "best" such option. Thankfully, we have brilliant
minds to call upon to solve this riddle.
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.
