Can we remove the need for function proxies?

[davesmith00000]

At the moment, to use an external function as a function, the user has to define a proxy function in the shader that has the same arguments. and delegates. This is because everything outside the shader body has to be inlined, so the body of the function ends up being inlined, which isn't always what you want.

Does the inlined definition gives us a clue that this was once a function somewhere? If so, can we make the proxy ourselves to save the user from having to do it?

[davesmith00000]

Another reason to do this is variable name collisions. Currently if you define a proxy with an arg p, and there is a p variable in the function code, then you'll get a confusing error saying that p has been redefined.

[davesmith00000]

Sadly, I think the answer here is no (unless progress is made on scala/scala3#22165), it isn't possible. You can get a very long way towards it, see this PR: #129

Ultimately though, the problem seems to be the nature of inline macros, and the fact that the inlining process just doesn't leave you with enough information. I wrote a quick summary on this issue of where I believe we are. It may be that improvements are possible, but there are fundamental limits to how far we can push inline macros, and inline macros still seem like the best option to me.

scala/scala3#22165 (comment)

Just to save me looking this up later:

(...) when attempting to write a transpiler, this seems to leave me with 3 options with their pros and cons:

1. Full compiler plugin (a la Scala.js) - transform a whole program. I guess code sharing will need to happen by importing libs. The approach means I can't just write a shader within my game project (as we do now), it needs to be an external module / project that would emit GLSL code during compilation.
2. Macro annotations - Nice clean AST and you get to chose your scope level. However, code sharing seems impossible. You can transform everything under the current annotation, but you can't see anything outside of it. (Right?)
3. Inline macros - thanks to inlining, it's possible to use shared code, it's just clunky and the AST is garbled and you have to do a lot of creative interpretation.