4 ms·
(Late reply, sorry) Well currently you can't get at the AST, only (with some hairy code) bytecode. (The use cases are post-compilation) But suppose this work
by shellac 3y ago
(Late reply, sorry)
Well currently you can't get at the AST, only (with some hairy code) bytecode. (The use cases are post-compilation)
But suppose this work did enable that. What Paul is saying is that there are intermediate representations between bytecode and AST that are more helpful for these GPU / SQL / whatever runtime compilers. Representations that capture dataflows, for example. Chance are these compilers would transform an AST to something like this anyway.
See https://mlir.llvm.org/ https://mlir.llvm.org/ which is referenced in that talk.
- bafe 3y agoThanks, that makes sense. I think I approached more from the perspective of a library writer that doesn't want to delve into the depth of language to implement transformations/macros. However it does seem reasonable to have a variety of abstractions to be able to express these transformations in a way closer to the target language