LWN: Comments on "Generics for Go"

Generics for Go

mcortese — Mon, 10 Aug 2020 23:14:21 +0000

I'll tangentially note that a problem with 3 horns is not a "dilemma".

Generics parameter syntax

anton — Fri, 17 Jul 2020 17:08:32 +0000

I expect that symbol table lookup in the parser is not a performance problem. It is a conceptual problem because you need to know the parse tree to know the scope of an identifier; of course, for some kinds of languages the problem is solvable (LL(1) languages with definitions before use of symbols should be fine), but it means that the language requires an integration of parsing and "static semantics". And possibly scanning, if, e.g., the syntax requires a token for a type that's separate from an identifier token.

Generics for Go

jch — Thu, 16 Jul 2020 10:17:49 +0000

> there was a language ML

Why in the past tense? ML is doing fine, the dialect with the most active community would appear to be OCaml, https://ocaml.org/ . (It looks to me like ML was an important inspiration for Rust.)

Generics for Go

renox — Thu, 09 Jul 2020 17:10:24 +0000

I wonder why everyone just doesn't copy DLang solution: using !( ) for generics: no ambiguity, no need to hack the parser, no conflict with with arrays.

Generics for Go

briangordon — Wed, 08 Jul 2020 21:34:29 +0000

So I guess the suggested usage is still to use interface{} when there are no type constraints...

