Ian, I very much appreciate your taking the time to provide the history here. I am almost inclined to suggest that the OP create a design document much the way an engineer creates an as-built design before creating a new design. For my part, I would be willing to assist the OP on an occasional basis in trying to figure some things out just because I enjoy puzzles and I think that these efforts to learn will pay great dividends in the future.
On Thursday, February 25, 2021 at 8:56:01 AM UTC-6 Ian Lance Taylor wrote: > On Wed, Feb 24, 2021 at 10:24 PM messi...@gmail.com > <messi...@gmail.com> wrote: > > > > I'm trying to read golang compiler source code and now have come to the > middle of syntax analysis: just finished parser.fileOrNil, next step is > noder.node(). > > > > So far everything is fine, both lex and syntax tree parsing is easy to > understand. But after that part, it feels more and more difficult, in order > to make my learning process smoother, I think I need to ask some help/tips > from the community. > > > > Currently I'm doing it this way: > > 1. Figure out the main phases and the role of each one. > > 2. For each phase, figure out related data structures firstly, like > interfaces and structs > > 3. Read the source code of the phase, figure out the main logic > > 3. Guess, and use UT to verify > > 4. Use git log to see the author's original thoughts > > > > Problems I'm facing: > > 1. Can't find enough docs, especially official design docs > > 2. Comment is not enough in code repo, I believe it's enough for > compiler developers, but not for beginners like me > > > > This makes it very difficult to understand the design thoughts, in some > cases you have to read the source code line by line for its purpose, but > still don't know why it's implemented like that in the end. > > > > So my questions are: > > 1. Is there a place I can find the design docs for go compiler design? > > 2. What's the most productive way to learn the source code? Especially > from the perspective of go compiler developers. > > > > Thanks for any helps/suggestions/tips :) > > > Unfortunately there are no design docs. > > The most productive approach is the one you are already doing. Feel > free to ask questions on this mailing list about why things are > written the way they are. > > That said, the history of the compiler is that it was originally > written in C and based on the Inferno C compiler. Ken Thompson > modified that compiler to compile Go code, but the compiler was itself > still written in C. Several years later Russ Cox wrote a tool to > translate the C code into Go code. That Go code was naturally not > very idiomatic. A lot of it has been rewritten, but some still looks > like C code. A couple of years after that Keith Randall rewrote the > entire backend to use an SSA representation. At some point Robert > Griesemer rewrote the entire parser. Matthew Dempsky and Russ Cox > rewrote a lot of the frontend. Right now Robert Griesemer and Rob > Findley are rewriting the type checker. Many other people have > written significant components of the compiler, replacing earlier > components. > > My point in providing this partial history is that many questions > about "why does the compiler work this way" have the answer "because > of the long and complicated history of the code base." It is not the > case that a group of people sat down and designed a clean and elegant > Go compiler. As far as I know nobody has ever written a Go compiler > from scratch. > > Ian > -- 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/723cd8b6-93a2-4bb8-a7f7-78fd56420a54n%40googlegroups.com.
