3 ms·

Author here, the article is more about how Rust and its ecosystem are nice tools for language designers rather than the beauty of Lisp. The crates listed in th

by linkdd 4y ago

Author here, the article is more about how Rust and its ecosystem are nice tools for language designers rather than the beauty of Lisp. The crates listed in that article are the ones I use for my compiler: https://letlang.dev https://letlang.dev Lisp was only chosen as a way to demonstrate the power of those crates and Rust features. A kind of way of justifying my choices for Letlang. It's not "you should do it like this" but "you can do it like this".

nerpderp82 4y ago
Your language is the first that I know of that compiles to Rust. Can you talk about that? Does the generated code have to pass the borrow checker or did you design around it?
- linkdd 4y ago
  After the translation of the source code to AST, I have walk through the AST to validate the code as much as possible. The generated Rust code should be valid Rust code that compiles with no error. I only have 2 exceptions to that rule: --- Function calls: I haven't found a way to verify that the identifier used resolve to a function with the correct signature (it would need some sort of partial evaluation and static type checking I don't have). Rust FFI: Letlang will have the ability to call native Rust functions (allowing me to rely on the Rust ecosystem to implement the stdlib), but it expects functions to have a specific signature. --- Those are the 2 cases where `cargo` can throw an error. So I (plan to) include source mapping comments in the generated Rust code. After getting the output of `cargo` as JSON, I can identify the error type and location, then using the source mapping info, I can pinpoint what AST node generated the wrong code. On a semi-unrelated note: Every Letlang module is a single Rust crate. The compiler generates a cargo workspace, and a cargo project in that workspace for every module. It makes dependency management (and my life) easier. It's funny how people are intrigued by my choice of targeting Rust, while other compilers targets C, Javascript, or other higher-level languages :P But I guess it's because I use the term "compiler" and not "transpiler". Hint: I hate the word "transpiler", which is just a synonym to "compiler" IMHO.
  - nerpderp82 4y ago
    Thank you! I am not questioning it in as casting doubt or making you defend it, I want to learn from it. Targeting a rigorous safe language as the output of a compiler is wonderful. You get no guarantees when you target C or JS. By targeting Rust, it also makes it natural to embed inside of a Rust macro and weave it into Rust like `inline_python` does. There was a position blog post awhile ago arguing that language designers should target Rust as their compilation target, but a quick search doesn't turn it up. https://docs.rs/inline-python/latest/inline_python/ https://docs.rs/inline-python/latest/inline_python/ *edit, found the post https://willcrichton.net/notes/rust-the-new-llvm/ https://willcrichton.net/notes/rust-the-new-llvm/ > New programming languages with a system-level compile target should choose Rust over LLVM. Targeting Rust can give new languages free package management, a type system, and memory safety while not imposing too many opinions on the language's runtime. With more work on languages, tooling, and Rust compiler development, we can create an ecosystem of beautifully interoperable programming languages.
mepian 4y ago
>Implemented in Rust, it compiles to Rust, allowing you to target any platform supported by LLVM. Why not emit LLVM IR directly instead of compiling to Rust?
- linkdd 4y ago
  This makes implementing the runtime (I use tokio for the concurrency model) faaaaaaar easier. I also get the borrow checker, move semantics, etc... that I would have to implement myself if I were to target LLVM IR. That question has been asked so many times, I should probably start a FAQ :P

by linkdd 4y ago

nerpderp82 4y ago

Your language is the first that I know of that compiles to Rust. Can you talk about that? Does the generated code have to pass the borrow checker or did you design around it?

linkdd 4y ago
After the translation of the source code to AST, I have walk through the AST to validate the code as much as possible. The generated Rust code should be valid Rust code that compiles with no error. I only have 2 exceptions to that rule: --- Function calls: I haven't found a way to verify that the identifier used resolve to a function with the correct signature (it would need some sort of partial evaluation and static type checking I don't have). Rust FFI: Letlang will have the ability to call native Rust functions (allowing me to rely on the Rust ecosystem to implement the stdlib), but it expects functions to have a specific signature. --- Those are the 2 cases where `cargo` can throw an error. So I (plan to) include source mapping comments in the generated Rust code. After getting the output of `cargo` as JSON, I can identify the error type and location, then using the source mapping info, I can pinpoint what AST node generated the wrong code. On a semi-unrelated note: Every Letlang module is a single Rust crate. The compiler generates a cargo workspace, and a cargo project in that workspace for every module. It makes dependency management (and my life) easier. It's funny how people are intrigued by my choice of targeting Rust, while other compilers targets C, Javascript, or other higher-level languages :P But I guess it's because I use the term "compiler" and not "transpiler". Hint: I hate the word "transpiler", which is just a synonym to "compiler" IMHO.
- nerpderp82 4y ago
  Thank you! I am not questioning it in as casting doubt or making you defend it, I want to learn from it. Targeting a rigorous safe language as the output of a compiler is wonderful. You get no guarantees when you target C or JS. By targeting Rust, it also makes it natural to embed inside of a Rust macro and weave it into Rust like `inline_python` does. There was a position blog post awhile ago arguing that language designers should target Rust as their compilation target, but a quick search doesn't turn it up. https://docs.rs/inline-python/latest/inline_python/ https://docs.rs/inline-python/latest/inline_python/ *edit, found the post https://willcrichton.net/notes/rust-the-new-llvm/ https://willcrichton.net/notes/rust-the-new-llvm/ > New programming languages with a system-level compile target should choose Rust over LLVM. Targeting Rust can give new languages free package management, a type system, and memory safety while not imposing too many opinions on the language's runtime. With more work on languages, tooling, and Rust compiler development, we can create an ecosystem of beautifully interoperable programming languages.

mepian 4y ago

>Implemented in Rust, it compiles to Rust, allowing you to target any platform supported by LLVM. Why not emit LLVM IR directly instead of compiling to Rust?

linkdd 4y ago
This makes implementing the runtime (I use tokio for the concurrency model) faaaaaaar easier. I also get the borrow checker, move semantics, etc... that I would have to implement myself if I were to target LLVM IR. That question has been asked so many times, I should probably start a FAQ :P