Compiler Design: Prereq Handler Dependency #2727
Comments
|
This might even simplify our We'd have a top-level PrereqHandler instance which is created in For each place where we might want to capture prereqs, we'd just create a new instance of this class. This would hopefully make it very clear which code emits prereqs and which captures prereqs. |
|
A side problem of this is that we use a mix of prereq handling. In some cases, we capture everything and return the list in mostly the same order. In other cases, we don't capture because the emit order is okay with all the prereqs at the top. (And in some bug cases, we don't capture even though the emit order is wrong). I like the sound of this suggested class, but I'm a bit worried it will become so common as to be mostly meaningless. The bigger problem is that prereqs are inserted at a place in the code automatically, which is not necessarily the sensible place when capturing or complex transforms have gone on. We could solve that by forcing explicit returns of prereqs, but that might create a lot of extra code that only pushes the prereqs at the start in simple transforms. |
Here's a quick thought I wanted to write down.
It's difficult to determine which
transformX()functions might result in prereqs. Usually, you have to go dig into the definition of it + whatever functions it ends up calling to get an idea.Instead, what if we moved all of the
state.prereq()functions into a new class.transformX()functions which use prereqs would be forced to take the instance of this new class as a parameter (and thus, dependency). Or if thattransformX()calls atransformY()which requires prereq functions, then it would also require it transitively.This would be a massive refactor of the current compiler and needs more thought.
The upside is that it would enable us to use the typechecker for validating where we might not be properly handling prereqs.
The text was updated successfully, but these errors were encountered: