6 ms·

What is the value prop of a stack-based language?

by platz 8y ago

cultus 8y ago
Everything is based on composition, which makes it easy to build computations up like building blocks. Stacks are also efficient. The JVM bytecode is actually a stack language, for example. There's a newer one called Kitten that is statically typed and uses term rewriting to allow for more normal syntax when you want. It's pretty cool. Too bad none of these languages will ever take off.
- bgongfu 8y ago
  And since composition is seamless, and they're relatively trivial to implement; they make great glue/DSL/process description languages. Take off as in replace C++ or Java, probably not. I see them more as a complement to existing languages, a more convenient way to glue the pieces together. Even wrote my own [0] to see how far it's possible to push that idea in C. [0] https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl
  - rurban 8y ago
    Interesting. But does cixl really do refcounting on stack values? It should only be done on aggregates or objects reaching out into the heap, not on int or float primitives on the stack.
    - bgongfu 8y ago
      Primitive types such as booleans, int, floats, times etc. are passed by value. Reference counting is only used for heap allocated values and types that themselves reference values, like pairs and tables. https://github.com/basic-gongfu/cixl/blob/master/src/cixl/box.h https://github.com/basic-gongfu/cixl/blob/master/src/cixl/bo...
- Someone 8y ago
  ”Stacks are also efficient. The JVM bytecode is actually a stack language, for example.” The advantage of stack-based is that instructions need not tell where there arguments live, making them smaller (if you have 16 integer registers, for example, a simple “add register I to register j, store result in register k” instruction needs 12 bits to encode the values of i, j, and k. That’s quite a lot if your instructions are 16 bits) The disadvantage is that you have to move data to where instructions expect to see it before you can do computations. That makes your code larger and slower. Last I know needing more instructions to do the same is more of a problem than having smaller instructions solves (https://www.usenix.org/events/vee05/full_papers/p153-yunhe.pdf https://www.usenix.org/events/vee05/full_papers/p153-yunhe.p...), but that’s over 10 years old.
- vanderZwan 8y ago
  > Too bad none of these languages will ever take off. I'm sure they will at least inspire some good features in others.
- munificent 8y ago
  > Stacks are also efficient. The JVM bytecode is actually a stack language, for example. Being stack-based doesn't help JVM efficiency. Modern JVM's take that bytecode and immediately translate it to some other non-stack-based form and then compile it. JVM bytecode is effectively a serialization format for syntax trees. (Stacks are a nice notation for serializing a tree.)
carapace 8y ago
Forth, Factor, Joy, et. al. provide a fundamentally better mental environment for thinking about problem solving (in code.) You'd have to read "Thinking Forth" by Brodie (out of print; PDF made available here: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ ) and actually play with them for a bit to catch on though, there's no substitute, I think.
- the_grue 8y ago
  I played with Factor when it was new and never managed to advance to a stage where I wouldn't have to come back and fix stack corruption. And then again, and again, even for simple pieces of code. YMMV.
  - carapace 8y ago
    But did you read "Thinking Forth"? :-)
    - the_grue 8y ago
      Nope.
  - vanderZwan 8y ago
    What I find a bit strange is that outside of Kitten (and Cat before it) nobody seems to have tried to make any stack-based languages with a strong typing system that prevents this. I mean, shouldn't it be trivial to follow which type of data a word expects from a stack, and which type it returns? The only limitation I can think of is words that leave a variable amount of data on the stack (one workaround would be to forbid that, or to have the type system be able to express that as well). I suspect something like Julia's type system, with Bits types and Abstract types, would work perfectly here[0][1]. [0] https://docs.julialang.org/en/release-0.4/manual/types/#bits-types https://docs.julialang.org/en/release-0.4/manual/types/#bits... [1] https://docs.julialang.org/en/release-0.4/manual/types/#abstract-types https://docs.julialang.org/en/release-0.4/manual/types/#abst...
    - 8y ago

