[6d65]

There's a twitch streamer(tsoding) doing a FORTH like language from first principles.

I've watched a couple of episodes and went started my own. I learned a bit of arm64 assembly, and now I have both an interpreter and a compiler to M1 binaries. Very fun experience.

One day I'll slap a F#/OCaml'esque syntax on top of it with typed functions, structs, interfaces and see if it works.

At their core(it seems to me), concatenative languages are about function (words) composition.

So, instead if having "words", I would make them functions, with typed arguments, and simple argument matching (no more dups and swaps). This would probably make the language less flexible, but will make it more readable.

Anyway, FORTH is nice.

[bitwize]

Sounds like you're in the process of reinventing Factor.

Which is not a bad thing. Go nuts. Just realize that there may be some degree of prior art for what you're doing.

[6d65]

I'm vaguely familiar with Factor and hopefully not in process of reinventing it.

I was planning to investigate this space just for fun. Most likely nothing will come out if it and that's ok, it's just a learning opportunity.

[bitwize]

Nah fam, like I said, go nuts. Even if something exists, reimplementing it is great for the challenge/intellectual curiosity/fun factor. I learned Ada by reimplementing Unix utilities in it.

[qsort]

> So, instead if having "words", I would make them functions, with typed arguments

Interesting idea. Wouldn't it require some compiler magic, though? E.g. you can't type a Y combinator.

[6d65]

Maybe I'm not using the proper FP function term. I don't mean functions as objects that you can store or pass around or higher order functions. Just take some arguments from stack, and return some values.

What I mean is that FORTH words seem to be functions taking stuff from stack and pushing stuff back. The composition is done by chaining them together.

This probably works fine with repl driven development(same as in lisp), you find out during development that your words cannot be composed. But as mentioned by others it may make the code hard to read, having to keep the state id the stack at all times in your head.

I was thinking just adding a light syntax, ex:

let add a b = a b +

// optional type annotation

let square a = a a *

let add-square = add square

Maybe add some type inference, support for structs, match expressions. But at the core keep the low level FORTH nature, with an interpreter and compiler.

It remains to be seen if it's possible to reach a balance here. FP programmers may be disappointed this is not a proper FP language, while FORTH programers may say it's a syntax ridden abomination.

I would say with some tooling (editor support, test framework, god forbid package manager), it can be an interesting option for embedded development.

[richard_todd]

In many forths you can have what they call locals, so your example can be:

    : add {: a b :} a b + ;