4 ms·

Kitten, a statically typed, globally type-inferred, GC-less functional stack language, with opt-in layout-based syntax and an effect system to separate pure and

Kitten, a statically typed, globally type-inferred, GC-less functional stack language, with opt-in layout-based syntax and an effect system to separate pure and impure operations. Disclaimer: I wrote this; it’s nowhere near complete, but not bad to play around with. We’re working toward a release in a few weeks, to include some missing language features and a new x86_64 runtime. https://github.com/evincarofautumn/kitten https://github.com/evincarofautumn/kitten http://kittenlang.org/ http://kittenlang.org/

tomp 13y ago
Can I ask you one thing: why did you decide to write a stack-based programming language? I'm really curious, as I personally see nothing good with them. The same kind of non-mathematical syntax as LISP (`1 2 +` as opposed to `+ 1 2`), without any of the goodness (code is data).
- coldtea 13y ago
  Seriously? Ever heard about this Forth thing?
- 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 ago
    I 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 ago
      I 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

tomp 13y ago

Can I ask you one thing: why did you decide to write a stack-based programming language? I'm really curious, as I personally see nothing good with them. The same kind of non-mathematical syntax as LISP (`1 2 +` as opposed to `+ 1 2`), without any of the goodness (code is data).

coldtea 13y ago
Seriously? Ever heard about this Forth thing?
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 ago
  I 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 ago
    I 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