What is the value prop of a stack-based language?

by platz 8y ago

What is the value prop of a stack-based language?

Everything is based on composition, which makes it easy to build computations up like building blocks. Stacks are also efficient. The JVM bytecode is actually a stack language, for example. There's a newer one called Kitten that is statically typed and uses term rewriting to allow for more normal syntax when you want. It's pretty cool. Too bad none of these languages will ever take off.

bgongfu 8y ago
And since composition is seamless, and they're relatively trivial to implement; they make great glue/DSL/process description languages. Take off as in replace C++ or Java, probably not. I see them more as a complement to existing languages, a more convenient way to glue the pieces together. Even wrote my own [0] to see how far it's possible to push that idea in C. [0] https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl
- rurban 8y ago
  Interesting. But does cixl really do refcounting on stack values? It should only be done on aggregates or objects reaching out into the heap, not on int or float primitives on the stack.
  - bgongfu 8y ago
    Primitive types such as booleans, int, floats, times etc. are passed by value. Reference counting is only used for heap allocated values and types that themselves reference values, like pairs and tables. https://github.com/basic-gongfu/cixl/blob/master/src/cixl/box.h https://github.com/basic-gongfu/cixl/blob/master/src/cixl/bo...
Someone 8y ago
”Stacks are also efficient. The JVM bytecode is actually a stack language, for example.” The advantage of stack-based is that instructions need not tell where there arguments live, making them smaller (if you have 16 integer registers, for example, a simple “add register I to register j, store result in register k” instruction needs 12 bits to encode the values of i, j, and k. That’s quite a lot if your instructions are 16 bits) The disadvantage is that you have to move data to where instructions expect to see it before you can do computations. That makes your code larger and slower. Last I know needing more instructions to do the same is more of a problem than having smaller instructions solves (https://www.usenix.org/events/vee05/full_papers/p153-yunhe.pdf https://www.usenix.org/events/vee05/full_papers/p153-yunhe.p...), but that’s over 10 years old.
vanderZwan 8y ago
> Too bad none of these languages will ever take off. I'm sure they will at least inspire some good features in others.
munificent 8y ago
> Stacks are also efficient. The JVM bytecode is actually a stack language, for example. Being stack-based doesn't help JVM efficiency. Modern JVM's take that bytecode and immediately translate it to some other non-stack-based form and then compile it. JVM bytecode is effectively a serialization format for syntax trees. (Stacks are a nice notation for serializing a tree.)

carapace 8y ago

Forth, Factor, Joy, et. al. provide a fundamentally better mental environment for thinking about problem solving (in code.) You'd have to read "Thinking Forth" by Brodie (out of print; PDF made available here: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ ) and actually play with them for a bit to catch on though, there's no substitute, I think.

the_grue 8y ago
I played with Factor when it was new and never managed to advance to a stage where I wouldn't have to come back and fix stack corruption. And then again, and again, even for simple pieces of code. YMMV.
- carapace 8y ago
  But did you read "Thinking Forth"? :-)
  - the_grue 8y ago
    Nope.
- vanderZwan 8y ago
  What I find a bit strange is that outside of Kitten (and Cat before it) nobody seems to have tried to make any stack-based languages with a strong typing system that prevents this. I mean, shouldn't it be trivial to follow which type of data a word expects from a stack, and which type it returns? The only limitation I can think of is words that leave a variable amount of data on the stack (one workaround would be to forbid that, or to have the type system be able to express that as well). I suspect something like Julia's type system, with Bits types and Abstract types, would work perfectly here[0][1]. [0] https://docs.julialang.org/en/release-0.4/manual/types/#bits-types https://docs.julialang.org/en/release-0.4/manual/types/#bits... [1] https://docs.julialang.org/en/release-0.4/manual/types/#abstract-types https://docs.julialang.org/en/release-0.4/manual/types/#abst...
  - 8y ago