FWIW, personally, I believe if you make it painful to write generics, what will happen is that people will write generic code and complain about how painful it is. I don't think the outcome will be that people will use it less. If someone thinks they need generics and wants to use them, they will.
On Wed, Jan 20, 2021 at 9:13 PM Arnaud Delobelle <arno...@gmail.com> wrote: > Hello > > FWIW I had a go at imagining a way to make a variant of your idea > (package-level parametrisation) work. At the time my principal worry > was contracts and I was keen to use interfaces instead to express > parametric constraints: > https://arnodel.github.io/marooned/go/generics/2020/06/06/go-spec2.html > > I posted it on golang-nuts a while ago. Here is a link to Ian Lance > Taylor's reply on this list pointing out some shortcomings: > https://groups.google.com/g/golang-nuts/c/Plq8DkScDW8/m/ig5NuDpXBgAJ > > Although I don't think my proposal was very good, I also think it was > an attempt to limit the power of generics in the language. I have a > feeling that in order to avoid abuse of generic code you need to make > it less easy to reach, especially less easy to write generic code > (using it should be easy I think!). Restricting to package-level > parametricity means that there is an obvious trade-off in writing > generic code: you have to make a package for it. > > Cheers, > > Arnaud > > > > > On Wed, 20 Jan 2021 at 19:42, atd...@gmail.com <atd...@gmail.com> wrote: > > > > > > It didn't seem to me like proposal-killers enoguh so much so that they > might not have liked some of the design choices they entailed. > > > > The proble with the current running proposal is that it is a > generalization fo what the compiler does. It definitely permits the spread > of generic functions across package boundaries since they can be exported. > Only that the type inference allows to not have to express the constraints > in most cases. This is still a complication. > > > > What I'd like to know is what are the complexities in a > package-parametrization. Indeed it would require additional syntax for > package import, there would still be a problem with zero-values return. But > it could be so much more simple other than that. > > > > The alternative is doing what the compiler does and dealing with > constraint on kinds. Which is a bit more complex. > > > > As far as deriving constraints from code, I think that it's actually > completely different at the package level than doing it at a higher > granularity ( functions) because a function is not a compilation unit. > > It is similar to essentialy replacing a name and building the package. > > At the function level, I would presume that more information about the > flow of data would be required. > > > > As a note, I think that with the first iteration of type aliases, people > had started experimenting with such parameterization(I think in the image > package). Seems a bit more intuitive. > > Obviously, the difference is that packages are uniquely identified by > their names which is why, the names have to be internally parameterized as > well. > > > > I think that dividing the design space for parametricity into simple > code parametrization at the package level and type list interfaces on the > other hand could be clearer and easier to handle but I'd like to know what > are the pain points. > > > > > > On Wednesday, January 20, 2021 at 8:22:07 PM UTC+1 > axel.wa...@googlemail.com wrote: > >> > >> The proposal-killers are mentioned - it is awkward for different > instantiations of the same package to interact and there is no reason to > believe generic usecases will delineate neatly into packages. It sounds > like you do not agree that those are proposal-killers. And of course, you > are welcome to write down your own design and maybe you even see something > they didn't see. But you should be prepared that ultimately, in a "agree to > disagree" situation, if the Go team feels it is awkward, their opinion will > be what tips the scales. > >> > >> On Wed, Jan 20, 2021 at 7:09 PM atd...@gmail.com <atd...@gmail.com> > wrote: > >>> > >>> Also, the distinction I see is that it would not be the same > instantiation of the same package as much as the creation of new packages ( > the package names should be parameterized too depending on the input) > >> > >> > >> Just to point out the obvious, that this means you still have to make > up a syntax for type-parameters and instantiations. So, this is not a > simple matter of importing a regular package. > >> > >>> Having different packages for different kinds seems to be a good > separation of concerns to me. Quite the opposite from mixing package > boundaries with types, I think it's rather the opposite. (the oppsoite > being to allow generic functions spreading across package boundaries) > >> > >> > >> Generic functions do not spread across package boundaries. Every > generic function and every generic type will still live in a single package. > >> > >>> > >>> it's more complex to write (constraints) > >> > >> > >> FTR, the way to express constraints is largely independent on whether > you constrain types on a per-function/type or per-package level. > >> For example, you suggested constraints should be derived implicitly > based on the operations used in the package. But you can do that with > generic functions too. For example, a previous incarnation of the generics > design would have allowed you to specify constraints by writing a function > body using all operations you need. In particular, you could've used the > function body itself as a contract. So if you take that design and just > declare that the contract of a generic function is *implicitly* its > function body, you'd get your idea of "constraint-less generics", while > operating entirely on a per-function level. > >> > >> That previous incarnation was abandoned though, because it turns out > that implicitly deriving constraints from code is just surprisingly > complicated, opens up more questions than it answers and - in my opinion at > least - just generally a very bad idea. So, I'm not too optimistic about a > new proposal, that tries to go back to that approach. > >> > >> In any case. As I said, my goal isn't really to convince you that your > approach won't work - just to explain why I don't think your approach is > likely to get accepted. > >> > >>> (Namely, the introduction of the functional patterns such as > map/transform/reduce. (which is nothing but an abstraction... nice for > people who appreciate it but not necessarily as a generic function imo)) > >>> > >>> The rest of use-cases for generics could be handled with interfaces > and/or the introduction of type-lists, enabling union/sumtypes, essentially > augmenting the concept of interface types. > >>> > >>> > >>> On Wednesday, January 20, 2021 at 6:21:10 PM UTC+1 jake...@gmail.com > wrote: > >>>> > >>>> If I understand correctly, this question is specifically addressed by > the design draft: > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages > >>>> > >>>> On Wednesday, January 20, 2021 at 10:22:19 AM UTC-5 atd...@gmail.com > wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> It' has probably been discussed somewhere but I am curious about > what might have been the issues when considering an implementation of > generics that would parameterized packages? > >>>>> > >>>>> The rationale being that usually, packages have a non-mutable > interface for the user and are the ompilation unit if I'm not mistaken. So > why not just relax the interface exposed by a package and allow for > package-wide type specialization? > >>>>> > >>>>> In terms of pure parametric polymorphism, having packages with a > mutable interface in terms of types (via mutation of type aliases for > instance) would just be the next iteration. It may require a little bit > more from the build tool but the type checking would not have to change I > think. The constraints on the parameter would stem implicitly from the code > within a package in terms of operations used and interfaces being > implemented. > >>>>> > >>>>> I would expect such "parameterized" packages to be rare, > non-pervasive if not for the simple fact that most parameterized package > would mostly be able to import other generic packages since they would be > defined with abstract types. The compiler may still want to insure that the > constraints make sense throughout the dependency tree of generic imports > incrementally but I don't think that that would be a huge problem. > >>>>> > >>>>> I think that it could be something orthogonal to the design of type > constraintd, notably type Lists, that are anyway highly desirable imo but > more so to constrain interfaces to a finite set of types ( as a way to have > union types, enums, sumtypes or whatnot). > >>>>> > >>>>> > >>>>> > >>> -- > >>> 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...@googlegroups.com. > >>> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7ba98154-ecee-4657-9985-ce21a80c68c2n%40googlegroups.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. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/913e84ad-1ab7-4a9a-aa5a-656d846cc203n%40googlegroups.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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAJ6cK1Yb%3DkdvXFuubWCW_iRvDckt8PZEhP42fmj97uT-3u4fMA%40mail.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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEm0PjgN%2Bkg2SkqOZe14wGqp%2B%2BhoZRk2Hv%3DjW1UiE1MEQ%40mail.gmail.com.
