> What you're doing wrong is that I can't write that inline in the code and need to write it as essentially an extension library for the compiler.

> I don't think it's such a strange request that my DSL implementation look like it does in C or Scheme, e.g. "[Define some quirky DSL hackery] [Implement a bunch of code using it]". I'm likewise mystified why you think that's not a useful requirement or a shortcoming (even a minor one -- you're literally refusing to engage me on this) of your design.

In Rust, you can implement any DSL you could implement in C precisely as you would in C, using Rust's macro system. You define a macro inline in your file, and then you can use it right there in your file. No separate module is necessary. Rust's macro system is pretty much strictly more powerful than that of C, so anything you can do in C macros you can do just as easily in Rust.

When you want more powerful syntax extension features than what Rust's macros—or the C preprocessor—could provide, then you reach for the compiler plugins.

When it comes to Scheme-like macros, where the language in its entirety can be used at compile time, that's where the cross-compilation story makes things more interesting. Rust's syntax extensions are just like Scheme macros in that the entire language is available to you. In Scheme, however, your compile-time and runtime environment can generally be considered to be one and the same, which makes cross-compiling issues a lot easier to deal with. Anything available at compile time is also available at runtime, so you can do things like write modules that export functions available in arbitrary phases. In Rust, because of things like cross-compilation, this is not true: your compile time and runtime environment can be totally incompatible. You can't just write a helper function inline in your code and expect it to be usable both at compile time and at runtime, because its compilation environment (for example, the symbols it references) may or may not exist depending on the architecture.

I don't think I'm "refusing to engage"; I'm just saying that we considered everything you're talking about already. The Schemers on the team had exactly your complaint :) But we tried to make a simple implementation that did what Scheme did and ran headfirst into the cross-compilation issue, pushing us toward a more limited approach. It's quite possibly doable to implement syntax extensions in such a way as to allow for the full generality of the language at compile time while still supporting cross-compilation; SBCL can cross-compile itself, for example. But it's a lot of work, and all of the Lisps and Schemes that can do something similar have a huge amount of infrastructure to allow them to do so. (Read the SBCL cross-compilation paper, for example.) Certainly no implementations of the main compiled languages I'm aware of allow the full generality of the language to be embedded within itself without some sort of module boundary: C++ and D compilers use an interpreter for a subset of the language to evaluate constexpr (and the reason why the full language is not supported is, essentially, exactly this). Given that Rust is hardly unambitious to begin with, I'm OK with the fact that it doesn't solve this problem yet.