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

21–30 of 91 posts

Re: Forth implemented in Rust trait system

#21

Post by [deleted] »

ncmncm wrote: post #9
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,…

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.

[deleted]

Re: Forth implemented in Rust trait system

#22

Post by samatman »

saagarjha wrote: post #14
andylei wrote: post #3

> 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.

Incorrect.

Turing completeness means using the syntax of your favorite programming language is "merely" a matter of writing the appropriate program.

What GP is proposing is completely impractical, of course. But not unreasonable, and certainly not impossible.

Re: Forth implemented in Rust trait system

#23

Post by _bxg1 »

saagarjha wrote: post #14
andylei wrote: post #3

> 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.

Any Turing-complete system can do anything a general computer can do, which includes compiling your favorite programming language.

Re: Forth implemented in Rust trait system

#25

Post by megameter »

frompdx wrote: post #17

Definitely 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 term "concatenative language" fits better for adaptations of Forth that also discard major semantics of Forth. There is a holistic quality to Forth that results in a lot of idioms that are not obvious, and concatenative systems that deviate from the whole tend to fall into an unexplored territory.

For example, in CASE ... OF ... ENDOF ... ENDCASE, the input value is consumed when OF is entered. But this means that the default result, positioned before ENDCASE, has to move the input value to the top of stack so that it can be consumed before the result. The examples in the ANS standard prefer using >R ... R> as a scratchpad for this purpose, so that any number of results may be pushed into the data stack, while the input is moved onto the result stack and then pushed back to the data stack. But the whole existence of the return stack and words that use it is a curious detail that doesn't come up if you start from an RPN calculator instead of a complete Forth system. Someone writing a RPN system in an applicative language, upon seeing this semantic, might be tempted to beef up the syntax rather than add this idiom. And in Forth this idea likely was only arrived at through the numerous iterations Moore made to achieve better expression in fewer words, since the return stack is useful everywhere.

Re: Forth implemented in Rust trait system

#26

Post by dimtion »

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

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.

Re: Forth implemented in Rust trait system

#28

Post by dependenttypes »

dimtion wrote: post #26
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,…

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.

Re: Forth implemented in Rust trait system

#29

Post by saagarjha »

_bxg1 wrote: post #23
saagarjha wrote: post #14

Earlier quoted context omitted.

Turing complete≠uses the syntax of your favorite programming language.

Any Turing-complete system can do anything a general computer can do, which includes compiling your favorite programming language.

No, that's not what Turing complete means. Turing complete means it can do an arbitrary computation, but "implementing Rust" usually means it needs to be able to take in a string of code and produce a binary, which means your program needs to have some way of actually doing that. Sure, you can encode the compiler into the Turing machine, but an arbitrary Turing-complete tarpit may not actually have the syntax to know what a string is. Usually the best you can do is encode the programming language into some form the machine can understand. (For example, with Fractran you'd encode your input as some sort of Gödel numbering before giving it to the program.)

Re: Forth implemented in Rust trait system

#30

Post by dependenttypes »

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

It should be noted that gcc and clang both execute certain functions at compile-time at their higher optimization levels.

In addition C++ has constexpr which marks an expression to be evaluated at compile-time.

Post reply on HN