undefined | Better HN

0 pointsatombender5y ago0 comments

Agreed. To keep Go simple and keep it from descending into the kind of extreme generics that Rust practices (nothing wrong with it, but it seems antithetical to Go's simplicity), the idea behind my syntax suggestion is to think about monomorphization as an explicit concept.

You're basically telling the compiler to generate new versions of the same function, or struct, or whatever. The mental challenge with just adding type parameters is that you're thinking of the type as generic, which creates "what colour is my code" distinctions; either types are generic or they're not.

I had another syntax in mind that would reuse the "for" keyword:

  for type T:
    func Max(a, b T) T {
      ...
    }

Both syntaxes work fine for other declarations; structs and methods, for example:

  for type T:
    type Atomic struct {
      v T
    }

  for type T:
    func (a *Atomic) Get() T {
      ...
    }

Of course, you still need some syntax to specify types in expressions, but that's also solvable.

0 comments

_y5hn5y ago

Parametric polymorphism should probably be very syntactically distinguishable from imperatively looping with "for", though you'd need constraints and multiple types for sure.

The problem from the start with such kind of programming, is that once you start meta-programming, there's always a bunch of stuff you could be missing or adding to the implementation. Just right up to the point where you could be implementing or self-referencing the language in the meta-program itself, or vica versa. But doing this without adding too much complexity for normal everyday use, would either be genius or a failed attempt at keeping things easy.

So I'm sure many are investigating all the use cases what the target should be. Though the end result should still be easy, readable and otherwise clearly distinguishable from other idioms of the programming language.

j / k navigate · click thread line to collapse