81–90 of 91 posts
Earlier quoted context omitted.
Rust is getting that, gradually . Uh oh. I'd hoped the language would settle down. The Go crowd knows when to stop. Go is mediocre, but stable.
>The Go crowd knows when to stop. Considering Go is removing "blacklist" from it's code because deranged individuals can delusionally construe it as racist, I'd say they don't know when to stop.
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 really don't want Rust to be crippled with a 1000 of DSL just because devs could write them easily.
Earlier quoted context omitted.
Pretty much all languages with turing-complete compile-time expressions only expose a subset. This comfortably lands in the "not in that subset" category.
> [...] and Lisp do-- allowing full use of the programming language at compile time. If you only expose a subset, you very specifically don't have the full use of the programming language.
Earlier quoted context omitted.
I don't think he's saying that a limit on recursion depth solves this problem. Rather, it's just a similar scenario where a real-world constraint (memory, time, whatever) comes to bear and may make a compilation fail on machine X where the identical code and environment would otherwise succeed on machine Y.
Alright, but that's not a feature, right? Stack limitations are just a natural limitation. Timeouts are something that you'd intentionally introduce, when you don't necessarily need it. And if possible, I'd like to minimize dependency on specifics of the machine as much as possible.
Try doing anything pretty fancy at compile time with templates in C++ or macros in Rust and you'll quickly need to set the recursion depth limit higher.
Earlier quoted context omitted.
> 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. 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 la…
A user configurable parameter for timeout would be a terrible language design mistake. You would want as much as possible to make the timeout not based on runtime -- but on an abstract model of the computation which doesn't actually depend on any machine particular. "Hey your program didn't compile on my machine -- try a faster cpu" would be a nightmarish interaction. You want constraints about how long these program…
Earlier quoted context omitted.
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 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. 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 tim…
The various tools built around Java stand as an example.
Earlier quoted context omitted.
Rust is getting that, gradually . Uh oh. I'd hoped the language would settle down. The Go crowd knows when to stop. Go is mediocre, but stable.
You say that like mediocre is a compliment. But I guess "mediocre" has been the best descriptor of Go from its inception.
Go got some things right, like "goroutines". Other languages are trying to add threads to a language with "async" type callbacks (Javascript), or "async" type callbacks to a language with threads (Python). Those concepts do not play well together, especially when retrofitted. Go does have a one-size-fits-most solution which handles the main use case - a server process handling a very large number of intermittently sending clients.
The same can be said of "functional" add-ons. Full-on functional languages can be OK, but functional features in an imperative language tend to be on the painful side syntactically. Retrofitting "functional" is even worse.
Earlier quoted context omitted.
The most useful values at compile time are types, so straight-up interpreting the core language at compile time is not enough. You need meta-typed named values to transport types in, and meta-functions to pass them to. Fortraith cleverly re-purposes existing features, doing some violence to language usage conventions to achieve it.
> so straight-up interpreting the core language at compile time is not enough. You need meta-typed named values to transport types in, and meta-functions to pass them to. Can you please explain what you mean by this?
However, at macro-expansion time, often what you want to do is examine a Type and expand the macro differently based on some information about the Type.
So you would like your Macro language to have some notion of manipulating Types that is absent from the language itself
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…
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,…
When the capabilities of the constant evaluation system get improved and stabilized, we are going to see the exact feature you are describing. (With the caveat that non-deterministic functions are not allowed to ensure deterministic builds.)