How well do LSP implementations cope with complex macros like this?
this is the wrong way to do translation problems in lisp.
Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
31–35 of 35 posts
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#32Earlier quoted context omitted.
Rust's macro system is actually quite limited (I don't know if it's Turing-complete, but the artificial recursion limit is low enough that even if it is, it's not going to be all that abusable); macros are mostly just good for getting rid of repetitive boilerplate, and community norms (and implementation papercuts) discourage people from reaching for macros willy-nilly.
They are Turing complete, see https://github.com/durka/brainmunch
Not that "Turing complete" matters much. Raw text find-and-replace is Turing complete.
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#33Earlier quoted context omitted.
They are Turing complete, see https://github.com/durka/brainmunch
Not that "Turing complete" matters much. Raw text find-and-replace is Turing complete.
Like the language /// ? (https://esolangs.org/wiki////)
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#34Earlier quoted context omitted.
> Would it be possible to write a compiler from Java to Rust? C# to rust? It's possible to write a compiler from any Turing-complete language to any other Turing-complete language > The goal then would be to get fast(er) execution times. You'd improve startup times from not having to warm up the JIT, but otherwise it would very unlikely you'd get a noticeable performance improvement. The speed of a language is at lea…
I'm not sure the statement "It's possible to write a compiler from any Turing-complete language to any other Turing-complete language" is really accurate, other than in a strict cs sense. If you have a language that only allows printing to the screen as output and reading from the keyboard as input then you can't write anything that requires low level hardware access in it.
Thats more a symptom of the environmemt/compiler, but not the language itself. Theres no reason printing to the screen would stop you from printing binary, and feeding that into your processor as normal. Theres also no reason why the language can't have another implementation that does allow more standard outputs.
Language-wise, theres nothing stopping you from parsing java, and producing equivalent semantics. There's nothing stopping you from producing equivalent jvm bytecode.
The interesting part of racket/perl6/this project is that this compilation step is being done without having to parsing "another language", by using macros. Parsing is still done ofc, but it could also be said that you're really just parsing the rust language, which happens to look like java, and producing rust code. The macro system itself is operating as the compiler, and since macros are "rust", then whats the difference?
Re: Show HN: A Rust macro that parses Java-like syntax and runs it as a Rust program
#35Earlier quoted context omitted.
Not that "Turing complete" matters much. Raw text find-and-replace is Turing complete.
Like the language /// ? ( https://esolangs.org/wiki//// )
Interesting, but my thoughts were along a simpler route of making a literal Turing machine out of text.
Represent your tape with digits, and your head with a letter. Have an arrow from the letter to the active cell.
[ 0 0 0 1 1 A->2 2 2 ]
A->2 becomes 1 A->
2
B->2 becomes (Plus a replacement from [] to ->0] to make the tape infinite.)