On Wed, Jan 20, 2021 at 8:42 PM 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. Yes, that's in general what kills proposals. 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. > This seems to be a distinction without a difference to me. You can instantiate a parameterized package from other packages as well, so they also "spread out" in that sense. > 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. > I don't think it would be simpler. I also don't think it would be significantly more complicated. There are two ways, I think, packages would differ: 1. You'd need to spend more effort on syntax to describe constraints and parameters and instantiations 2. You'd need to make sure that the compiler treats different instantiations as different packages and stores and looks them up in the right place. There might be corner cases about cyclic imports, but these, I think, are probably analogous to cyclic references in generic functions/types. The alternative is doing what the compiler does and dealing with constraint > on kinds. Which is a bit more complex. > As I said - the language for expressing constraints is completely orthogonal to whether you constrain the types on packages, or functions. > 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. > I don't really think so. In any case, that is implementation complexity at worst - it is not reflected in complexity for the user. So I don't think it changes anything to how the community would feel about the introduced complexity. 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. > Not just internally. They have to be parameterized externally as well. A package would want to be able to use two different generic list instantiations in the same function, so the identifier by which they refer to the instantiated package needs to be different for the different instantiations. 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. > To repeat: You know the pain points. You just don't think they are that painful. Which is fine. > > > 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 >> <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md> >> 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 >>> <https://groups.google.com/d/msgid/golang-nuts/7ba98154-ecee-4657-9985-ce21a80c68c2n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 > <https://groups.google.com/d/msgid/golang-nuts/913e84ad-1ab7-4a9a-aa5a-656d846cc203n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfEFaXGgTDLA%3D%3D3W7hdrr%2BwfWFczLYJQmTpJG8%2B0RT77ag%40mail.gmail.com.
