# compiler-plugin mtg 07/08

I would like to discuss the design of [Part 1: Cassette.jl-like Code Rewrite](https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?both#Part-1-Cassettejl-like-Code-Rewrite), especially the part of [How This Design Solves the Issues of `@generated` ?](https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?both#How-This-Design-Solves-the-Issues-of-generated-).

- As for 1. unlimited customizations
- As for 3. context hook ?

## As for 1.

Don't more hooks simply mean more customizations ?
Isn't correct to say "`@generated` is limited in a sense that it can only hook into pre-inference stage" ?

"trade off"s:
- termination vs. more inference/optimization
- usual functions vs. `@generated` functions
- `@generated` functions vs. compiler plugin
- autodiff:
- Cassette.jl: exponential work
- Diffractor.jl: almost linear work, by eliminating expanded unused closures (requires type information)
- Diffractor:
- optimizations before inference ?
- `@generated` functions are not allowed to do

> `@generated` tweak inference options

E.g. tweak the method inference heuristics.
And we can have more like that.

Reuse `@generated` function ? Not necessarily.

## As for 2

- shouldn't rely on dispatch !
- overlay method table can be solutions ?
- might not be composable
- give up context hook ?
- how we gonna manage

Don't rely on dispatch as a core mechanism to apply transformations, and unlimit the inference.
E.g. recursion detection is limited for `@generated` functions.

## As for 3, many things to consider

From <https://julialang.slack.com/archives/C01T5MN64NB/p1625684749254100>

> The current example for context_hook looks like this interface would only be valid for concrete types, which means they are slightly worse at 2 than `@generated` functions now
>
> For 3, I don’t see anything in the proposal that reduces latency
>
> The specific mechanism of bail-out looks slightly different, but I thought Cassette-type passes already offer bail-out “context hooks” that work almost the same as the proposed pass would
>
> For 3, there seems to be an implication that the passes could preserve information between frames–something that generated functions are permitted to do now
>
> But generated functions are prohibited from that because the latency implications would be too slow
>
> Keeping latency low generally requires each component to be independent, so that there is never exponential (context-sensitive) work to add compile-time latency problems

### Is it really problem / Is there any alternative

Think about Diffractor:
- returns a value, derivative it is closure that contain all the previous states (functions)
- Observation: most of the closures aren't used => avoid creating unused closures.

Generalized: use type information to cut off uninterested portion

Key point: a closure multiplied zero, directly intervene to inference !

Punchline: _**Allow compiler plugins to experiment inference decisions**_

The transformation order might be important.

## Examples ?

- simple: `sin` to `fast_sin`
- autodiff
- GPU compiler
- CAS