Lisp (or other languages) on top of Mojo?
I (and many others) derive considerable benefit from using a Lisp-based language: homoiconicity, macro capability, regularity of syntax, terseness, developer convenience (e.g. Paredit, Parinfer), and so on. Plus, even beyond issues of practicality — as anyone knows who's "gotten" Lisp — there's something subjectively beautiful and timeless about it (https://xkcd.com/224/).
I'd like to suggest that Mojo have some facility for other programming languages to take advantage of the compiler work being done under the hood. JS has source maps for transpiled languages like TypeScript, ClojureScript, etc. The JVM processes bytecode emitted by hosted languages and treats such languages as first-class citizens. Having some sort of transpilation story (or possibly better, a hook-in to the Mojo MLIR representation?) could be a powerful advantage for Mojo as it draws in indirectly users like me who are disconnected from the Python ecosystem, but who still want to take advantage of Mojo's performance and reach to heterogeneous architectures.
This, of course, is all assuming that Mojo is defining some custom MLIR passes that give it some sort of technical advantage over a language that used MLIR directly. Otherwise there's not much to do here 🙂
8 Replies
Bumping this!
I struggle to understand this request. Are you asking that the compiler be architected in such a way that it can accept multiple frontends?
Perhaps so. Let me see if I can be more clear.
Right now it's:
Mojo -> Mojo MLIR -> other MLIR frontends like LLVM -> machine code
Supporting transpilation is reasonably trivial, but debuggability suffers (e.g. source maps would be required, and the source language would always be "second class"):
Arbitrary language -> Mojo -> Mojo MLIR -> ...
I'm proposing:
Arbitrary language -> Mojo MLIR -> ...
Ostensibly, in this way the source language would benefit from all the MLIR tooling (stacktraces, debugging, etc.) while also benefitting from Mojo's custom performance-oriented MLIR passes.
Does that make sense or is what I'm proposing not a reasonable way to achieve the goals I've outlined? Maybe I'm misunderstanding some part of the pipeline.
Oh, that makes sense. Interestingly, Mojo might already provide facilities for it with the way packages are compiled. When Mojo and its IR gets documented and released it should be possible to do. Though I doubt you'll get any help from Modular.
Awesome! Figured that about Modular haha. They're solving the two-language problem, and proliferating languages is an explicit non-goal. But they do emphasize compatibility and, well, modularity, so hoping they expose their IR facilities.
Congrats @Alex Gunnarson, you just advanced to level 3!
They intend to build Mojo in a way that completely opens up the compiler. They've been talking a lot about moving optimisations to the library and giving all the power to the developer. It'll depend on C/C++ interop though, see this
Perfect! Thanks for sharing!