Re: [go-nuts] Re: Generic alternatives: new basic types?
Choosing a virtual machine target was the wrong decision. All machines have a machine in them, why add a virtual one? C already could be compiled on every platform, all we got out of it was processing latency and a whole extra layer of performance wrinkles that the CPU maker probably already fixed. It's my opinion that if you really think that Go is missing generics you just don't know the language well enough nor have used it to solve problems others used parametric polymorphism or generics. The clamour for solutions in the area of error handling and (easier) generic programming for go has to do with the wordy constructions required to implement data abstraction. To speak of java, it also has the interface, and was the biggest champion of the concept for a long time. But it's not the feature everyone talks about Java. That's the JVM on every processor and the OOP constructions, as everywhere else in programming there is no interface. But interfaces can solve a lot of these problems and cut down on boilerplate, and Go's stdlib already has loads of good though unsophisticated examples of interface programming. Also in this discussion people are talking about how languages like Smalltalk have deep reflection capabilities. Go has 'reflect'. and go has interfaces. You can often dodge a lot of use of reflect by using interfaces, and *making* types with more metadata is not difficult with Go, at all. The error inbuilt interface, for example. It is extremely primitive. The way it should be used is that you declare (almost) all types as structs and add the attributes you want to them and create interfaces that pass and process this data. Then you can use the dot notation to form ad hoc constructors, you can create second level names using structs, and the thing I have discovered is that once you have a really good set of interfaces for things like coding modes, error handling, and so on, when you go to actually write the application you can say a lot with quite a little. The downside of this complexity-averse philosophy in go is that even though the concept is not that young, I think there is some ways to go before the best patterns for interfaces are a settled question. What I love most about interfaces is they let my code start to look more like poetry and less like math. Maintaining code is very important, and though in some areas Go can be quite wordy, the constructions are quite naive and are not difficult to edit en masse, the invention of multiple cursors in editors is something Go programmers can greatly benefit from. Repetition is bad if it says nothing new but at the same time it is easier to unfold what it contains when it is in a simple syntax, and easier to generate automatically. Code generators are another thing I have started looking at, and I know there is a lot in there that would make this type of programming simpler. Turning a struct into JSON that can be unmarshalled using reflect does not require reflect, a simple string concatenation with some string conversions, which is just a bit of array shuffling. The same applies to database serialization. In go many times you can gain a lot with the use of some of the wordy stuff, and then afterwards you have a neat little black box that you can trust, and never have to use that wordy stuff unless you are just building something new without a clear map of its parts. Go puts a lot more power in the hands of the programmer, and doesn't sugar over very many things at all. Whether it reads well and is comprehensible is more dependent on the programmer than the language, but the benefit is being able to ride so close to the metal whenever you need to, and a neat construction system to give more flexibility and power. It's my opinion that when you start to try using interfaces and goroutines in new ways you have less bad to say about what is sacrificed for this power. I kinda basically wasn't programming much during the time of the rise of OOP though it seemed cool when it came out, I was just used to BASIC and assembler and my favourite language back then was called "E", which, similar to Go, combined a very simple syntax, mashed together some syntax patterns from C and Pascal style, but man that compiler flew, it felt like nearly as fast as assembler. Keeping the compilation process simple does mean the programmer must adapt their thinking to be more like the machine, but on the flip side, you can run through files and make multiple changes easily, with no ambiguity of symbols, search and replace and multiple cursors, quite quickly, and immediately see the change, plus, more easily write tools that parse it. There is many tools already, but the maturity of the field of automated programming isn't mature yet, in my view. Instead of wanting go to sacrifice that speed and simplicity so you can read your code easier, you will just use some declarative focused, maybe mixed embeds of
Re: [go-nuts] Re: Generic alternatives: new basic types?
Hi everybody. I'm a beginner at Golang. Anyone who has the talent to Golang please let me please On Mon, Sep 24, 2018 at 1:05 AM Ian Denhardt wrote: > Quoting Robert Engels (2018-09-23 13:38:04) > > I wasn’t suggesting that Go should resemble Java. I was just trying to > point out that many of the current issues under debate for Go2 have been > resolved quite well in other languages, and looking to them for direction > should not be out of bounds just because they are not Go. That’s a little > short sighted IMO. > > Java doesn't allow basic types to be used in generics at all (except for > arrays, which are magic like Go's slices and maps are today). The issue > under discussion crops up because we want to be able to talk about both > MyGenericType(MyCustomType) and MyGenericType(int). The fact that basic > types are totally separated from objects is a big wart in the language, > so Java isn't really a great source of ideas re: how to deal with the > question currently under discussion. > > -- > 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. > -- 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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
You did not offend me. This is a place for earnest ideas and all are
welcome.
Your comment is not yet persuasive, but it might become so. Still thinking.
I first heard from James Gosling about Java when Java was Oak. He seemed
proud to say, "C++ has objects. Well, I'll show them, I'll make *everything*
objects!" That they did. I've been recalling those days and wondering if
that team knew more about language design in some privileged way or was
just turning the knob to eleven. Still not sure.
I am sure that Alan Kay et al had important, fundamental insights in
Smalltalk. Variables had named attributes and they could be inspected in
code and visually with an inspector. I could ask you about your type, size,
length, etc. If i asked an inapplicable question i got a survivable answer,
not a panic. I raised this pre-Go1 in Google with the idea of, why are
Len() and Cap() not implicit methods on a slice? I like that because it
also suggests asking a variable, "hey, what is your minimum expressible
value?" in a way that is type agnostic. Being able to as parameter t of
generic type T a question like "x := t.MinExpressibleValue()" has a grand
flexibility compared to a type switch that then knows about library
functions for math.MinFloat64(). There were reasons why not, but in this
quest I'm not persuaded against the notion that *every common attribute of
T should be knowable from t, an instance of that type*. In Go this happens
with magic compiler generics (len(x), cap(x), ...) that take any and all
types and do the right thing. I'm more a fan of no magic and a simple
universal notion that applies to every type, built-in or custom.
In this sense, the Java team's gusto and my deep respect for Smalltalk's "a
queryable database of instances" (aka, DOM decades before) align and I do
like that path.
On Sun, Sep 23, 2018 at 9:17 AM Robert Engels wrote:
> I take offense to that. I apologized for my statement that was worded more
> harshly than intended. But if you think that Go is beyond criticism just
> because of ??? Anything??? Go is a GREAT tool for many classes of
> applications, but it is certainly not appropriate for all use cases. Maybe
> with open criticism it could get there, but I don’t think your attitude
> will help it. I am certainly not the first nor the last to highlight many
> deficiencies in Gos design. That’s the great thing about software though,
> it is malleable.
>
> Sent from my iPhone
>
> > On Sep 23, 2018, at 9:01 AM, Lucio De Re wrote:
> >
> > I take exception to that statement, your notion of "understood
> > languages much better" doesn't parse in light of the fact that you are
> > here, debating the merits of Java in the primary Go forum instead of
> > writing wonderful code using the language you respect so much.
> >
> > That's either hypocritical or merely absurd in addition to the rather
> > inappropriate, unjustified and offensive ad hominem that accompanies
> > it.
> >
> > Lucio.
> >
> >> On 9/23/18, Robert Engels wrote:
> >> Issues like these highlight the deficiencies of Go compared to Java. The
> >> Java designers understood languages far better, and from the start
> realized
> >> that identity and reference equality were different concepts. Everyone
> in Go
> >> land are debating these solved issues. Pick and chose what you want to
> >> implement but there doesn’t really need to be a debate on how to do it.
> >>
> >> Sent from my iPhone
> >>
> On Sep 22, 2018, at 8:52 PM, Ian Denhardt 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).
> >>>
> >>> 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)
Re: [go-nuts] Re: Generic alternatives: new basic types?
Quoting Robert Engels (2018-09-23 13:38:04) > I wasn’t suggesting that Go should resemble Java. I was just trying to point > out that many of the current issues under debate for Go2 have been resolved > quite well in other languages, and looking to them for direction should not > be out of bounds just because they are not Go. That’s a little short sighted > IMO. Java doesn't allow basic types to be used in generics at all (except for arrays, which are magic like Go's slices and maps are today). The issue under discussion crops up because we want to be able to talk about both MyGenericType(MyCustomType) and MyGenericType(int). The fact that basic types are totally separated from objects is a big wart in the language, so Java isn't really a great source of ideas re: how to deal with the question currently under discussion. -- 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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
I wasn’t suggesting that Go should resemble Java. I was just trying to point out that many of the current issues under debate for Go2 have been resolved quite well in other languages, and looking to them for direction should not be out of bounds just because they are not Go. That’s a little short sighted IMO. > On Sep 23, 2018, at 12:13 PM, Lucio De Re wrote: > >> On 9/23/18, Robert Engels wrote: >> I take offense to that. I apologized for my statement that was worded more >> harshly than intended. But if you think that Go is beyond criticism just >> because of ??? Anything??? Go is a GREAT tool for many classes of >> applications, but it is certainly not appropriate for all use cases. Maybe >> with open criticism it could get there, but I don’t think your attitude will >> help it. I am certainly not the first nor the last to highlight many >> deficiencies in Gos design. That’s the great thing about software though, it >> is malleable. >> > I responded harshly, too and that wasn't necessary, so I owe everyone > an apology. > > But setting Java as the paragon for Go is not going to win anyone to > your cause, either. Java exists, it is available, it is what it is. > Why would Go want to resemble it? > > 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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
On 9/23/18, Robert Engels wrote: > I take offense to that. I apologized for my statement that was worded more > harshly than intended. But if you think that Go is beyond criticism just > because of ??? Anything??? Go is a GREAT tool for many classes of > applications, but it is certainly not appropriate for all use cases. Maybe > with open criticism it could get there, but I don’t think your attitude will > help it. I am certainly not the first nor the last to highlight many > deficiencies in Gos design. That’s the great thing about software though, it > is malleable. > I responded harshly, too and that wasn't necessary, so I owe everyone an apology. But setting Java as the paragon for Go is not going to win anyone to your cause, either. Java exists, it is available, it is what it is. Why would Go want to resemble it? 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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
I take offense to that. I apologized for my statement that was worded more
harshly than intended. But if you think that Go is beyond criticism just
because of ??? Anything??? Go is a GREAT tool for many classes of applications,
but it is certainly not appropriate for all use cases. Maybe with open
criticism it could get there, but I don’t think your attitude will help it. I
am certainly not the first nor the last to highlight many deficiencies in Gos
design. That’s the great thing about software though, it is malleable.
Sent from my iPhone
> On Sep 23, 2018, at 9:01 AM, Lucio De Re wrote:
>
> I take exception to that statement, your notion of "understood
> languages much better" doesn't parse in light of the fact that you are
> here, debating the merits of Java in the primary Go forum instead of
> writing wonderful code using the language you respect so much.
>
> That's either hypocritical or merely absurd in addition to the rather
> inappropriate, unjustified and offensive ad hominem that accompanies
> it.
>
> Lucio.
>
>> On 9/23/18, Robert Engels wrote:
>> Issues like these highlight the deficiencies of Go compared to Java. The
>> Java designers understood languages far better, and from the start realized
>> that identity and reference equality were different concepts. Everyone in Go
>> land are debating these solved issues. Pick and chose what you want to
>> implement but there doesn’t really need to be a debate on how to do it.
>>
>> Sent from my iPhone
>>
On Sep 22, 2018, at 8:52 PM, Ian Denhardt 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).
>>>
>>> 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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
I take exception to that statement, your notion of "understood
languages much better" doesn't parse in light of the fact that you are
here, debating the merits of Java in the primary Go forum instead of
writing wonderful code using the language you respect so much.
That's either hypocritical or merely absurd in addition to the rather
inappropriate, unjustified and offensive ad hominem that accompanies
it.
Lucio.
On 9/23/18, Robert Engels wrote:
> Issues like these highlight the deficiencies of Go compared to Java. The
> Java designers understood languages far better, and from the start realized
> that identity and reference equality were different concepts. Everyone in Go
> land are debating these solved issues. Pick and chose what you want to
> implement but there doesn’t really need to be a debate on how to do it.
>
> Sent from my iPhone
>
>> On Sep 22, 2018, at 8:52 PM, Ian Denhardt 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).
>>
>> 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
Re: [go-nuts] Re: Generic alternatives: new basic types?
I’m sorry. I did not mean to offend anyone. It came out wrong and I apologize.
Sent from my iPhone
> On Sep 23, 2018, at 5:01 AM, Louki Sumirniy
> wrote:
>
> The thing that people are concerned about is creating a construct that
> enables you to write legal but confusing and unclear code. Let's say we steal
> triple equals ===, and then use it to mean some kind of special assignment
> operation. Or we make = become an addition operator infix for a
> string-related type.
>
> Interfaces don't cover the case of operator precedence, interfaces are all
> verb subject object. Operator precedence is a syntactic layer that does not
> have at least an easily inferred type and require deeper analysis of the AST
> before you can get the types right. The bigger reason to not allow constructs
> like this in Go is because one of its main advantages is simple parsing,
> which means tooling and nearly interactive speed testing. Go even can use
> spaces (or not) to override precedence. Either the implementation forces each
> operator symbol to be of only one precedence relation to others, or you are
> leaving out milk and cookies for the kinds of programmers that make people
> want to invent a language like Go.
>
> The case for equality operators is a pretty good one though. The reason why
> an infix operator is preferable for equality operations is because both
> operands are being tested for equality. It doesn't matter which order, unlike
> verb subject object of function notation. + is already used for string
> concatenation, logically it could and probably should also apply to any type
> of sliceable array type.
>
> I am against a wide open operator override system, most especially one that
> allows the disruption of the conventional order of precedence for the
> operator. But a small set that is declared like an interface and only covers
> a very small subset, the most useful ones, like +, ++, --, !=, ==, <, >.
>
> A central pillar of the design process of Go is all about avoiding complexity
> where flexibility can substitute and not add an excessive and questionable
> cost for an operation that is not that commonly used especially when it
> decreases the approachability of code. Overloaded equality, increment and
> comparision operators would not increase the ambiguity for either humans or
> the source code. If you can assert the type of an operator from only one of
> its operands this is less parsing than a case where you have to disambiguate
> both. Type casting should never be implicit, so for a Go version of operator
> overloading, there would not be conversion involved - a full parse showing
> differing types on an operator operand would thus be illegal. Unless both
> operands are both implementors of the same countable interface, for example,
> and they either use interface{} or a defined interface name as
> returns/inputs. I think that this is a step further on from just allowing
> redefinition of (some) operators to bind to new types, and to allow those
> types to create assignment channels, for example. And this is where the big
> syntax bugbear appears. Overriding an operator is one thing, but defining two
> types as being comparable and assignable with each other will pretty quickly
> grow into a hella boilerplate for a shortcut used 10 times in a 1000 line
> project, and ever growing compilation times.
>
> Go is a simple language, and anything that will take away the simplicity,
> with its benefits in learning, reading and compiling, will and should be
> rejected as an addition to the language spec. I would argue that a small set
> of infix operators and maybe some unarys would not create such complexity.
> Especially if we restrict it to unary post/prefix, addition, subtraction
> equality and assignment, and don't change the precedence rules. Really,
> precedence would not be relevant, and there should not be any ambiguity
> allowed in how an overridden symbol can be used. Precedence really only
> irritates everyone between add/subtract and multiply, square, and only for
> countable types. To stop complexity creeping into the parser, also, no change
> in the rule about casting. No implicit casts. Implicit casts are probably one
> of the most irritating and pervasive features of C type languages. I always
> have to double and triple check. Even between some version changes C++ has
> substantially disrupted the rules about it and I just don't think that
> implicit casting is a good construct in a language. Implicit typing through
> inference does not have this problem.
>
>> On Sunday, 23 September 2018 08:35:15 UTC+2, Robert Engels wrote:
>> Issues like these highlight the deficiencies of Go compared to Java. The
>> Java designers understood languages far better, and from the start realized
>> that identity and reference equality were different concepts. Everyone in Go
>> land are debating these solved issues. Pick and chose what you
Re: [go-nuts] Re: Generic alternatives: new basic types?
The thing that people are concerned about is creating a construct that
enables you to write legal but confusing and unclear code. Let's say we
steal triple equals ===, and then use it to mean some kind of special
assignment operation. Or we make = become an addition operator infix for a
string-related type.
Interfaces don't cover the case of operator precedence, interfaces are all
verb subject object. Operator precedence is a syntactic layer that does not
have at least an easily inferred type and require deeper analysis of the
AST before you can get the types right. The bigger reason to not allow
constructs like this in Go is because one of its main advantages is simple
parsing, which means tooling and nearly interactive speed testing. Go even
can use spaces (or not) to override precedence. Either the implementation
forces each operator symbol to be of only one precedence relation to
others, or you are leaving out milk and cookies for the kinds of
programmers that make people want to invent a language like Go.
The case for equality operators is a pretty good one though. The reason why
an infix operator is preferable for equality operations is because both
operands are being tested for equality. It doesn't matter which order,
unlike verb subject object of function notation. + is already used for
string concatenation, logically it could and probably should also apply to
any type of sliceable array type.
I am against a wide open operator override system, most especially one that
allows the disruption of the conventional order of precedence for the
operator. But a small set that is declared like an interface and only
covers a very small subset, the most useful ones, like +, ++, --, !=, ==,
<, >.
A central pillar of the design process of Go is all about avoiding
complexity where flexibility can substitute and not add an excessive and
questionable cost for an operation that is not that commonly used
especially when it decreases the approachability of code. Overloaded
equality, increment and comparision operators would not increase the
ambiguity for either humans or the source code. If you can assert the type
of an operator from only one of its operands this is less parsing than a
case where you have to disambiguate both. Type casting should never be
implicit, so for a Go version of operator overloading, there would not be
conversion involved - a full parse showing differing types on an operator
operand would thus be illegal. Unless both operands are both implementors
of the same countable interface, for example, and they either use
interface{} or a defined interface name as returns/inputs. I think that
this is a step further on from just allowing redefinition of (some)
operators to bind to new types, and to allow those types to create
assignment channels, for example. And this is where the big syntax bugbear
appears. Overriding an operator is one thing, but defining two types as
being comparable and assignable with each other will pretty quickly grow
into a hella boilerplate for a shortcut used 10 times in a 1000 line
project, and ever growing compilation times.
Go is a simple language, and anything that will take away the simplicity,
with its benefits in learning, reading and compiling, will and should be
rejected as an addition to the language spec. I would argue that a small
set of infix operators and maybe some unarys would not create such
complexity. Especially if we restrict it to unary post/prefix, addition,
subtraction equality and assignment, and don't change the precedence rules.
Really, precedence would not be relevant, and there should not be any
ambiguity allowed in how an overridden symbol can be used. Precedence
really only irritates everyone between add/subtract and multiply, square,
and only for countable types. To stop complexity creeping into the parser,
also, no change in the rule about casting. No implicit casts. Implicit
casts are probably one of the most irritating and pervasive features of C
type languages. I always have to double and triple check. Even between some
version changes C++ has substantially disrupted the rules about it and I
just don't think that implicit casting is a good construct in a language.
Implicit typing through inference does not have this problem.
On Sunday, 23 September 2018 08:35:15 UTC+2, Robert Engels wrote:
>
> Issues like these highlight the deficiencies of Go compared to Java. The
> Java designers understood languages far better, and from the start realized
> that identity and reference equality were different concepts. Everyone in
> Go land are debating these solved issues. Pick and chose what you want to
> implement but there doesn’t really need to be a debate on how to do it.
>
> Sent from my iPhone
>
> > On Sep 22, 2018, at 8:52 PM, Ian Denhardt > wrote:
> >
> >> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
> >>
> >> I think the thing everyone who likes
Re: [go-nuts] Re: Generic alternatives: new basic types?
Issues like these highlight the deficiencies of Go compared to Java. The Java
designers understood languages far better, and from the start realized that
identity and reference equality were different concepts. Everyone in Go land
are debating these solved issues. Pick and chose what you want to implement but
there doesn’t really need to be a debate on how to do it.
Sent from my iPhone
> On Sep 22, 2018, at 8:52 PM, Ian Denhardt 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).
>
> 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
Re: [go-nuts] Re: Generic alternatives: new basic types?
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
Re: [go-nuts] Re: Generic alternatives: new basic types?
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 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 *
--
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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
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). 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.
On Saturday, 22 September 2018 14:30:27 UTC+2, Ian Denhardt wrote:
>
> Quoting Lucio (2018-09-21 16:15:19)
>
> >The other thought I had, but is very poorly baked, is that the
> >"essence" of polymorphism in Go operators is analogous to the
> informal
> >definition of interfaces: it can be determined by the compiler, even
> >though it is not expressed in a formal notation (the magic of
> >super-types like for example "numerics" to which the addition
> operator
> >applies).
>
> 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)`.
>
> 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.
>
> 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.
>
--
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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
Quoting Lucio (2018-09-21 16:15:19)
>The other thought I had, but is very poorly baked, is that the
>"essence" of polymorphism in Go operators is analogous to the informal
>definition of interfaces: it can be determined by the compiler, even
>though it is not expressed in a formal notation (the magic of
>super-types like for example "numerics" to which the addition operator
>applies).
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)`.
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.
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.
--
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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
In my opinion the interface represents the simplest way to allow operator
overloading. With an inbuilt interface that covers all the symbols and some
sort of category to break them down (boolean logic, binary logic,
arithmetic, misc unary, prefix infix and postfix). Then you can have the
built in interfaces for 'countable', 'comparable', etc etc.
The thing that is the sticking point for me is that when I look through c++
code very often all of these things are implemented in a type but never
used, only constructors and sometimes destructors. I would think that
creating a special named function for classes, like a built in interface,
for initialisation and cleanup would be useful, something that triggers at
the end of scope unless the pointer is owned by another name somewhere, and
satisfy a lot of these issues. As for being able to take a big.Int and + it
with another thing, honestly, the amount of code you have to write with
these types is really so small the benefit probably doesn't even pay off
unless you are doing a LOT of big number math in a long algorithm, for the
cost in declaring the operators compared to just using the function
notation.
On Saturday, 22 September 2018 08:53:14 UTC+2, Lucio wrote:
>
> "Google ate my homework, sir!"
>
> Let me try again...
>
> On 9/22/18, Ian Denhardt > 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
Re: [go-nuts] Re: Generic alternatives: new basic types?
"Google ate my homework, sir!"
Let me try again...
On 9/22/18, Ian Denhardt 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
Re: [go-nuts] Re: Generic alternatives: new basic types?
On 9/22/18, Michael Jones wrote: > these seem excellent points all around. > > one area of difficulty seems to me the lack of operator overloading. now, > hold your breath, i'm not arguing for it here. but it highlights a kind of > structural issue that is in the air around the discussion of generics. > consider: > > i instantiate a tree type to handle uin64 data. under the proposal, this > should work because guards assert that the type proposed must allow "==" to > be used. > > i instantiate with some custom type that needs its own custom > "isEqual(a,b)" -- that will not instantiate because there is no "==" > operator for my custom type, even though there is an equality tester but > its name is not "==" and i can't overload "Operator==" to say so. > > > this is not an argument for operator overloading but rather the observation > that what the generic tree code actually wants is not an "==" for > instantiated types but the more general and less specific notion of "what > can i call to determine equivalence?" > > one way is to have operator overloading so my type has equivalence testing > under a standard name. (==) > That's the APL approach, before operator overloading was invented. It *nearly* got there, but the concept of "overloading" wasn't sufficiently evolved yet. Naturally, there are other issues involved there as well. > one way is to instantiate with the type name and a "test for equal" > function pointer that when nil means "just use ==" > That's an interesting idea that makes a lot of sense in the Go 1 context, but it is a bit of compromise to convention that may have shortcomings. Or maybe the exact opposite, it may well be the broadest possible application. > one way is to annotate my type's "isEqual()" a la json annotation with a > hint saying "use this for equality testing" > This has been my thought for a while: a type is nothing more than a variable attribute, which in some sense makes a property such as "testable for equality" just such an analogous attribute for a type. In fact, then pointers and indexing can also be reduced to analogous properties and in due course one arrives at "mutable types" and a whole new way to look at the compiler's job. I know that's a stretch, but even if Go 2 does not provide for the full extent of such a step, applying "attributes" to a language's elements does open opportunities and in a disciplined environment (which is where Go has the lead, in my opinion), a lot can be achieved that has been much harder until now (sorry, I can't help being a bit immodest about these "insights"). > > there may be many ways. but it seems generics would be simpler and more > generic if there was a way to be clear about such things. that is, to be > generic we want to ignore inessential differences in instantiation, but > extraneous difference (the name of equality testing) makes the essential > and inessential more confused. > I think we've "overloaded" types for a long time without consideration for the "essence" of a "type". My approach suggests that some attributes that we use to qualify language elements do not fall squarely under "type attributes", but need a few additional categories and the discipline that only formalising them can produce. Examples would be "immutable", "units" (the Go "time" type is a case in point) and of course indirection and indexing. There probably are others, as yet undiscovered, as much as pointers were a novel idea back in the 1960s. Once we break out of that box, we may desperately need to find ways to control that genie, though :-). 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.
Re: [go-nuts] Re: Generic alternatives: new basic types?
these seem excellent points all around. one area of difficulty seems to me the lack of operator overloading. now, hold your breath, i'm not arguing for it here. but it highlights a kind of structural issue that is in the air around the discussion of generics. consider: i instantiate a tree type to handle uin64 data. under the proposal, this should work because guards assert that the type proposed must allow "==" to be used. i instantiate with some custom type that needs its own custom "isEqual(a,b)" -- that will not instantiate because there is no "==" operator for my custom type, even though there is an equality tester but its name is not "==" and i can't overload "Operator==" to say so. this is not an argument for operator overloading but rather the observation that what the generic tree code actually wants is not an "==" for instantiated types but the more general and less specific notion of "what can i call to determine equivalence?" one way is to have operator overloading so my type has equivalence testing under a standard name. (==) one way is to instantiate with the type name and a "test for equal" function pointer that when nil means "just use ==" one way is to annotate my type's "isEqual()" a la json annotation with a hint saying "use this for equality testing" there may be many ways. but it seems generics would be simpler and more generic if there was a way to be clear about such things. that is, to be generic we want to ignore inessential differences in instantiation, but extraneous difference (the name of equality testing) makes the essential and inessential more confused. On Fri, Sep 21, 2018 at 1:15 PM Lucio wrote: > > > On Friday, 21 September 2018 11:52:40 UTC+2, Louki Sumirniy wrote: >> >> This is something that I have seriously considered to be the right way >> for Go to express other generic types. I am in fact in the middle of a >> project at the moment where I have created a pair of generic byte buffer >> types, one is the regular kind, the other uses memguard locked buffers, for >> keeping secrets out of reach of other processes on a system. >> >> >>> I like this exposition and I think it has inspired me to a realisation I > have not seen mentioned in the many discussions I have tried to follow, > namely that the existing generics in Go - numeric operators and few > special-purpose intrinsic functions, have a common property: only a very > few operands, something that user generics will no doubt not be restricted > to. > > In other words, there is an overarching "contract" involved that enforces > "simplicity". I don't know what the designers of a generic polymorphism > paradigm can make of that, but I'm sure that much of the blood, sweat and > tears shed so far have been caused in an attempt to extend the complexity > of "generics" in addition to the scope of the receiver, arguments and > result lists. > > I hope this is helpful. > > The other thought I had, but is very poorly baked, is that the "essence" > of polymorphism in Go operators is analogous to the informal definition of > interfaces: it can be determined by the compiler, even though it is not > expressed in a formal notation (the magic of super-types like for example > "numerics" to which the addition operator applies). > > In a nutshell, defining a polymorphic function would entail omitting > explicit type qualifications entirely and allowing the compiler to > determine compatibility from the use of polymorphic operators and > consequently rejecting combinations that, like in interfaces, do not fit > permissible combinations of such operators. Lack of implicit conversions is > then the remaining problem and I have not found (or even sought) a solution > to that, but others' vision will no doubt be further reaching than my own. > > I'm sorry if I'm not expressing my ideas very clearly, this is stretching > my understanding somewhat. > > -- > 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 * -- 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.
[go-nuts] Re: Generic alternatives: new basic types?
On Friday, 21 September 2018 11:52:40 UTC+2, Louki Sumirniy wrote: > > This is something that I have seriously considered to be the right way for > Go to express other generic types. I am in fact in the middle of a project > at the moment where I have created a pair of generic byte buffer types, one > is the regular kind, the other uses memguard locked buffers, for keeping > secrets out of reach of other processes on a system. > > >> I like this exposition and I think it has inspired me to a realisation I have not seen mentioned in the many discussions I have tried to follow, namely that the existing generics in Go - numeric operators and few special-purpose intrinsic functions, have a common property: only a very few operands, something that user generics will no doubt not be restricted to. In other words, there is an overarching "contract" involved that enforces "simplicity". I don't know what the designers of a generic polymorphism paradigm can make of that, but I'm sure that much of the blood, sweat and tears shed so far have been caused in an attempt to extend the complexity of "generics" in addition to the scope of the receiver, arguments and result lists. I hope this is helpful. The other thought I had, but is very poorly baked, is that the "essence" of polymorphism in Go operators is analogous to the informal definition of interfaces: it can be determined by the compiler, even though it is not expressed in a formal notation (the magic of super-types like for example "numerics" to which the addition operator applies). In a nutshell, defining a polymorphic function would entail omitting explicit type qualifications entirely and allowing the compiler to determine compatibility from the use of polymorphic operators and consequently rejecting combinations that, like in interfaces, do not fit permissible combinations of such operators. Lack of implicit conversions is then the remaining problem and I have not found (or even sought) a solution to that, but others' vision will no doubt be further reaching than my own. I'm sorry if I'm not expressing my ideas very clearly, this is stretching my understanding somewhat. -- 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.
[go-nuts] Re: Generic alternatives: new basic types?
This is something that I have seriously considered to be the right way for Go to express other generic types. I am in fact in the middle of a project at the moment where I have created a pair of generic byte buffer types, one is the regular kind, the other uses memguard locked buffers, for keeping secrets out of reach of other processes on a system. A lot of the complaints that lead to the idea of creating a generics system in Go tend to start from the absence of a few basic types. One is the set, and in particular the union operator. However, it is trivial to implement various types of sets and set operations based on maps or slices, and more often than not you save absolutely no time predeclaring a framework when you can just embed a number of other structs inside a type as well as by implementing or composing in interface implementations. But knowing from having done quite a bit of study of data structures, being one of my favourite subjects, that one-size-fits-all only really happens in a very small number of cases. Hash table indexes like used to make maps, arrays and slices, but binary trees, since someone mentioned it, these have many different forms, as dictated by their application. You have heaps and you have trees, the former are better for queues and the latter for optimising searches. There is several ways to implement them. You have B-trees, btrees, red/black, B-heaps, AVL, and so on and so on. These are not really subject matter for basic language types, though the language might improve their use and readability with a number of special keywords and declaration types. I think that the solutions to most of the problems lies in embedding error status into every type (except maybe machine-sized integers), a conditional return statement that allows you you to handle errors concisely within a statement block, and possibly some kind of built-in addition, in addition to the universal error status flag, which integrates some kind of configurable serialisation function for wire and storage. There is many options already available, but to make it simpler to invoke 'freeze' and 'thaw' functions, which provides a data format that can optionally contain type metadata and enable this data to become, no matter what its' type, an object that any other function can pass around and as required see and access parts of the data that relate to the interface. Very small changes, is what I am suggesting. Implicit error type in all but integers, a conditional break/return function (probably one for each) and more generally what I am suggesting is extend the built in 'error' interface to add set, unset and serialise/deserialise functions. And maybe a built-in structured logger that lets you track the state of all variables as each function operates on it, but only automatically in case of throwing an error. I think that go almost already perfectly implements the generic type []byte. Everything can be turned into []byte and []byte can encode any other variable. Go is absolutely a leader in the programming language field. I just saw yesterday a blog post about 'new features in C++17' or whatever, 'that simplify your code'. Every single feature already in Go, the optional first statement in the 'if' structure, type inference through assignment to constants, and somethting else I forget. In every area of the core language, Go uses a pattern that is both simpler and more powerful than you find in most other languages, and that can trivially express many other patterns usually in a far more concise yet readable manner. The changes for version 2, in my opinion, should first identify the real meat of the issues that people point at their previous language experiences to talk about, but go far deeper to decisions about syntax that are in many cases now quite obsolete concerns. In the old days, every byte was so expensive. The price is very low now and basically seems to be flattening out, so people are slowly starting to realise that certain conventions were only based on this bit-conservation. Another issue has to do with creating brittle codebases with excessive need for copy and paste to implement something where in each instance the code only differs by the type of only one variable, that is functionally the same only differing in such as the number of bytes it can encode, sign, or any arbitrary number of other groupings of elements. Go's interfaces and embedding go a long way to neaten this up but this really is at the centre of what needs to be improved, and before anyone actually changes the language, explore the ways of expressing the pattern in go to see if the solution might just be idiom rather than syntax. Most of Go's idiom has been quite certain and settled and you don't take long to see by violating it what extra work and complexity you create. I have pretty high confidence in the Go Authors rejecting all but the simplest, and most
