Post-analysis desugarings and transformations result in ASTs without types. (The names are still resolved as the annotation on string is copied along during transformations.)

It would be really useful to have an analyse-post-analysis(|scope): Expr -> Expr' so one can let something get type annotations (and the use site annotations if they miss) on newly constructed expressions.

The scope graph itself does not change (well maybe, there might be lets or set comprehensions in the expressions), only some local additions. New definitions like adding classes or attributes is not required. So this would be a local analysis.

Use: code generation from the language to the target language requires type information.

Use cases: Relations language, Booster language. But I guess this pattern occurs more often. (Now we have to annotate manually again, repeating the type system specified in TS in stratego again.)

It would be nice if a future version of NaBL/TS could support this kind of use case: not only analysing input code, but also analysing newly constructed expressions in light of the analysed input code.

@Hendrik, any idea if this would be possible ‘relatively effciently’ with constraints. I imagine wanting to call analyse-post-analysis 100s of times during code generation: if that would mean running the full analysis of the program + 1 extra expression 100s of times it would be too slow I expect.

I’m going to try to write the stratego type-annotation rules analoguously with the TS rules. I expect we could then generate those from ts.

Submitted by Daco Harkes on 12 June 2015 at 11:52

@Danny, I guess this would not be enough for the WebDSL compiler, as you also add function definitions (and even entities?). Do these extra definitions the you get during compilation also change the resolution of already analysed AST parts?

I am planning to think about this together with Jeff, since GreenMarl has similar issues. However, I don’t think continuous, full re-analysis is a solution here. We were more thinking about scope-graph aware transformations, which migrate the scope graph, or where you can call local re-analysis (for types).

For the WebDSL compiler, in most cases the newly generated definition will have some internal unique name, and the reference to it is also part of a newly generated fragment. These still require some broader reanalysis to add the necessary context information (e.g. the closure with variables in scope, if that is required for further transformations). However, they don’t change existing resolution because the name is new and unique.
Other cases will pre-declare a definition, e.g. the built-in session entity securityContext, which means the analysis will know the type, but the actual entity is generated in a later transformation phase. Built-in generated templates and functions also work like this.

@Guido and Jeff, I was indeed also thinking about local reanalysis indeed.

I guess if it it would be constraints then if you only add code, you only add constraints. Meaning that if you keep the constraints of the initial analysis and the unification of those constraints, you could just add the new constraints and continue unifying.

@Daco yes, that is my hope. With constraints you can also delete some constraints from deleted code, and remove all unifications based on those constraints.
Still, it all depends on how powerful you need this partial reanalysis to be. The more powerful you make the technique, the more you can change and therefore the less you can reuse of the previous analysis.

Danny poses an interesting case where you add a new (top-level?) definition, but you already know you don’t need to check existing references because the definition is new. That’s valuable information that wouldn’t be available in the general case unless you restrict reanalysis to only accept definition of new names. I’d prefer to have some kind of system where that restriction isn’t necessary and you can instead tell the reanalysis about the freshness of the new name.
The nice thing about scope graphs is that once you have one for a correct program, you can do alpha-conversion, which means you can also completely anonymise the graph and work with abstract fresh names when you extend the scope graph alongside the program.