[proposal] Make go compiler work with different syntax versions in same project to support adaptivity

[ivaniva...@gmail.com]

Add support of optional syntax_version to file beginning, allow compiler to tokenize/compile file by the compiler of syntax_version, using any number of syntax_version-s in same project

Why? Because go takes ridiculously long to implement generics, and implementation is very likely to not be perfect or to become not perfect when world changes. Having support of several syntaxes/compilers in same project will allow to adapt syntax faster

[Viktor Kojouharov]

What problems would you expect generics to bring in terms of syntax, where such flexibility would be a solution?

[Ian Lance Taylor]

On Sat, Aug 8, 2020 at 7:51 PM <ivaniva...@gmail.com> wrote:
>
> Add support of optional syntax_version to file beginning, allow compiler to tokenize/compile file by the compiler of syntax_version, using any number of syntax_version-s in same project
>
> Why? Because go takes ridiculously long to implement generics, and implementation is very likely to not be perfect or to become not perfect when world changes. Having support of several syntaxes/compilers in same project will allow to adapt syntax faster

We already support something like this on a per-module basis via the
"go" line in a go.mod file
(https://golang.org/cmd/go/#hdr-The_go_mod_file). See also
https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md
.

Ian

[Ivan Ivanyuk]

Thank you for answering

Why does it take so long to implement generics then? There is already an instrument in playground that works fine. Why not just roll it out and improve design, if needed, in next version?

Having generics in 2021 means many projects will choose other languages in 2020, which will effectively mean 1 year of work in other language

[Carla Pfaff]

On Monday, 10 August 2020 at 10:30:55 UTC+2 Ivan Ivanyuk wrote:

There is already an instrument in playground that works fine. Why not just roll it out and improve design, if needed, in next version?

The go2go tool is just a toy, an experiment, a simple translation tool. It will be thrown away once they begin with the real implementation.

https://twitter.com/GoTimeFM/status/1292148677155463169

(Transcript from the Go Time podcast): "The experimental tool has no similarity whatsoever to any real implementation. [...] If this does move forward to become a proposal and it gets accepted, then most likely the implementation will be to start with a branch of the main Go toolchain, and we'll start adding generic support on that branch, which will involve changing the compiler mainly and any other changes to other tools that are required."

 

Having generics in 2021 means many projects will choose other languages in 2020, which will effectively mean 1 year of work in other language

Go aims at careful and cautious language design, not at catering to impatient people. 

[David Skinner]

A handyman can do many things. But domain-specific experts like plumbers, electricians, and carpenters are far more skilled and efficient.

Statistical analysis of psycholinguistics indicates that there exist specific modes of thinking, no one syntax will ever be the best syntax for all modes of thought.

One lesson I learned in my brief and ineffective stint with the IEEE Standards is that when you try to satisfy all stakeholders, you end up with a pudding that satisfies no one.

I do believe that letting the Go team be both deliberate and opinionated is for the best.

I also do not consider the go2go tool a toy, but rather a proof of concept. It is similar and superior to the translation tool that I am using internally.

I have never considered the Go language to be the best language for anything except for the implementation of solutions. It is not the best for defining a project or for defining a solution. Warren Swader never needed Go, He could conceive an entire game and code it in ASM. I started without a compiler by writing MachineCode directly in Octal. 

Ivan Ivanyuk has a most excellent idea, one that I fully support. It is also one that is fully supported by the Go programming language.

• Begin your project with a doc.go file and define the API and package.
• Create your domain-specific grammar file.
• Create your Doit.ivan file with your domain-specific syntax.
  
• //go:generate goyacc -o Doit.go -p parser ivan.y
  

This is perhaps an oversimplification but details are available at

• https://blog.golang.org/generate
  

The Go team is incapable of maintaining multiple syntaxes and we need to respect their bandwidth, but in their wisdom, they have enabled us to achieve all of our domain-specific goals, not in 2021 with generics, but rather with Go 1.14 with generate. Please do not expect them to do all of our work, learn to use the tools they have been providing us.

[Ian Lance Taylor]

On Mon, Aug 10, 2020 at 1:30 AM Ivan Ivanyuk <ivaniva...@gmail.com> wrote:
>
> Thank you for answering
>
> Why does it take so long to implement generics then? There is already an instrument in playground that works fine. Why not just roll it out and improve design, if needed, in next version?
>
> Having generics in 2021 means many projects will choose other languages in 2020, which will effectively mean 1 year of work in other language

Besides what other people have said, we believe, rightly or wrongly,
that language stability and backward compatibility are important
features for Go programmers. We don't want to roll out a version of
generics that we then have to change in some incompatible way. That
would force people to rewrite programs over time, which is painful,
and will decrease people's perception of Go as a stable and reliable
language.

Ian

[Ivan Ivanyuk]

Ok, thanks for the clarification.