Crafting Interpreters is a good recommendation, and in the same spirit "Writing an Interpreter in Go" (and it's followup about writing a virtual machine) is a good addition.
A lot of the complexity and front-work of these kinda things is the parsing step though, so you can follow MAL (or any other make a lisp tutorial) though that won't necessarily help with other languages it frees you to jump to the interesting parts.
FORTH, mentioned in another comment, has that same appeal. I wrote a quick tutorial here, back in the day:
I tried reading the dragon book in my teens, never really understood it, it was too much theory for me.
I'd recommend starting with implementing a forth since it's the easiest language to write an interpreter/compiler for. From there you'll have enough experience to go for something bigger.
Making your own bytecode is really fun.
Ultimately you'll probably want your compiler to target llvm bytecode so that it works on every target automatically.
That’s a feature of the abstract machine. TM and Von Neuman is very reliant on a global (and locals) state. Lambda calculus does not and instead requires evaluation (or reduction in symbolic terms).
Best bet for this is some book on computation theory, but as the name says, they’re full of theory, but it’s kinda the foundation of everything.
> separate state and code
Not really possible. The name “code” cames from the fact that you’re encoding logic and data to represent a process. It’s a closed system and the above books explain how and why it works.
> ai native debugger
What does that mean? A debugger is mostly the capability to stop a process and inspect the current state. How does AI helps?
> native deterministic simulation testing
What does that means?
> coding proofs
Again, the books on computation theory will helps. Most of them will only explain the context free grammars (tightly coupled to TM). There’s a bunch of abstraction on top of that that leads to C, JavaScript and Python. There’s also the various other systems like Horn clauses, lambda calculus, and relational algebra. All have mathematical models that are the basics of such proofs.
> explicit type system
The main book I can recommend is Types and Programming Languages by Pierce. It also requires a good knowledge of basic computation theory. Quick note: Computation does data transformation, types helps with proving that.
> repl
While not impossible, it clashes with the above. Explicit typing is cumbersome to write while REPL is all about quick iteration. Some simple software like ed and ksh can help there.
> wasm target
Going from assembly to C is about design abstractions, compiling C to assembly is building those abstractions. Targeting wasm is about design what would take you to go from wasm to you abstract machine that is capable of executing your language and then starting to build it.
Related? An AI lang from the creator of Kotlin
https://codespeak.dev
Crafting interpreters. Very well written and free of cost, but ofc I’d recommend purchasing a copy.
If you find it a bit hard to chew, there is a simpler book using Python: https://www.amazon.ca/Anthony-J-Dos-Reis/e/B001KE4SU8/ref=dp...
Another book: Game Scripting Mastery.
Crafting Interpreters is a good recommendation, and in the same spirit "Writing an Interpreter in Go" (and it's followup about writing a virtual machine) is a good addition.
A lot of the complexity and front-work of these kinda things is the parsing step though, so you can follow MAL (or any other make a lisp tutorial) though that won't necessarily help with other languages it frees you to jump to the interesting parts.
FORTH, mentioned in another comment, has that same appeal. I wrote a quick tutorial here, back in the day:
https://github.com/skx/foth
I tried reading the dragon book in my teens, never really understood it, it was too much theory for me.
I'd recommend starting with implementing a forth since it's the easiest language to write an interpreter/compiler for. From there you'll have enough experience to go for something bigger.
Making your own bytecode is really fun.
Ultimately you'll probably want your compiler to target llvm bytecode so that it works on every target automatically.
> separate effect full code from pure logic
That’s a feature of the abstract machine. TM and Von Neuman is very reliant on a global (and locals) state. Lambda calculus does not and instead requires evaluation (or reduction in symbolic terms).
Best bet for this is some book on computation theory, but as the name says, they’re full of theory, but it’s kinda the foundation of everything.
> separate state and code
Not really possible. The name “code” cames from the fact that you’re encoding logic and data to represent a process. It’s a closed system and the above books explain how and why it works.
> ai native debugger
What does that mean? A debugger is mostly the capability to stop a process and inspect the current state. How does AI helps?
> native deterministic simulation testing
What does that means?
> coding proofs
Again, the books on computation theory will helps. Most of them will only explain the context free grammars (tightly coupled to TM). There’s a bunch of abstraction on top of that that leads to C, JavaScript and Python. There’s also the various other systems like Horn clauses, lambda calculus, and relational algebra. All have mathematical models that are the basics of such proofs.
> explicit type system
The main book I can recommend is Types and Programming Languages by Pierce. It also requires a good knowledge of basic computation theory. Quick note: Computation does data transformation, types helps with proving that.
> repl
While not impossible, it clashes with the above. Explicit typing is cumbersome to write while REPL is all about quick iteration. Some simple software like ed and ksh can help there.
> wasm target
Going from assembly to C is about design abstractions, compiling C to assembly is building those abstractions. Targeting wasm is about design what would take you to go from wasm to you abstract machine that is capable of executing your language and then starting to build it.