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

Show HN: I built a minimal Forth-like stack interpreter library in C

news.ycombinator.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Show HN: I built a minimal Forth-like stack interpreter library in C

#11

Post by uecker »

zoezoezoezoe wrote: post #6
gabrielsroka wrote: post #5

1. You should add a URL when you you create a post on HN. You can indent code two spaces on HN, eg: Stack s; stack_init(&s); dict_init(); exec(&s, "10 20 + ."); // Prints "30" exec(&s, "1 2 3 4 .s"); // Shows stack contents 2. Your readme mentions a repl but I don't see it in the source code. 3. I'm not an expert in C but I thought header files shouldn't have code in them. The code should be in a .c file 4. Maybe mov…

technically, "header only libraries" can be exceptions to C code not being in header files. See STB as an example https://github.com/nothings/stb . The advantage theoretically is that you can #include this library and use its code and types from just one file, its a decent model IMHO, but it can be jarring to someone unfamiliar with header only libraries.

They have plenty of downsides and only one very minor advantage: You need to copy only a single file instead of two into your source. I am still puzzled why anybody could think this is a good idea...

Re: Show HN: I built a minimal Forth-like stack interpreter library in C

#12

Post by anadem »

tdeck wrote: post #4

If you're interested in learning more about how FORTH works I, I can recommend two very old books. Starting FORTH https://archive.org/details/LeoBrodieStartingFORTHIntroducti... Threaded Interpretive Languages https://archive.org/details/R.G.LoeligerThreadedInterpretive... The latter doesn't even mention FORTH, and describes some very archaic CPU architectures, but I found it fascinating because it builds things from…

Loeliger's 'Threaded Interpretive Languages' jumpstarted my career in the late 1970s: I built a networked water management system based on their code, which was my first big project, earning me £1,500. Note that there's a bug in their code (I no longer remember exactly where) so getting it off the ground was tricky.

Re: Show HN: I built a minimal Forth-like stack interpreter library in C

#13

Post by crq-yml »

You've implemented a stack calculator, which misses the big picture: the stack is an implementation detail that enables a lot of the nifty stuff, but Forth is a "braided language" - the whole is more than the sum of the parts. Each part of it is just implementation, and the implementation is kept simple, but all of it needs to be there to make it completely usable. The distinction is important and non-trivial to the design of the interpreter.

To get there, please implement some of the metaprogramming words found in one of the standardized Forths(and if you aren't sure which one, use an earlier spec like Forth83 since the core wordset is smaller, so you run into the "hard stuff" faster).

Forth used in anger towards an application actually tends to resemble Fortran: procedural idioms flinging around lots of named temporary variables. The stack, being just implementation, doesn't give any assistance for everyday programming, unless you extend the system to do so. This is a point on which modern concatenative languages have diverged and tried to add some rigor into it.

Re: Show HN: I built a minimal Forth-like stack interpreter library in C

#14

Post by matheusmoreira »

> Has anyone else built something similar?

I made my own lisp. It used to have a recursive interpreter but I recently finished converting it into a register/stack machine that's essentially a modified version of the Explicit Control Evaluator from Structure and Interpretation of Computer Programs.

https://github.com/lone-lang/lone/blob/master/source/lone/li...

Now I'm thinking about converting it into a CESK machine which I believe is a proper stack machine. Modifying the SICP machine has proven difficult due to the loose stack discipline. I'm told register machines are faster but keeping track of all those ad hoc pushes and pops is turning into a nightmare.

> What features would you add to make it more useful?

The neat part about all these machines is how the stack itself turns into some sort of code. You push some state indicating what you want the machine to do next. Then you set it up so that it evaluates a value. When it's done, that value just flows into whatever the next computation step is.

Making a copy of the stack and wrapping it into a callable that just plugs that value in is how first class continuations are implemented.

Re: Show HN: I built a minimal Forth-like stack interpreter library in C

#15

Post by 1718627440 »

uecker wrote: post #11
zoezoezoezoe wrote: post #6

Earlier quoted context omitted.

technically, "header only libraries" can be exceptions to C code not being in header files. See STB as an example https://github.com/nothings/stb . The advantage theoretically is that you can #include this library and use its code and types from just one file, its a decent model IMHO, but it can be jarring to someone unfamiliar with header only libraries.

They have plenty of downsides and only one very minor advantage: You need to copy only a single file instead of two into your source. I am still puzzled why anybody could think this is a good idea...

And you also can name your single file to be included .c instead of "hiding the truth".

Re: Show HN: I built a minimal Forth-like stack interpreter library in C

#16

Post by 1718627440 »

zoezoezoezoe wrote: post #6
gabrielsroka wrote: post #5

1. You should add a URL when you you create a post on HN. You can indent code two spaces on HN, eg: Stack s; stack_init(&s); dict_init(); exec(&s, "10 20 + ."); // Prints "30" exec(&s, "1 2 3 4 .s"); // Shows stack contents 2. Your readme mentions a repl but I don't see it in the source code. 3. I'm not an expert in C but I thought header files shouldn't have code in them. The code should be in a .c file 4. Maybe mov…

technically, "header only libraries" can be exceptions to C code not being in header files. See STB as an example https://github.com/nothings/stb . The advantage theoretically is that you can #include this library and use its code and types from just one file, its a decent model IMHO, but it can be jarring to someone unfamiliar with header only libraries.

You can include a .c file just fine.
Post reply on HN