Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Forth implemented in Rust trait system

github.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Forth implemented in Rust trait system

#71

Post by BeKindAndLearn »

a1369209993 wrote: post #60
crazypython wrote: post #4

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,…

Because that's fundamentally incompatible with a competently-designed compiled language. Consider: fn immutable foo() long: asm(long x:"rax") "mov rax 7" return x Now try cross-compiling that from a 32-bit ARM machine. Aside: D is kind of weird in this regard because most of it is designed to work as a interpreted language as well as a compiled one. To the extent the D is good, it's not compiled[0]; to extent that it…

Pretty much all languages with turing-complete compile-time expressions only expose a subset. This comfortably lands in the "not in that subset" category.

Re: Forth implemented in Rust trait system

#72

Post by TA0X4 »

Animats wrote: post #63
vertex-four wrote: post #12

Earlier quoted context omitted.

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…

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 and documentation because it can delusionally be construed as racist, I'd say they don't know when to stop.

Re: Forth implemented in Rust trait system

#73

Post by a1369209993 »

BeKindAndLearn wrote: post #71
a1369209993 wrote: post #60

Earlier quoted context omitted.

Because that's fundamentally incompatible with a competently-designed compiled language. Consider: fn immutable foo() long: asm(long x:"rax") "mov rax 7" return x Now try cross-compiling that from a 32-bit ARM machine. Aside: D is kind of weird in this regard because most of it is designed to work as a interpreted language as well as a compiled one. To the extent the D is good, it's not compiled[0]; to extent that it…

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.

Re: Forth implemented in Rust trait system

#74

Post by TA0X5 »

Animats wrote: post #63
vertex-four wrote: post #12

Earlier quoted context omitted.

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…

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 and documentation because it can delusionally be construed as racist, I'd say they don't know when to stop.

Re: Forth implemented in Rust trait system

#75

Post by ThA0x1 »

Animats wrote: post #63
vertex-four wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: Forth implemented in Rust trait system

#76

Post by shpongled »

Animats wrote: post #63
vertex-four wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: Forth implemented in Rust trait system

#77

Post by pull_my_finger »

crazypython wrote: post #4

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,…

Terra[1] does this using Lua as it's compile time language.

[1]: http://terralang.org/

Re: Forth implemented in Rust trait system

#78

Post by breatheoften »

dependenttypes wrote: post #48
ImprobableTruth wrote: post #43

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…

> 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 programs are allowed to execute to be tight enough for developers to learn a sense for what is reasonable to do with these features -- as opposed to waiting for runtime.

Re: Forth implemented in Rust trait system

#80

Post by s17n »

crazypython wrote: post #4

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,…

Lisp failed as an industrial language precisely because it has powerful meta programming capabilities. In the real world, nobody wants to have to solve a puzzle every time they visit a new area of the codebase.
Post reply on HN