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 <lucio.d...@gmail.com> wrote:
> 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).
>>
>
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
