Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Eric you ostensibly forgot about the type of a callback function whose body varies at runtime and thus is statically unknowable. This is why the type of the function has to be typed for the contracts it requires. On Wednesday, October 17, 2018 at 4:37:01 AM UTC+8, Eric Raymond wrote: > > > > On

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

I’ve updated my gist at https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890 to use contracts as adaptors. Andy > On Nov 6, 2018, at 8:27 PM, Andy Balholm wrote: > > It is implicit: the functions defined i

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

It is implicit: the functions defined in the contract are available (in scope) in generic functions that use the contract. I’m thinking about revising how the adaptors work. I might let contracts act as adaptors. But I don’t have time to work on it any more today. Andy > On Nov 5, 2018, at 7:

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Steven Wiley (2018-11-05 22:12:40) >And let's face it. Templates, operator overloading, and talk of >generics has swirled around golang since its inception. Separating the >template/generic/operational overload step from the core language via a >pre-compile step� is one wa

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

The word "elegant" comes to mind... Comments below. On Monday, 5 November 2018 21:47:46 UTC+2, Andy Balholm wrote: > > The concept of using operators to implement methods cross-pollinated in my > mind with Patrick’s “Go Generics with Adaptors” thought experiment and > produced this: > https://g

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Hi all, There appear to be a lot of different paths to take as far as generics and templates go (pun intended). Many of you I am sure have more experience and have thought deeper about contracts and templates than I ever will. Also, I am sure all experienced users and programmers know the joys

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

The concept of using operators to implement methods cross-pollinated in my mind with Patrick’s “Go Generics with Adaptors” thought experiment and produced this: https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Saturday, 3 November 2018 22:41:08 UTC+2, Andy Balholm wrote: > > I thought of a way to do something similar to the “implements” proposal > without introducing operator overloading: turn it around. Instead of > letting methods implement operators, we could let operators implement > methods.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Andy Balholm (2018-11-03 16:40:39) > But if a mis-matched type was passed to Less, it would need to panic. > So this option (using the Self type) would somewhat reduce > compile-time type safety. This is why I left `self` out of my own proposal; while I agree it would be more ergonomic, i

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

I thought of a way to do something similar to the “implements” proposal without introducing operator overloading: turn it around. Instead of letting methods implement operators, we could let operators implement methods. type Lesser(type T) interface { Less(b T) bool for(<) } This interf

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Sunday, 28 October 2018 15:13:23 UTC+2, Scott Cotton wrote: > > Hi Marvin, > > I think a lot of us like the fact that when we see "a == b" in Go we know > what it is without looking up a redefinition somewhere. > To me, "a (==) b" is better if there is operator overloading, but I don't > like

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Hi Marvin, I think a lot of us like the fact that when we see "a == b" in Go we know what it is without looking up a redefinition somewhere. To me, "a (==) b" is better if there is operator overloading, but I don't like it in any case. One problem with operator overloading is that, to use opera

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

