Personally, I feel that "let's reduce utility while keeping complexity constant" is a questionable approach, if you feel that generics don't provide enough value to justify their complexity. I feel that *if* we introduce generics, we should make sure they actually pay for their cost. I'd much rather have no generics at all, than a bad and useless implementation of them.
On Wed, Jan 20, 2021 at 10:19 PM atd...@gmail.com <atd...@gmail.com> wrote: > I have been asking because the List of List example seemed a bit > contrieved to me. I have seen maps of linked lists or slice of slices for > math stuff but rarely lists of lists.(probably because of the time > complexity) > > But yes, composing the parametrization is probably not something that > should be possible. Would have to have package List[int] fully created > beforehand via code generation. No recursive instantiation. > > I think I understand the worry more clearly. Paramaeterized packages make > the definition of Higher Kinded operations more difficult. The Transform > function which operates on Lists would be one example. > > This could also be a feature to have some things more difficult to do. I > have no idea on this, I think it would require data on the kind of code > that is needed the most in the wild. > Not sure that the most powerful generics facilities are required. I think > that the current set of constraints of what is expressible via current Go > code is also why it is successful. Namely the small set of identifiable, > common idioms. > If Higher Kinded type of functions are easily created, one could fear that > there wiould be more code styles within the Go ecosystem. > But anyway, it needs data across codebases to see what is required. (I > know that scientific code, ML code will be wildly different for instance) > But yes, I guess would tend to agree with Arnaud. > > Thanks for the answers! :) > > On Wednesday, January 20, 2021 at 9:37:11 PM UTC+1 Ian Lance Taylor wrote: > >> On Wed, Jan 20, 2021 at 11:42 AM 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. >> >> >> I think Axel has expressed the pain points pretty well. >> >> You've got a List package that lets you manage linked lists of some >> type. So you write >> >> import listint "list[int]" >> >> and then you can write lst := listint.New(); lst.Push(1). Or >> something like that. >> >> Now you want a list of lists of int. How do you write that? >> >> import listint "list[int]" >> import listlistint "list[listint.List]" >> >> ? >> >> That is not how imports work in Go. Now import has changed from >> "import a package" to "instantiate an imported package". Those are >> pretty different operations. >> >> Also look at >> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#list-transform >> and think about how to implement that using generic packages. >> >> More generally, there just isn't any clear reason to believe that >> generic types and functions naturally map to package boundaries. It's >> easy to think up cases where I would want an unexported generic >> function. If only packages can be generic, then I have to create a >> new internal package just to represent that function. That seems >> tedious. >> >> You have asked a couple of times for "proposal-killers". I'm not sure >> that there are proposal-killers for attaching generics to packages. I >> think it could probably be made to work. In 2017 Robert Griesemer and >> I spent about six months working up a generic proposal based on >> packages. But in the end we stopped pursuing that approach, because >> there were too many difficulties and awkwardnesses. >> >> Ian >> > -- > 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/92868a82-63f0-48a2-bc40-e3ce5e06a111n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/92868a82-63f0-48a2-bc40-e3ce5e06a111n%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/CAEkBMfEFsrotAxLGh2O2hymieH_%3DHWVYfYH0eGMQ4EismpGr-Q%40mail.gmail.com.
