6 ms·

Nice implementation of a concatenative language, and the relatively robust standard library it already has is nice. Is there anything different about its execut

by jdp 13y ago

Nice implementation of a concatenative language, and the relatively robust standard library it already has is nice. Is there anything different about its execution model from languages like Factor or Joy? As far as being purpose-built for code golf goes, there are already even more compact concatenative languages, like F[1] and XY[2], that might give this a run for its money due to K's obvious influence. Then again, it wouldn't be hard to have a rewrite layer to turn mnemonic operations into their expanded rhoScript words :) [1]: http://nsl.com/k/f/f.htm http://nsl.com/k/f/f.htm [2]: http://nsl.com/k/xy/xy.htm http://nsl.com/k/xy/xy.htm

n_c 13y ago
The execution model of rhoScript isn't so different from that of any other concatenative language. There are two differences I can think of at the moment: - The lazyness of lists. "1 naturals (add) map" will produce an infinite list of integers from 1. This introduces some interesting difficulties. For example, what would you expect "1 naturals (add) map 2 swap 5 take" to produce? It will clearly either be (1 2 3 4 5) or (2 3 4 5 6). I pick the first because it produces less surprising results. So, when map is called, it saves the state of the stack, so it doesn't end up seeing the 2 pushed on the stack. - I added lexically-scoped "arguments" to functions because I found them useful. The commands "arg-[a-d]" will "remember" the top four values on the stack, even if the lazyness of the language changes the top four values on the stack by the time it reaches these commands. I guess one other difference is that functions here are typed, but that's not really a fundamental difference with other concatenative languages. As for F and XY, I haven't looked in to them much. A cursory glance, however, leads me to believe that when pushed to their limits, I'd expect the arithmetic-encoded programs to be significantly shorter. The 22 different tokens in the 8 queens program condense in to 17 bytes. (And, this assumes that all functions of a valid type are equally likely to be called -- I'd expect most programs to get shorter once I spend some time figuring out reasonable weights for the encoder). That said, I definitely see some things I'm going to steal from those languages.
- tel 13y ago
  How are you doing the concatenation typing? Is it like Cat's type system? http://cat-language.com/ http://cat-language.com/
  - n_c 13y ago
    It's very similar. There are major differences with how functions are typed, however. Namely, in Cat, they are, and in this, they are not. There's a good reason for that, though! Imagine you write the program "(add print) call". Clearly that function takes two integer arguments. Right? Well, that's only because you're looking at the high-level version. Compile it down and you get AE 1D B0 88. If you run it on two integers, you get the sum, as expected. But what happens if you run it with a list on the stack? Then it happens to run the program "(arg-min arg-a) call". Why? The arithmetic-decoder just sees some bytes, and it decodes them to match the correct types. Representing the actual type of functions would require more bits, make programs longer, and so I haven't implemented that. I'm still pondering things to do here.
    - pestaa 13y ago
      This is the first time I've seen dynamic typing arising from simple systems as opposed to making the implementation more complex. Beautiful!
    - tel 13y ago
      From a Haskell background I want to suggest typeclass mechanisms to enable valid polymorphism types. The compiled form can be the same, but the classes help to note that the initial syntax version has that kind of polymorphic effect.
  - fosap 13y ago
    IMO a types stack languages does not make much sense. If the stack side effect is typed a function does alway have to return the same number of arguments and consume the same number. That IMO takes the by far biggest advantage of postfix languages away.
    - 13y ago

by jdp 13y ago

n_c 13y ago

The execution model of rhoScript isn't so different from that of any other concatenative language. There are two differences I can think of at the moment: - The lazyness of lists. "1 naturals (add) map" will produce an infinite list of integers from 1. This introduces some interesting difficulties. For example, what would you expect "1 naturals (add) map 2 swap 5 take" to produce? It will clearly either be (1 2 3 4 5) or (2 3 4 5 6). I pick the first because it produces less surprising results. So, when map is called, it saves the state of the stack, so it doesn't end up seeing the 2 pushed on the stack. - I added lexically-scoped "arguments" to functions because I found them useful. The commands "arg-[a-d]" will "remember" the top four values on the stack, even if the lazyness of the language changes the top four values on the stack by the time it reaches these commands. I guess one other difference is that functions here are typed, but that's not really a fundamental difference with other concatenative languages. As for F and XY, I haven't looked in to them much. A cursory glance, however, leads me to believe that when pushed to their limits, I'd expect the arithmetic-encoded programs to be significantly shorter. The 22 different tokens in the 8 queens program condense in to 17 bytes. (And, this assumes that all functions of a valid type are equally likely to be called -- I'd expect most programs to get shorter once I spend some time figuring out reasonable weights for the encoder). That said, I definitely see some things I'm going to steal from those languages.

tel 13y ago
How are you doing the concatenation typing? Is it like Cat's type system? http://cat-language.com/ http://cat-language.com/
- n_c 13y ago
  It's very similar. There are major differences with how functions are typed, however. Namely, in Cat, they are, and in this, they are not. There's a good reason for that, though! Imagine you write the program "(add print) call". Clearly that function takes two integer arguments. Right? Well, that's only because you're looking at the high-level version. Compile it down and you get AE 1D B0 88. If you run it on two integers, you get the sum, as expected. But what happens if you run it with a list on the stack? Then it happens to run the program "(arg-min arg-a) call". Why? The arithmetic-decoder just sees some bytes, and it decodes them to match the correct types. Representing the actual type of functions would require more bits, make programs longer, and so I haven't implemented that. I'm still pondering things to do here.
  - pestaa 13y ago
    This is the first time I've seen dynamic typing arising from simple systems as opposed to making the implementation more complex. Beautiful!
  - tel 13y ago
    From a Haskell background I want to suggest typeclass mechanisms to enable valid polymorphism types. The compiled form can be the same, but the classes help to note that the initial syntax version has that kind of polymorphic effect.
- fosap 13y ago
  IMO a types stack languages does not make much sense. If the stack side effect is typed a function does alway have to return the same number of arguments and consume the same number. That IMO takes the by far biggest advantage of postfix languages away.
  - 13y ago