FWIW I've published some ideas about how contracts and interface types could be partially unified, and contracts significantly simplified, which I think is quite pertinent to the above discussion.
Doc here: https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69 On 1 September 2018 at 20:15, Scott Cotton <w...@iri-labs.com> wrote: > > > On Saturday, 1 September 2018 20:29:31 UTC+2, Axel Wagner wrote: >> >> I don't understand what you are trying to say. You assert that there >> wouldn't be a type-error, but you don't actually justify that. > > > There are 2 examples, both are (to me) intuitive suggestions and not the > result of a phd thesis worth of research :) continued below. > > > >> It seems pretty obvious to me, that if you instantiate my MultiReader >> example to, say, *strings.Reader, it would fail to compile. Because >> *multiReader is not a *strings.Reader (and you'd have to replace R with >> *strings.Reader everywhere in the signature, that is the exact reason we >> want generics to begin with). > > > That's why I didn't use R for another, distinct Reader. For the signature > of your MultiReader example I changed the return type from "R" (the type > argument) to "Reader" (the name of the contract). In a hand-wavy formal > way, the return type would serve as a new type argument to Reader, > independent of R. Put in an intuitive (to me) way: Since MultiReader > returns something which presumably conforms to the contract Reader, why not > just say that instead of the type argument R? > > >> >> The example you give for "unifying this" isn't actually syntactically >> correct, AFAICT. At least I can't find anything in the design that would >> allow using the identifier of the contract in its arguments - and it's >> unclear to me what that would mean. > > > Apologies, I'm responding to the proposal, just giving my 2 cents. I am not > asserting that the examples I give are syntactically correct according to > the proposal. I am suggesting that the concepts of "contract" and > "interface", can (probably) be defined for Go > in a unified way. I am not supposing the definitions in the proposal of > "interface" and "contract" in suggesting this; to the contrary I am > suggesting these concepts are what Go would define them to be and hence are > flexible and not yet fixed. I do not think saying interfaces and contracts > are different because the proposal or other background such as Haskell or > type theory treat them differently is a convincing counterargument to my > suggestion of exploring the unification of contract and interface. > >> >> >> To provide another way to clarify that interfaces and contracts are >> different: > > > This again assumes a priori interfaces and contracts are different. I am > trying to suggest to drop this assumption and see what happens. To me, it > seems, so far, good things would happen. > >> >> * How would you build fmt.Println using contracts? >> >> * One of the main motivators behind adding generics is the lack of >> type-safety for containers (say, container/list). While all methods mention >> the same type, interface{}, it is not checked for consistency between >> invocations. This is a bug for type-safe containers, but it's a feature for >> fmt.Println. > > > So perhaps containers could use a contract which does not instantiate each > type argument distinctly, forcing uniformity of types and > more or less like in the proposal. And perhaps situations desiring > heterogenous types, such as fmt,*f(), could use a different kind of > contract which instantiates each type argument independently at the call > site. To distinguish them, some syntax could be proposed such as > > contract Reader(r Reader.(*)) { ... } > vs > contract Reader(r Reader) {...} > > I am far from the genius who is capable of thinking this idea through and > making it as solid as the proposal overnight. Just expressing the opinion > that unifying the concepts of contract and interface seems to me like a good > idea to explore, and that a priori assuming they are different doesn't help > advance exploring it. > > Scott > > > > > > > -- > 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.