* Ian Lance Taylor [181016 17:59]: > The contract system in the generics design draft does not have this > problem. It may have other problems, but it doesn't have this one. I haven't finished reading the draft (I got to the beginning of the Contract Details section when it was first mentioned o

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Eric Raymond (2018-10-16 17:28:11) >Fair enough. But is there any way to have a contract system of *any* >kind that doesn't have the identical problem?� Linked elsewhere in this thread, but I sketched something that I think does the trick: https://gist.github.com/zenhack/ad50

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tue, Oct 16, 2018 at 2:28 PM, Eric Raymond wrote: > > On Tuesday, October 16, 2018 at 4:52:54 PM UTC-4, Ian Denhardt wrote: >> >> The trouble is that (in the case where you compile using the implements >> <, rather than throwing an error) the type signature no longer tells you >> what the const

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:52:54 PM UTC-4, Ian Denhardt wrote: > > The trouble is that (in the case where you compile using the implements > <, rather than throwing an error) the type signature no longer tells you > what the constraints actually are; this information is only in the body

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:41:53 PM UTC-4, Dave MacFarlane wrote: > > Now I'm confused about what problem regarding generics you're trying > to solve with operator overloading. If you can't assume anything about > the meaning of an operator other than "it returns a bool", how could a >

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Eric Raymond (2018-10-16 16:37:01) > you either compile "a < b" using the "implements <" method of the > concrete type or throw an error. > This means that a change in the generic function, which happens to > introduce a new use of the parameter, can cause a failure at the >

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:17:36 PM UTC-4, Ian Denhardt wrote: > > What is this intended to buy us? Is this as Ian T suggests in lieu of > any kind of contract system? Oh , no. You *need* a contract system (or at least my implements clause) so you can know if a < b has a meaning when

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Dave MacFarlane (2018-10-16 16:40:59) > (Also, does this mean the compiler wouldn't be able to make any > optimization assumptions regarding whether an operation is > commutative/associative/distributive?) This is true regardless, because we aren't actually *enforcing* these properties; t

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tue, Oct 16, 2018 at 4:14 PM Eric Raymond wrote: > If the alternative is requiring programmers to remember pre-cooked > relationships between different operators that may or may not be appropriate > for what he or she is trying to model, then I embrace this "problem". > > It's up to the progr

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:03:16 PM UTC-4, Ian Lance Taylor wrote: > > It's a feasible approach. But unless I misunderstand, testing > arguments at the call site means that you've discarded contracts. > I don't understand that claim. A contract (in my plan, an "implements" clause) is

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Eric Raymond (2018-10-16 16:14:46) >It's up to the programmer to implement things like commutativity.� I >don't think the language should pre-specify whether < is a partial or >total ordering.� Any choice of this kind the language makes will >inevitably turn out wrong a s

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Ian Lance Taylor (2018-10-16 16:02:57) > On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond wrote: > > > > New rule: A function on variables of undefined formal-argument types > > compiles to a template (not a textual template - we don't want identifier > > capture). At each callsite of the fu

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

(Sorry about the post fragment that got away from me.) On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote: > > > The alternative though is having to implement several different methods > with obvious implementations in terms of one another, and make sure > they're consistent.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond wrote: > > New rule: A function on variables of undefined formal-argument types > compiles to a template (not a textual template - we don't want identifier > capture). At each callsite of the function, the undefined types in the > formals are bound to

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Eric Raymond (2018-10-16 15:57:49) >I don't undetstand rte q rte q? I assume this is a typo, but I'm not sure what it was supposed to be... -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop recei

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote: > > > The partial vs. total order thing brings up another issue that I think > needs to be kept in mind: what are the contracts for the various > operators? > I don't undetstand rte q -- You received this message because

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Eric Raymond (2018-10-16 13:41:47) >On Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane >wrote: > > [...] > > Would there be any rules defined for relationships between > operators? > For instance, if the "<" operator is defined does "<=" come for free >

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane wrote: > > Why is the implements keyword a better solution than magic names? > Because you get syntactic uniformity with primitive types without claiming namespace you don't need. It's more minimalist. Would there be any rule

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Why is the implements keyword a better solution than magic names? Magic names feel more Go-ish to me in the sense that interface implementations already eschew the implements keyword (unlike most other languages) and don't require any syntactic changes to the language. Would there be any rules def

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Ian Lance Taylor (2018-10-16 09:44:00) > It's not clear to me what other aspects of various generic proposals > you are picking up here. How are you imagining that we would write > the function that merges two channels? With the current design draft > that looks something like this: > >

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tue, 16 Oct 2018 08:39:32 -0700 (PDT) Eric Raymond wrote: > New rule: A function on variables of undefined formal-argument types > compiles to a template (not a textual template - we don't want identifier > capture). At each callsite of the function, the undefined types in the > formals ar

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 9:44:23 AM UTC-4, Ian Lance Taylor wrote: > > It's not clear to me what other aspects of various generic proposals > you are picking up here. The answer is "none of them". That wasn't my goal, because all the previous generics proposals I have seen struck me as

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Mon, Oct 15, 2018 at 7:24 PM, Eric Raymond wrote: > > Recent discussion of possible generics designs has forced me to a conclusion > I'm not happy with, because it requires a feature-cluster that I thought I > was glad to be leaving behind in Python. That is this: > > The simplest and most ef

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Cute. I think we're better off without it though; the use cases I can think of for "generic booleans" are all way too clever. FWIW, the uses of "generic booleans" I've seen in the wild don't actually work with your proposal, because they really do need to overload `and` and `or`, not just `not`. B

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:59:44 PM UTC-4, Ian Denhardt wrote: > > I'm not in love with the inconsistency, and expect it to cause some > confusion with newbies, but I'd have to use it to see how big of a > footgun it is in practice. There are certainly worse ideas. > Yes. If that's th

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:32:23 PM UTC-4, Eric Raymond wrote: > > Fair enough. I am completely willing to discard the possibility of > overloading && and || > A little thought showed me that this is not required. The straightforward way to write the contract of "!" would be that it is

[go-nuts] Generics: an unwelcome conclusion and a proposal

I agree that operators in contracts and the proposed generics don't seem to mesh well. Your proposal would enable the use of operators in interfaces in an easy way. However, personally I think that perhaps we don't need operators at all. Suppose I was to implement a generic btrie or such today

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Eric Raymond (2018-10-15 23:32:22) >Fair enough. I am completely willing to discard the possibility of >overloading && and || and almost any other operator that doesn't behave >like a function, because I think we get a rich enough set of contracts >from those that do. As

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:02:18 PM UTC-4, Ian Denhardt wrote: > > > There are other operators in the language that don't behave like > functions or methods (e.g. boolean operators like && and ||, which > short-circut), but the rest of them are things that don't have gobs of > use cases

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

Quoting Eric Raymond (2018-10-15 22:24:50) >The simplest and most effective way to solve the generics problem is to >embrace operator overloading and the kind of magic method designations >that go with it. This matches my intuition as well, though see below. >Can it even possibly

[go-nuts] Generics: an unwelcome conclusion and a proposal

Recent discussion of possible generics designs has forced me to a conclusion I'm not happy with, because it requires a feature-cluster that I thought I was glad to be leaving behind in Python. That is this: The simplest and most effective way to solve the generics problem is to embrace operat