Hi Jacob; As you have probably figured out yourself by now, coming up with some syntax for parametrized types (and perhaps even a set of formalized rules) is the easy part of a complete implementation.
If you have been working on the existing compiler, you must have adjusted the cmd/compile/internal/syntax package which is quite straight-forward and easy to play with. The result is a parse tree using syntax.Nodes. Presumably you have introduced new new types and fields to handle the extra information you need to represent and adjusted the parser code. (Correct me if you're doing something else). In cmd/compile, currently (we're in a transition phase) this syntax tree is then converted by the gc noder into another syntax tree, the one that historically was generated by the compiler's parser directly. It's bigger, has only a handful of distinct nodes, and is generally (much) harder to deal with. I don't know if you have attempted to generate this one as well. It's much more difficult to extend this node structure and its documentation is sparse to non-existent (hence we're hoping to replace it eventually). In cmd/compile, it's that tree that is type-checked. If you haven't gotten this far you may want to try to type-check the syntax tree instead. Type-checking is a complicated process: For Go it must implement essentially three basic functions: 1) resolution of identifiers: Which object (package, constant, type, variable, function, label, etc.) does an identifier stand for. In general this resolution requires all source code of a package to be available because only then one can know for sure what an identifier (which might be defined at the very last line of the last file) stand for. 2) Constant folding: For all constant expressions, the constant value is determined. 3) Type inference: For each expression its type is determined. There's some finer-grained phases to associate methods with types, to determine initialization order, etc. In Go, only phase two can be done truly independently. Phases 2 and 3 are somewhat interdependent because a constant value (say, the length of an array, or unsafe.Sizeof a variable) may depend on a type. Vice versa, an array type may depend on the value of a constant which in turn may affect the constant size of the array type. The cmd/compile type checker mixes some of these phases. In fact some identifier resolution (phase 1) is even done at parse time (and sometimes needs to be corrected afterwards). But the main phases are at least outlined in gc/main.go:439ff. The type checker is also called whenever the compiler is not sure it has the type of a node. Each node "knows" if it was type-checked, and there's a mechanism to stop endless recursion (Node.Typecheck). It's all pretty complicated unfortunately - which is why we're trying to clean it up over time. If your goal is to eventually generate code, you'd have to deal with the compiler's node structure, adjust the type checker, and probably backend (and all that depends on that). It's a huge project. If your goal is to have a proof of concept where you can parse and type-check source code, it might be a lot easier to have your own type-checker. You could borrow almost all of go/types <https://goto.google.com/types> which is a complete type-checker for Go, and which is hopefully a bit easier to read. It operates on go/AST <https://goto.google.com/AST> nodes which are a bit different from syntax nodes, but in fact most of the nodes are the same or very similar (syntax nodes mostly have a simpler structure for grouped declarations). That might be a simpler approach but it won't get you to code generation. You'd still have to deal with import and export somehow which would need to be extended so it can represent the new data structures. All that said, if you actually manage to type-check a single package using parametrized types correctly (in whatever glorious form you have devised), you've got the first half of an implementation. Hopefully this is a little bit helpful. - gri On Wed, Sep 20, 2017 at 4:46 PM, Jacob McCollum <jacob.r.mccol...@gmail.com> 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. > > 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. > > 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. > -- 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.
