Looking briefly, seems interesting but slightly different. It seems that the intent described in the paper is to endorse full blown functions as a replacement to import statements.
It is useful insofar that it could rationalize the use of build constraints in Go. But it is too expressive in that it may obscure which packages are actually imported amongst other things. For instance, it allows to branch and decide on different implementations for hashmaps depending on a size parameter. This is a bit different from what I had in mind as I think that generic packages should be encapsulated and would simply expose a simple interface to some of their internal state (mostlly allowing to replace type names). The consequences would be a bit different Ibelieve. That is another example where I think, too much power is granted to the programmer, in the sake of generalization. Now, the evaluation of import constraints may slow down the build of large programs arbitrarily, and, as you mentioned, it requires package to be virtualized (because their definition/instantiation is not static anymore) which I don't think is desirable. The advantage of doing things a bit more simply is that we could decide to save parameterized packages to files via code generation if required. The constraints are static. (I really appreciate everyday that Go is not "over-engineered") On Thursday, January 21, 2021 at 2:54:19 PM UTC+1 jesper.lou...@gmail.com wrote: > On Wed, Jan 20, 2021 at 4:22 PM atd...@gmail.com <atd...@gmail.com> wrote: > >> 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? >> >> > You can take a look at Standard ML / Ocaml "functors" if you want to see > an exploration of what it entails as a consequence. It's a completely > different approach, and often you'd find you need to improve the > module/package system of the language in order to make it feel fluid for a > programmer. For Go, it would require quite some language extension before > it would be viable (or rather, that is my hunch). One particular important > point is that you tend to end up with a "stratification" of sorts. The > module system becomes a language of its own, on top of a core language and > they don't mix. The stratification isn't required though, as shown by > Andreas Rossberg in his 1ML paper. In Go terms, you remove structs, and a > struct is a package containing a "var" section. Now, parameterization of > packages becomes parametrization of interfaces/structs as a result. What > Rossberg shows is that you can create a language out of this idea, and said > language "works" insofar it's possible to give it a sensible semantics. > > Note: for this to work, you really want packages to be nestable inside > packages. And you also want to decouple packages entirely from the file > system, by which time you have a language entirely different from Go. > > -- 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/920510e8-36a4-4f86-a7c5-ffc9adb313afn%40googlegroups.com.
