|
Top-level
 @vanja It's for Uxntal. Type inference in stack-based programming language is done by checking the stack effect declarations of words before they can be run, against the cumulative stack state of each item in the definition. Words that do not pass the stack checker are rejected and cannot be run, and so essentially this defines a very simple and permissive type system that nevertheless catches some invalid programs. 9 comments
@vanja You might enjoy these if you're still considering it: https://prl.khoury.northeastern.edu/blog/static/stack-languages-talk-notes.pdf If you decide to target Uxn, lemme know if you need a hand, I'll be happy to help. :) @neauoire So I've decided to continue working on it. Do you have an explanation of the encoding of instructions in uxn? I found https://wiki.xxiivv.com/site/uxntal_reference.html#opcodes, but I don't understand it. What I'm trying to do first is making an emitter for the opcodes before I start working on the language itself. (If just an emitter already exist for C, I'd be happy to use that) @vanja Ah yes, ok. So you're planning to target uxn, have you written uxntal before? @vanja okay perfect, each instruction is 1 byte long. I recommend that you pick a uxntal disassembler(Dexe, beetbug, etc..) and disassemble simple programs to see how they map to bytecode. But generally, there's a couple of immediate opcodes(LIT, JMI, JCI, JSI) where their value is found after the opcode, and the rest is all postfix. @neauoire what bits of each instruction signify the modifiers (2, keep mode, return mode), and which are the opcode itself? |
Gregory's Server
@neauoire Oh that's really cool! Reminds me of the type checking I wanted to implement for a functional stack based programming language. For each function you'd have to write its input and output stack. Though this one actually did have multiple types such as ints, floats and chars (i haven't decided yet which ones). I was actually thinking of compiling it to uxn bytecode! Maybe I finish it one day.