It's not about bad or useless, the same way Go is not useless because of its current set of constraints. It's about implementing which you can derive the most value of(also in terms of simplicity, code-sharing etc.)
Meta-programming is all-encompassing but it's problematic. Give someone a hammer and everything looks like nails. On Wednesday, January 20, 2021 at 10:35:43 PM UTC+1 axel.wa...@googlemail.com wrote: > 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...@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/1e396ad0-b70f-4ec8-b8e1-abb0b17753f8n%40googlegroups.com.
