search

clipperhouse / typewriter

The package underlying gen: type-driven code generation for Go
http://clipperhouse.github.io/gen/typewriters/#
Other
52 stars 20 forks source link

issue #77: make types.Check ignore errors #4

Open dgnorton opened 9 years ago

dgnorton commented 9 years ago
clipperhouse commented 9 years ago

Thanks. This is a start in the right direction, but we need to go a bit further.

I plan to make this behavior opt-in by the user. There are classes of type check errors where this will succeed, and others where it will fail. As a design goal, I want the behavior to be strict by default, and if the user wants to choose the non-deterministic approach, let them.

I've got a bit more architecture in the works on my end, will share with you.

dgnorton commented 9 years ago

I think it's important to be able to start with just a copy of the handwritten code (no generated files present) and generate from there.

I'd be interested to see what you have in the works.

clipperhouse commented 9 years ago

@dgnorton Agree, that’s the idea – you’re saying that even if the handwritten code has dependencies on the yet-to-be-generated code, it should work? That’s what I am going for here, if I understand the use case you are describing.

dgnorton commented 9 years ago

Yes, exactly. As it is, it's kind of a chicken & egg problem and I would be reluctant to use it on a big project for fear of getting into a state that required manual intervention to build.

clipperhouse commented 9 years ago

Yup. Am scratching my own itch here too, I’ve gotten into that state a lot.

dgnorton commented 9 years ago

I haven't played with Go's scanner / parser. Is it possible to feed it small chunks of code instead of files? I.e., could you read out just the package name and type declarations with some hand written scanning and feed those chunks into the parser? Dunno...maybe that's too hokey.

clipperhouse commented 9 years ago

To answer your question, yes you can do that but not sure what it buys us in this scenario. I get the instinct, maybe we can only evaluate the specific bits we need. Not impossible but sounds like a tough road.

typewriter first parses your whole package as an AST. That part is not changing – the code needs to be syntactically valid to proceed. If it’s syntactically busted, we really have no reliable information about the code.

It is possible for a program to be syntactically valid but incorrect. A class of error here is a variable of an unknown (undeclared) type. I think this is the state I think we are talking about above – handwritten code using yet-to-be-generated code.

typewriter then passes the AST to the types checker. The change we are discussing here is to have the types checker ignore that class of error.