On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye <xiezhe...@gmail.com> wrote:
> Gramma of a programming language is not able to be changed after released. > So language design is elegant or not is more important than difficulty of > implementing. > > Adding type information in parse time and use angle brackets only affects > compiler and 3rd part tools or IDEs in a short time. > No, it creates lasting downsides. While programming, the normal state of a program is to be broken in some way. And a tool that requires type-information thus can only work on a correctly typed program. So, requiring type-information for parsing will ultimately make many tools less useful by a *lot*. Think about goimports for example - it *inherently* only is used when full type-info is not available, by its very nature. In general, I really dislike these arguments, that it's just implementation complexity and thus doesn't matter. Humans need to parse the language as well, to read and write it. And they'll have exactly the same problems. A simple grammar doesn't just simplify things for parser-authors, it also is vital for the people actually using the language. > Providing parser tools and packages can help 3rd part tools/IDE to support > new gramma. And for professional IDE provider, process generic go code will > not be more difficult than other language like Java, TypeScript etc. > > On Wednesday, July 15, 2020 at 6:29:30 AM UTC+8 gri wrote: > >> Correction: The last paragraph in the post below should have said: "In >> Go, type information is not available at *parse* time". (Of course, type >> information is available at compile time.) >> >> On Tuesday, July 14, 2020 at 2:56:01 PM UTC-7 gri wrote: >> >>> We have received a variety of feedback on the generics draft design >>> <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md> >>> (blog <https://blog.golang.org/generics-next-step>). Thanks to everyone >>> who took the time to read it, play with generics code in the playground >>> <https://go2goplay.golang.org/>, file issues, and send us their >>> thoughts. >>> >>> Not unexpectedly, many people raised concerns about the syntax, >>> specifically the choice of parentheses for type parameter declarations and >>> generic type and function instantiations. >>> >>> A typical computer keyboard provides four easily accessible pairs of >>> single-character symmetrical "brackets": parentheses ( and ), square >>> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses >>> curly braces to delineate code blocks, composite literals, and some >>> composite types, making it virtually impossible to use them for generics >>> without severe syntactic problems. Angle brackets require unbounded parser >>> look-ahead or type information in certain situations (see the end of this >>> e-mail for an example). This leaves us with parentheses and square >>> brackets. Unadorned square brackets cause ambiguities in type declarations >>> of arrays and slices, and to a lesser extent when parsing index >>> expressions. Thus, early on in the design, we settled on parentheses as >>> they seemed to provide a Go-like feel and appeared to have the fewest >>> problems. >>> >>> As it turned out, to make parentheses work well and for >>> backward-compatibility, we had to introduce the type keyword in type >>> parameter lists. Eventually, we found additional parsing ambiguities in >>> parameter lists, composite literals, and embedded types which required more >>> parentheses to resolve them. Still, we decided to proceed with parentheses >>> in order to focus on the bigger design issues. >>> >>> The time has come to revisit this early decision. If square brackets >>> alone are used to declare type parameters, the array declaration >>> >>> type A [N]E >>> >>> cannot be distinguished from the generic type declaration >>> >>> type A[N] E >>> >>> But if we are comfortable with the extra type keyword, the ambiguity >>> disappears: >>> >>> type A[type N] E >>> >>> (When we originally dismissed square brackets, the type keyword was not >>> yet on the table.) >>> >>> Furthermore, the ambiguities that arise with parentheses appear not to >>> arise with square brackets. Here are some examples where extra parentheses >>> are not needed with square brackets: >>> >>> using () using [] >>> >>> func f((T(int)) func f(T[int]) >>> >>> struct{ (T(int)) } struct{ T[int] } >>> >>> interface{ (T(int)) } interface{ T[int] } >>> >>> [](T(int)){} []T[int]{} >>> >>> To test this better understanding, and to get a feel for this >>> alternative notation, we will begin to make changes to our prototype >>> implementation such that it accepts either parentheses or square brackets >>> (only one or the other) in a generic Go package. Those changes will first >>> appear as commits to the dev.go2go branch >>> <https://go.googlesource.com/go/+/refs/heads/dev.go2go>, and eventually >>> in the playground <https://go2goplay.golang.org/>. >>> >>> If square brackets don't lead to unforeseen issues, we have another >>> fully explored notation to choose from, which will allow us to make a more >>> informed decision. >>> >>> - gri, iant >>> >>> PS: For ambiguities with angle brackets consider the assignment >>> >>> a, b = w < x, y > (z) >>> >>> Without type information, it is impossible to decide whether the >>> right-hand side of the assignment is a pair of expressions >>> >>> (w < x), (y > (z)) >>> >>> or whether it is a generic function invocation that returns two result >>> values >>> >>> (w<x, y>)(z) >>> >>> In Go, type information is not available at compile time. For instance, >>> in this case, any of the identifiers may be declared in another file that >>> has not even been parsed yet. >>> >>> -- > 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/05841f9e-5f6c-4a7a-ab5e-efd699b1e4den%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/05841f9e-5f6c-4a7a-ab5e-efd699b1e4den%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfGStATbr5uhqoY0HREoWX5eXmkSsXC5rrna3exvk6hY1Q%40mail.gmail.com.