func Keys(type K comparable, V interface{})(m map[K]V) []K {

That being said I do think the choice to forgo covariance and contravariance in favor of simply talking of type constraints as interfaces is very golang. Not exactly the language I would prefer to use but it's at least consistent.

Generics for Go

mathstuf — Wed, 08 Jul 2020 13:41:31 +0000

> but you're already going to have to do kind-checking there anyway (i.e. to prohibit Int<List> and similar errors), so additionally checking that the argument *is* a type isn't really that much more work.

But you don't want your AST module to have to decide that. It feels like a layering violation to me.

Generics for Go

ncm — Wed, 08 Jul 2020 06:58:38 +0000

C++ generics do not, in fact, draw on Ada generics, and the Ada attempt at an STL was a dismal failure, as it would also be in Java were it attempted.

C++ generics do owe a lot to ML (not "machine learning"; there was a language ML that also influenced Haskell). Java generics are extremely limited, and their backward compatibility means they offer no performance improvement over older mechanisms.

Generics for Go

NYKevin — Tue, 07 Jul 2020 20:49:46 +0000

> When parsing code within a function, such as v := F<T>, at the point of seeing the < it's ambiguous whether we are seeing a type instantiation or an expression using the < operator. Resolving that requires effectively unbounded lookahead. In general we strive to keep the Go parser efficient.

Eh... Python used square brackets to solve this exact problem (which had the bonus of being entirely backwards-compatible with their existing syntax; Python's types are "just" variables pointing to class objects, so applying the subscript operator was already syntactically legal). Perhaps Go didn't want to parse generics as an extension/generalization of the subscript operator? I suppose that saves you the trouble of disambiguating generics from "classical" subscripting at the semantics layer, but you're already going to have to do kind-checking there anyway (i.e. to prohibit Int<List> and similar errors), so additionally checking that the argument *is* a type isn't really that much more work.

Maybe they just thought that parentheses were less ugly than square brackets?

Generics parameter syntax

dtlin — Tue, 07 Jul 2020 12:19:23 +0000

It helps for that case, but if you have higher-order kinds, f<t> is also a type, for some appropriate type variables f and t.

Generics parameter syntax

dezgeg — Mon, 06 Jul 2020 20:38:38 +0000

Haskell was just an example of some other language where caseness of a name matters (but apparently even Go already uses it in other manner). I was thinking about having names starting with Uppercase always refer to types and names starting lowercase be variables. Thus in the v := F<T> example the caseness of F would tell whether the < is the less than operator or the opening bracket of a type parameter.

Generics parameter syntax

dtlin — Sun, 05 Jul 2020 22:23:28 +0000

In Haskell, types do begin with an upper-case letter or : symbol, but data constructors (which are values) also begin with an upper-case letter or : symbol and type variables begin with a lower-case letter or non-: symbol, so that's not useful for disambiguation.

But only values appear to the left of :: and only types appear to the right of ::, so there's no confusion. Except in import lists, or when -XTypeApplications, -XDataKinds, -XStarIsType, … No angle brackets so it doesn't suffer from C++'s problems though.

Generics parameter syntax

Cyberax — Sun, 05 Jul 2020 19:11:53 +0000

Go uses upper case names for exported symbols and lower-case names for package-local ones.

Generics parameter syntax

dezgeg — Sun, 05 Jul 2020 10:06:23 +0000

In some languages (Haskell comes to mind, also Erlang I think) case-sensitivity is used to enforce this kind of problems without requiring a symbol table in the parser. In Haskell, uppercase names always refer to types or type constructors; and lowercase names always refer to variables or type parameters. Sadly not many new languages seem to take use of this as I personally find it quite elegant.

Generics parameter syntax

mathstuf — Sun, 05 Jul 2020 02:26:46 +0000

Note that I actually don't know how Go's parser in particular works. I surmise that the parser requiring access to a symbol table would be unacceptable for performance. It'd be better to let the parser go and make ASTs for all the source and only then figure out what symbols are defined where (using the imports as a guideline). In fact, the mere existence of the AST module in the standard library likely means that symbol tables cannot be allowed (because requiring `import` to actually do work and look at what symbols are available just to parse `sym<arg>` would be a little ridiculous IMO).

Generics for Go

cpitrat — Sat, 04 Jul 2020 08:26:55 +0000

"(The C approach.) Leave them out. This slows programmers. But it adds no complexity to the language."

Actually the C approach is drop the safety net (typing) and use (void *)

"The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?"

Actually the first option's issue is not slow development, it's choosing between loosing type safety or duplicating code which in both cases, means higher risk of bugs. Yes it also means slower development, but not by a huge amount and that's not a big issue.

Generics for Go

cpitrat — Sat, 04 Jul 2020 08:19:33 +0000

IIUC, this is conceptually like the C++ approach but with a nicer syntax (same as the language rather than a dedicated one). AmI missing something?

Generics parameter syntax

davecb — Fri, 03 Jul 2020 22:39:24 +0000

Thanks: I come from an era when we assumed a symbol table, and so did not realize Go does not have one in it's parser. Rather amazing!

Generics parameter syntax

mathstuf — Fri, 03 Jul 2020 18:49:22 +0000

How complicated can `T` get syntactically? Can you decide before you see the `>` somehow? This is the reason for the weird `obj.mem1.mem2.template foo<T>` syntax in C++: T can be very complicated and "type or expression" is not something one can answer without actually having a name lookup table.

Generics parameter syntax

davecb — Thu, 02 Jul 2020 15:34:31 +0000

I rather wonder if v := F<T> can be parsed both accurately and efficiently with strongly bounded lookahead?

Generics for Go

ragnar — Thu, 02 Jul 2020 09:32:23 +0000

I really like the approach zig has taken with generics. They simply have types as compile-time parameters to functions and data structures.

https://ziglang.org/#Generic-data-structures-and-functions

Generics for Go

k3ninho — Thu, 02 Jul 2020 08:25:35 +0000

>Not that I know much about Go
Read the "Featherweight Go" journal article [1] and its parent, "Featherweight Java"[2]. I think Rob Pike looked and though Featherweight Java more relevant because of the user-facing side of Go is more like the C++/C#/Java kind of object orientation than the approach taken by Ada. You should be heartened that both Featherweight approaches prove (rather than merely providing) type safety.

K3n.

1: https://arxiv.org/pdf/2005.11710.pdf
2: https://dl.acm.org/doi/10.1145/503502.503505

Generics for Go

dvdeug — Wed, 01 Jul 2020 20:27:46 +0000

How is this related? Go seems like a decidedly different language for a decidedly different audience. What's the expected win from native compilation? https://benchmarksgame-team.pages.debian.net/benchmarksga... says that C# already ties or beats Go on every single problem.

Generics for Go

Cyberax — Wed, 01 Jul 2020 20:17:18 +0000

> Though surely Java too, these days, lets you create a vector of ints without having to box each one?
Nope. That's on the TODO list, though: https://openjdk.java.net/projects/valhalla/

Generics for Go

epa — Wed, 01 Jul 2020 20:15:40 +0000

Yes, I was surprised not to see C# mentioned in the discussion, since it seems to avoid the macro expansion approach of C++, while not suffering the boxing overhead of Java. (Though surely Java too, these days, lets you create a vector of ints without having to box each one?)

Generics for Go

dvdeug — Wed, 01 Jul 2020 19:53:19 +0000

C++ templates were designed after Ada generics, and Alexander Stepanov, who wrote the Standard Template Library for C++ and pushed for C++ templates with Bjarne Stroustrup, did his first proto-STL in Ada. So C++ and Java should show a more refined form of Ada generics.

Personally, I've worked with Ada generics. The Ada type system added complexities in places that don't seem to have wins in retrospect, and Ada generics reflect that. They don't have the sheer power that C++ templates have, or the usual elegance of Java. I'd be interested to see languages from a universe where Ada was more successful and modern languages stuck more to its design principles, but in any case, Ada generics were the first major generics implementation, and it shows.

Generics for Go

acarno — Wed, 01 Jul 2020 19:13:04 +0000

Not that I know much about Go, but why not look at generics in languages other than C/C++/Java? For example, Ada has (strongly-typed) generics:
https://www.adaic.org/resources/add_content/standards/05r...

Generics for Go

kjp — Wed, 01 Jul 2020 17:21:35 +0000

If only google and msft could team up and get native compilation going for C#. Nope, gotta be NIH.

Generics for Go

Cyberax — Wed, 01 Jul 2020 16:44:35 +0000

I'm honestly amazed by Ian Lance Taylor. He's active in most of discussions about generics and always takes time to calmly discuss questions and explain issues.