Finally, Rust is production-ready. It is neat to see something more practical than an Brainf* interpreter.
A list of even more practical pieces of production code in Rust: https://wiki.mozilla.org/Oxidation#Shipped
Forth implemented in Rust trait system
11–20 of 91 posts
Re: Forth implemented in Rust trait system
#12I don't see why people won't just take the step D and Lisp do-- allowing full use of the programming language at compile time. You can execute an ordinary functions at compile-time to read a DSL from a string or read attributes (reflective metaprogramming) on your program's classes. Take the string it outputs, use mixin(), and you have code. For example: // Sort a constant declaration at Compile-Time enum a = [ 3, 1,…
Rust is getting that, gradually, with the work of replacing the ad-hoc "const evaluator" with miri (an interpreter for a Rust intermediate representation). Right now you have procedural macros, which are Rust code that operates on the syntax tree, including custom attributes.
Proper reflective metaprogramming would be a fairly big step though - right now, the macro systems happen well before the type system even gets a chance to look at the code, so the data to play with types in an interesting way isn't there at the right step.
Re: Forth implemented in Rust trait system
#13Re: Forth implemented in Rust trait system
#14> Rust's trait system is Turing complete has anyone tried implementing rust in rust's trait system
Turing complete≠uses the syntax of your favorite programming language.
Re: Forth implemented in Rust trait system
#15I don't see why people won't just take the step D and Lisp do-- allowing full use of the programming language at compile time. You can execute an ordinary functions at compile-time to read a DSL from a string or read attributes (reflective metaprogramming) on your program's classes. Take the string it outputs, use mixin(), and you have code. For example: // Sort a constant declaration at Compile-Time enum a = [ 3, 1,…
Rust have procedural macros https://doc.rust-lang.org/reference/procedural-macros.html
Re: Forth implemented in Rust trait system
#16I don't see why people won't just take the step D and Lisp do-- allowing full use of the programming language at compile time. You can execute an ordinary functions at compile-time to read a DSL from a string or read attributes (reflective metaprogramming) on your program's classes. Take the string it outputs, use mixin(), and you have code. For example: // Sort a constant declaration at Compile-Time enum a = [ 3, 1,…
> I don't see why people won't just take the step D and Lisp do-- allowing full use of the programming language at compile time.
Because "full use of the programming language" implies Turing completeness, which means compilation may require unbounded time and compute resources. You can allow use of a non-Turing complete subset, and this is something that dependently-typed languages can do quite elegantly.
Re: Forth implemented in Rust trait system
#17Definitely interesting, but I don't see any mention of being able to use this interactively or incremental compilation, which is what makes Forth, Forth. Forth isn't just syntax. It's an operating system and a programable programming language.
Re: Forth implemented in Rust trait system
#18I don't see why people won't just take the step D and Lisp do-- allowing full use of the programming language at compile time. You can execute an ordinary functions at compile-time to read a DSL from a string or read attributes (reflective metaprogramming) on your program's classes. Take the string it outputs, use mixin(), and you have code. For example: // Sort a constant declaration at Compile-Time enum a = [ 3, 1,…
> I don't see why people won't just take the step D and Lisp do-- allowing full use of the programming language at compile time. Because "full use of the programming language" implies Turing completeness, which means compilation may require unbounded time and compute resources. You can allow use of a non-Turing complete subset, and this is something that dependently-typed languages can do quite elegantly.
Many type systems are already Turing complete like C++ and indeed Rust as evidenced by the project linked here.
It’s a valid point. Of compilation already is Turing complete, why not just drop the pretense and allow arbitrary compile time expressions.
Re: Forth implemented in Rust trait system
#19Definitely interesting, but I don't see any mention of being able to use this interactively or incremental compilation, which is what makes Forth, Forth. Forth isn't just syntax. It's an operating system and a programable programming language.
The trait system and macros run at compile time and sadly there is no way to interact with the Rust compiler. However the macro is fully incremental (creating new words too). Which means in theory if it were possible to ask for input and pass it to the macro it would behave more like a VM:
// create a word
forth!(: inc 1 + ;);
// ask user for $input
type Stack = forth!($input inc return);
// if you keep the stack around it can be used again
forth!({ Stack } inc .);
// should print $input + 2Re: Forth implemented in Rust trait system
#20Earlier quoted context omitted.
> I don't see why people won't just take the step D and Lisp do-- allowing full use of the programming language at compile time. Because "full use of the programming language" implies Turing completeness, which means compilation may require unbounded time and compute resources. You can allow use of a non-Turing complete subset, and this is something that dependently-typed languages can do quite elegantly.
Many type systems are already Turing complete like C++ and indeed Rust as evidenced by the project linked here. It’s a valid point. Of compilation already is Turing complete, why not just drop the pretense and allow arbitrary compile time expressions.
Even where nothing in compilation is Turing complete, many pieces may be unbounded. And where there are artificial bounds, they could as well be applied to something otherwise Turing complete.