00:33 <tp> bluekelp, g'day!

00:34 <tp> bluekelp, mecrisp works on MSP430, Cortex-m, Risc-v and some FPGA

00:35 <tp> bluekelp, Mecrisp-Stellaris is the version for Cortex-m, Mecrisp for MSP430, Mecrisp-Quintus for Risc-v

23:38 <tabemann> question

23:39 <tabemann> does anyone have any recommendations on how to implement CREATE and <BUILD / DOES> in a native code forth?

23:39 <tabemann> okay, for crab1, who just entered:

23:39 <tabemann> does anyone have any recommendations on how to implement CREATE and <BUILD / DOES> in a native code forth?

23:39 <crab1> wym by native code

23:40 <tabemann> like it compiles to actual processor instructions

23:41 <siraben> Anyone know of a formal semantics for a subset of Forth? I'm working through http://concrete-semantics.org/ and there's some pretty interesting stack machine compilation going on in the later chapters.

23:41 <siraben> This is pretty good; https://pdfs.semanticscholar.org/43cd/c0f52701e022b506b5819d6a3c4fea12c001.pdf

23:41 <siraben> "Forth Semantics for Compiler Verification"

23:43 <tabemann> to me at least, there's a reason even Haskell doesn't have formal semantics

23:43 <siraben> tabemann: Yes, but the core language, System F Omega, does.

23:44 <siraben> Also Haskell is enormously complex at this point to do a formal semantics.

23:44 <tabemann> yeah

23:44 <crab1> Haskell is too much

23:44 <siraben> Given Forth's simplicity, it would be a good way to learn about grounding a small language's semantics, IMO.

23:45 <tabemann> the problem I see with forth is that it has direct arbitrary access to memory

23:45 <siraben> crab1: Could you elaborate?

23:45 <siraben> tabemann: Right, and self-modifying code as well.

23:45 <tabemann> exactly

23:46 <siraben> (there is research on SMC, but that's way beyond a toy stack language I'm trying to practice formal semantics on)

23:46 <siraben> research on SMC semantics*

23:46 <siraben> http://flint.cs.yale.edu/flint/publications/smc.pdf

23:47 <siraben> tabemann: Then a small core has to be kept, w/out SMC or direct access to memory.

23:47 <siraben> Stack operations, WHILE, IF, various looping operators.

23:47 <siraben> Return stack too, perhaps.

23:47 <crab1> Haskell is too much: the language is complicated, there's too much to know and keep track of when using it, I think

23:49 <siraben> crab1: I think the language is actually pretty small. The ecosystem and libraries are huge, yes, but recently seeing a small self-hosting compiler with a C runtime has changed my mind; https://github.com/blynn/compiler

23:50 <siraben> Certainly, the variuos language extensions added over the years have added complexity enormously.

23:50 <siraben> s/variuos/various

23:50 <crab1> Also I like that forth programs can be self modifying and allow memory manipulation to occur freely, it shouldn't be terribly hard to ensure a word does not modify the program or do bad with memory

23:51 <siraben> crab1: Right, seems like it's just a matter of seeing if an arbitrary write happens for that word.

23:52 <crab1> siraben: I would argue that becoming a regular haskeller requires you to be involved in the ecosystem, like the ecosystem and the language are inseperable

23:52 <crab1> also I need to stop participating in multiple tracks of conversation at once, it's weird

23:52 <siraben> crab1: Yeah, to transition to using a language do things, ecosystem is a must, and I agree that it's pretty wild out there.

23:53 <siraben> Sort of fun, we'll see what comes out of it all, decades from now.

23:54 <crab1> I do like functional though, I just think I need a different language for it

23:54 <siraben> Thanks for the inputs crab1, tabemann, I've got to go.

23:54 <crab1> toodleoo