Just coming back to this quickly, although it is unlikely to change
anything at this stage, but, re. a transform function, instead of using
parametric polymorphism, I think it is possible to do it with interface
arguments and to a greater extent, type lists interface arguments if we
have access to these in the future..
It would require to have the transform function in its own package. I don't
expect it to be a big problem as I do not think that a transform function
require full-parametricity: to transofrm a list of U elements into anoter
list of V elements,
I would tend to think that U and V need to be known in advance. A purely
generic transformation seems a bit of a red herring to me.
So, not so sure that it would be a counter argument to package
parametrization.
However, the only example I may conceive to be a bit annoying is providing
a "seemingly" single generic Max function, If for instance, we want the
math package to be a regular package that also expose a few generic
functions.
I would tend to think that this is where it would be difficult to bind the
type of the argument with the type of the return value with only type lists.
With a package parametrization, we would have to introduce a math/generic
package and have something like:
import (
mint math/generic [type T= int]
mfloat math/generic [type T=float]
If we have code that requires Max on ints and floats within a same package,
that would make people have to use 2 different max functions, (just like we
do these days anyway)
mint.Max(2,3)
mfloat.Max(2.0,3.0)
No opinion on this. I don't think it would bother me but...
Am I missing something?
On Thursday, January 21, 2021 at 4:37:17 PM UTC+1 atd...@gmail.com wrote:
> 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/b012c91a-c408-4ae6-a20b-b35019e7ec2cn%40googlegroups.com.
