1991 – a server-side web framework written in Forth

The beauty of Forth is that you can write at as low or as high a level as you'd like. I think most Forth programmers would factor out some of these operations into their own words rather than writing such a low-level definition, but there's nothing preventing you from writing your web server like it's assembly code.

The rstack is just a temporary second stack with the caveat that you have to be a bit careful about cleaning it up after you're finished with it. (Unless you intend to do something fun and exotic like : goto r> drop >r ;)

Usually I'm more tense about code that uses rot/-rot; a little harder to keep track of in my head.

I like the (maybe a bad idea?) comment.

Maybe migrating from bashttpd:

https://github.com/avleen/bashttpd

As someone with a similarly retro web framework ( https://fortran.io ), as far as I know, no one has switched to it. I have gotten a few serious inquiries from coders in the sciences or who are making use of their old Fortran skills... but only a very few in two years.

Postmodern. Just like Perl.

That's a nice one, but why not use MS Sans Serif as a font where available, for maximum effect?

Think you can make it into a CSS framework or Bootstrap theme?

That's really nice. I have a stupid amount of nostalgia for the Win95/NT theme.

I wrote a Forth interpreter for WASM some time ago: https://github.com/stefano/wasm-forth

It's not production ready and it's missing a good JS interface, but you can use it to run Forth code in the browser with a basic console interface.

I know Karsten Schmidth made a browser REPL you can try. I don't know the address, but I think he mentions it in this talk: https://juxt.pro/blog/posts/XT16-karsten-schmidt.html

Considering that some Forth implementations were custom hardware that directly implemented the language semantics, it was often quite fast, yes. Most of the bigger Forth systems (gForth, WinForth, BigForth) have some form of threading/task management. The smaller ones, which are often the ones expecting to run natively on microcontrollers with no operating system, expect you to write your own if you need it.

A naive (ie. threaded[1]) Forth implementation will be slow because the jump between each instruction is a very effective way to defeat branch prediction. Of course this doesn't apply to "real Forth" which is compiled into machine code or even less naive Forths which can do inlining, but there are many hobbyist Forth implementations (because they're so easy to write) where this will still be true.

If you're interested I wrote a naive literate Forth implementation which can do inlining: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth... http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth...

[1] "Threaded" in this sense means https://en.wikipedia.org/wiki/Threaded_code not multithreading.

It seems it's supported in some FORTHs: https://stackoverflow.com/questions/32736552/does-forth-supp...

Also of interest - Chuck Moore's* current work is on such a parallel architecture ASIC that uses FORTH: http://www.greenarraychips.com/

*Chuck Moore is the creator of FORTH

Some years ago, I ported ngaro (the retroForth vm) to Go, and made it possible to launch goroutines and use channels. It was very cool.

However, it was Go pre-1.0, so it won't work now. For a while, it was maintained by Charles Childers - the original retroForth author - but I do not think the Go version is still available.

If you want to give it a try (making it work with the latest Go version shouldn't be difficult), have a look at:

https://bitbucket.org/yiyus/ngaro/src

Hmm, sadly Factor is single-threaded I think (so you are stuck with coroutines), but you can make use of multiple cores using channels.

Never used Forth much, but did use NeWS which had a multi-threaded PostScript environment - which was fun.

It would have been cool to serve this from the raw ip like https://1.9.9.1 :P It's actually responding to pings, seems to be in Malaysia.

certain target audiences don't in domain names anymore, they just follow links so it often doesn't really matter.

One process, one HTTP request at a time, buffering excess requests in a queue of up to 255 requests. Here's the main "event loop":

    : start-server { server client }
        begin
            server 255 listen
            server accept-socket to client
            client read-request prepare-response client send-response
        again ;

I think this word's definition should be fairly easy to follow even if you aren't familiar with Forth.

I think it's single-threaded synchronous. https://github.com/urlysses/1991/blob/1991/1991.fs#L469 https://github.com/forthy42/gforth/blob/master/unix/socket.f...

I made it in 2010: https://bitbucket.org/yiyus/ngaro/src

As I said in another comment, it won't work now because Go had not yet reached 1.0 at that time, but it should be easy to get it working again.

Not exactly Forth, but I implemented a small branchless Forth-like language in Go for audio synthesis and music:

https://github.com/boomlinde/acidforth

I think entirely procedural languages are a nice fit for this domain since they make order of operations apparent. Going for something Forth-like was obvious, since it's terse, trivial to implement and makes factoring easy.

That said, I think the documentation of this project is a bit out of date, that the overall architecture is flawed and that stack juggling can be a bit distracting when working with more complex algorithms. I intend to rewrite it some day.

I've always thought Haskell and Forth would make an amazing combo.

I've implemented forth a few times, most recently in perl.

I have a couple of forth-implementations in golang bookmarked. As a quick example take this one:

     $ go get github.com/unixdj/forego
     $ echo '3 4 + dup * . ' | forego 2>/dev/null
     49 ok

ForthGo?

Sounds like it isn't that good if it took them four tries.

What makes you think Go and Forth go well together?

This is not getting enough up votes.

And postfix software!

To stay true to this claim it should’ve been written in Perl.