41–50 of 91 posts
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. 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. 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,…
You have procedural macros, which are literally "Rust code is the input, which you write rust code to manipulate, and output more rust code".
You have const fns, which are interpreted at compile time, and are closer to what you're referring to.
Earlier quoted context omitted.
One issue not yet mentioned with Turing complete language at compile is that it makes tooling and IDE integration much more difficult. When you need to run an unbounded program each time you want to provide real time feedback, like type inference or in Rust case lifetime inference, you make the language tooling much less simple and accessible.
> One issue not yet mentioned with Turing complete language at compile is that it makes tooling and IDE integration much more difficult How so? > When you need to run an unbounded program How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case.
I'm not sure how realistic that actually is. Besides certain party tricks like encoding the ackermann functino using primitive recursion, I haven't actually seen anything like that. From my experience the vast majority of programs that don't finish in a reasonable amount of time are those that have some logic bug.
A timeout seems pretty off-putting. The idea that compilation could fail on a weaker machine just because it isn't fast enough just doesn't sit right with me.
Earlier quoted context omitted.
One issue not yet mentioned with Turing complete language at compile is that it makes tooling and IDE integration much more difficult. When you need to run an unbounded program each time you want to provide real time feedback, like type inference or in Rust case lifetime inference, you make the language tooling much less simple and accessible.
> One issue not yet mentioned with Turing complete language at compile is that it makes tooling and IDE integration much more difficult How so? > When you need to run an unbounded program How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case.
All other tooling faces the same issue. What variables have a given type? If determining the type takes arbitrarily long, how are you supposed to discover them? Now consider the plight of an automated refactoring tool.
The IDEs and tools can still be written, of course. But they take more work and can't be as reliable.
Earlier quoted context omitted.
> One issue not yet mentioned with Turing complete language at compile is that it makes tooling and IDE integration much more difficult How so? > When you need to run an unbounded program How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case.
>How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case. I'm not sure how realistic that actually is. Besides certain party tricks like encoding the ackermann functino using primitive recursion, I haven't actually seen anything like that. From my experience the vast majority of programs that don't finish in a reasonable amount of…
Earlier quoted context omitted.
No, because the program may not be able to actually understand the syntax of your favorite programming language. As I mentioned in another comment, FRACTRAN is Turing-complete and you cannot just shove a string of Rust code at it because it has no idea what a string is; the best you can do is implement the "compiler" as working on some numerically-encoded version of Rust and producing some encoded version of a native…
You are misunderstanding the difference between “can in theory” and “presently able to do.”
Earlier quoted context omitted.
You are misunderstanding the difference between “can in theory” and “presently able to do.”
I don't think so; would you mind explaining why you think that?
That doesn't mean that the OP's hack can be used today, or even tomorrow for compiling-Rust-in-Rust. But you could, in theory, do so.
Earlier quoted context omitted.
> One issue not yet mentioned with Turing complete language at compile is that it makes tooling and IDE integration much more difficult How so? > When you need to run an unbounded program How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case.
>How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case. I'm not sure how realistic that actually is. Besides certain party tricks like encoding the ackermann functino using primitive recursion, I haven't actually seen anything like that. From my experience the vast majority of programs that don't finish in a reasonable amount of…
The timeout should be set based on what the user of the machine considers acceptable. Why should I have to tolerate a 2 hour wait time for a compile-time computation to finish in order for the auto-complete menu to appear on emacs just because I am using a laptop from 2010?
> Besides certain party tricks like encoding the ackermann functino using primitive recursion, I haven't actually seen anything like that
Try prolog then (or something similar) and write something of the form sha512(X) = 0 this will initiate a brute-force search that will last essentially forever.
Earlier quoted context omitted.
>How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case. I'm not sure how realistic that actually is. Besides certain party tricks like encoding the ackermann functino using primitive recursion, I haven't actually seen anything like that. From my experience the vast majority of programs that don't finish in a reasonable amount of…
The analog of a timeout in a compiler is recursion depth limits.
Earlier quoted context omitted.
> One issue not yet mentioned with Turing complete language at compile is that it makes tooling and IDE integration much more difficult How so? > When you need to run an unbounded program How is a program that provably terminates but takes 2 years to finish any better for compile-time computation? You want timeouts in either case.
A language that is Turing complete at compile means that an IDE cannot reliably tell whether code has a syntax error without running a program that can take arbitrarily wrong. All other tooling faces the same issue. What variables have a given type? If determining the type takes arbitrarily long, how are you supposed to discover them? Now consider the plight of an automated refactoring tool. The IDEs and tools can st…
A language that is not Turing complete at compile-time does not necessarily mean that an IDE will be able to reliably tell whether a certain piece of code has a syntax error without running a program that can take an arbitrarily amount of time to finish.