• Why?
• You’ve made two mostly independent major changes in the syntax: to depend on significant indentation, and to switch from keywords to symbols. Why both, rather than just indentation while keeping it otherwise as familiar as possible?
• Why change lifetimes from ' to `? (Nothing obviously collides with keeping it '.)
• Why change closures from || to //? (You’ve then reused | for other things, but why not the other way round?)
• What does the word “analogous” mean here? (I don’t believe it can be the normal English sense I’m used to because that requires something in the syntax to be compared to—I’m not sure what the proper grammatical term is on the adjective, but it’s like the distinction between intransitive and transitive verbs, with the sense I know being strictly transitive (by analogy) but you using it intransitively (as it were).)
Finally, macros are a knell for alternative syntaxes like this: it’s not possible to make them work interoperably, because macros consume Rust token trees, but can interpret the body however they like, and you can’t reliably detect what they’re trying to do, so you can’t compensate. In your println! example, you are apparently saying it must translate the body from Analog to Rust, which would work in that instance because it’s largely consuming Rust language syntax (though named arguments add a little fun); but in your json! example, it needs to not perform any such translations, because json! doesn’t consume Rust syntax. (Perhaps in that specific instance the translation would be harmless, but it’s trivial to show macros where that’s not the case.) Attribute macros will be OK, and you might be able to get most structural macros working, but many structural macros (especially those that deal with token trees) and all non-attribute procedural macros are going to be a dead loss. I’m afraid I see only three solutions for macros in such an alternative syntaxes: (a) give up on interoperability, and maintain a completely distinct macro system; (b) have macro bodies always be in Rust syntax, which would break your very first example’s use of println!; or (c) on macros where there is any uncertainty, require what basically amounts to FFI bindings, which the language could provide for the standard library but it’d mean pain for calling macros from third-party crates, and could basically entail falling back to Rust syntax in complex cases. Hmm… that’s actually interesting to think about, as the uncertain nature of macros already causes some trouble for developer tooling. (rust-analyzer works well with structural macros, but can’t cope very well with most procedural macros, and something along these lines could actually be genuinely useful.)