Requiring type-information for parsing will brings difficulty for implementing these tools, but not impossible. To solve ambiguity, the only requiring type-information is wether a symbol is a type name or an identifier. A parser package can help this.Since other languages like Java, C#, TypeScript can solve this, it must be a way for Go.
On Monday, July 20, 2020 at 2:43:53 PM UTC+8 axel.wa...@googlemail.com wrote: > On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye <xiez...@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...@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/147a7e7f-ac1c-45fa-8a3a-0634079b7d56n%40googlegroups.com.
