[go-nuts] Re: Question regarding compiler internals

[Jacob McCollum]

Keith,

The genreal idea is that type parameters can only be specified in 2 places 
right now: on package-level type definitions and on package-level function 
definitions. I am waffling on the viability of allowing methods on 
already-parameterized types to specify type parameters as well, but that's a 
digression and will likely present a clear answer as I do more work and test 
more use cases.

You're correct that typechecking and type parameterization are tightly coupled 
logically, but conceptually it feels like 2 separate phases: type-checking type 
expressions, and type-checking concrete objects such as variable names, etc.

If I can nail down the concrete type represented by a type expression, I can do 
type replacement without knowing the type of every named object, given that the 
type checking logic that exists will catch the more low-level type errors. The 
brunt of the work in the existing type checker would then become incorporation 
new meta data to allow error messages to refer to the user-specified syntax 
(example: say GenType.[int] rather than GenType_generated_for_int_xhagdhd).

I will most definitely document gc with any information I glean during this 
process, although I think that is a separate project on its own, hah.

-- 
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.

[go-nuts] Question regarding compiler internals

[Jacob McCollum]

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.