On Sun, Jul 23, 2017 at 10:17 AM 'meta keule' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
>
> Hi,
>
> here is a proposal for an alternative to Generics for Go2:
>
>
>From a quick skim:
It looks like you are trying to discuss a combination of three things:
* universals
* type inference
* type variables
For each, it looks like you are placing some rather arbitrary constraints
on these in order to make the system sound w.r.t. other Go features. I
think much can be gained by splitting up the discussion into the handling
of type variables and universal functions, if you want to go down this path.
Universals are a generalization which is possible whenever a function
doens't depend on a particular type. For instance, in the function
func len(arr []int) int {
count := 0
for _ = range(arr) {
count++
}
return count
}
There is no dependence on the fact that the array is an 'int' so we could
as well write 'func len(arr []$A) int' in your notation. Languages with
(full) type inference can figure this out by making *all* types into
metavariables and then look at what types variables must be, based on type
constraints. In the above, the metavar generated for '$A' will have no
constraints which is why it can be generalized into an universal.
Type variables already exist in Go, but they are limited to built in
structures of slice and map types. When we write []int, we really
instantiate a type []$A into []int. Likewise for a map. If I construct my
own type, for a RB-tree say, then I can't get at this generalization but
must use interface{}. For each use I would have to build my own wrapper API
in order to make the usage of my RB tree type safe.
Any generic proposal must address the two above problems at the least. I
must also address how to mix those into the existing interface concept,
which will give rise to how generics will work in Go if added.
Another viable path is to stratify generic instantiations to be at the
package level. That is, you can declare a
package foo<T>
for some abstract type T. Use of the package by import will expand T into a
concrete type. A more ambitious solution would generalize this by noting
that each package has a *signature* which is the set of exported types and
functions. We'd like to then say
functor foo<P : Sig>
to say that foo is a module level function (a functor) which takes a
package P as a plug-in with signature Sig. Generic programming is then
handled by plugging in concrete implementations at the package level rather
than at the module level. For a concrete type 't' you can simply refer to
P.t in the foo package/functor.
All of these ideas already exist and have working precedents in Standard ML
or OCaml.
My hunch is that most constrained attempts at generics are likely to fall
short in usage examples. That is, there is no easy way out: you have to
address the problems up front. In Go, you'd have to handle the interface
concept and generics. But my intuition is that this is possible because
interfaces look a lot like existential types which have good support in the
litterature together with the abstractions mentioned above.
--
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.
For more options, visit https://groups.google.com/d/optout.
