5 ms·

While skimming, I find the article-examples largely unreadable compared to idiomatic Go. You'd almost require generic-aware syntax highlighting in order to grok

by loopz 6y ago

While skimming, I find the article-examples largely unreadable compared to idiomatic Go. You'd almost require generic-aware syntax highlighting in order to grok complex syntax, which breaks normal readability. Experimenting with wrapping as you suggest, seems a good way to see if that separates concerns in syntax enough to make generics "fun again". Programmed for long time in C++ w/templates . Any and everything that avoids the hells of those syntax and compiler error/messages, could even be called innovative if hitting the right spots. I see generics as convenience, but only if the costs doesn't accumulate over time * complexity. Generics need to be something natural, not bolted onto a language, or sneaked in. Unlike precompiler defines, and templates to some degree. To that end, maybe it deserves its own nomenclature, form and space, to properly distinguish those special cases from more concrete cases of syntax. Just like we distinguish looping with "for".

atombender 6y ago
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.
- loopz 6y 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.

by loopz 6y ago

atombender 6y ago

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.

loopz 6y 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.