3 ms·
In Factor, code is data. Remember, though, that there are many sources of goodness in a language. As for your actual question, I decided to write a stack-based
by evincarofautumn 13y ago
In Factor, code is data. Remember, though, that there are many sources of goodness in a language. As for your actual question, I decided to write a stack-based language because:
• They can be implemented very efficiently on real hardware. The stack-based VM is well established as an implementation technique for non–stack-based languages.
• Like in Lisp, the simple structure makes them suitable for useful visualisations beyond the program text. Static typing creates even more cool possibilities for such analysis.
• There is fertile ground for new research, and applying existing theory to these languages for the first time—particularly type and effect systems.
• It’s just a lot of fun. :)
- tomp 13y agoI agree with all of those, to me is just seems like transformation into stack-based language should be made as part of the compilation process, not written down by the programmer. Maybe it's just me, I totally admit that I'm not used to thinking in concatenative languages as I've never used one, but mathematics, with named variables and control- and data-flow denoted by functions or sequential lines of operations, seems the most natural notation to read, write and think in.
- evincarofautumn 13y agoI totally understand. In fact, Kitten has named variables for that reason. You can write code that looks imperative, expressiony, or dataflowy, according to taste. Here’s a silly example: // Implicitly thread state between functions. def promptInt: ": " cat prompt readInt fromSome // Write stacky code if you want. def squareDiff: - dup * // Use locals as much as you need to. "x0" promptInt ->x0 "y0" promptInt ->y0 "x" promptInt ->x "y" promptInt ->y x0 x squareDiff ->a y0 y squareDiff ->b a b + sayInt