On Wednesday, September 20, 2017 at 7:51:28 AM UTC-7, Jacob McCollum wrote: > > All, > > This is my first time posting to the golang-nuts mailing list, but I've > hit a wall and I'm not sure where else to reach out for some assistance. > > I'm knee-deep in a research implementation of parameterized types for Go. > It started out as an experiment, but I really enjoyed working on it and it > has turned into a toy project for me. > > To clarify, this is not (necessarily) something I intend to submit as a > PR, nor do I intend to release it as a fork or in any way use it to > fracture the community. This is simply a project I undertook to develop a > better understanding of the technical challenges facing the team when it > comes to implementation of generic types, and to potentially bring some new > ideas to that discussion (eventually). I don't have future plans for this > beyond learning at this point. > > That being said, I'm to a point where I've got a formalized set of rules, > the syntax is parsing correctly this information is stored in the parse > tree. The next step is type checking & concrete type generation/replacement. > > I am considering 2 possible implementations for this phase. One possible > plan is to augment the existing type checking logic with new functionality. > Another is to re-implement a lightweight type checker that gathers only the > information it needs to modify the parse tree, before dropping that down to > the cmd/compile/internal/gc package's processing logic. Right now, I don't > feel that I understand the existing type-checking flow well enough to make > that call. > > I'd lean toward modifying the existing typechecker. It's hard to tell from a 2-sentence description of your algorithm, but generally I suspect generic type checking and regular type checking to be tightly coupled. How would you do one if the other hadn't been done yet?
> Would it be a reasonable request to ask for a high-level overview of the > process that gc uses to get from syntax's parse tree to the node DAG that > is type-checked? I can fill in a lot of the blanks on my own once I have a > better high-level understanding, but right now I'm struggling to determine > the exact relationship between processing the syntax tree with *noder, > typecheck, the order in which those two processes should occur, etc. I've > seen the different phases as presented in gc's Main method, but trying to > understand the high level intent via the code feels like I'm failing to see > the forest through the trees. A little cognitive glue would go a long way > in helping me coalesce my understanding. > > I don't think we have any docs about this at the moment, the comments in Main are as good as it gets. But to your question, almost nothing happens between parsing and typechecking. The input to the type checker is exactly the output of the parser. Please, please, add comments to Main as you figure things out. It will help the next person who comes along. > Thanks, > > Jacob R. McCollum > > > > > > -- 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. For more options, visit https://groups.google.com/d/optout.
