n_c

I found CL really nice. One nice feature about SBCL is it can be incredibly fast. Sure, not as fast as raw C, but it approaches it. (This is useful when you're using CL as your IR.)

The macros were the big win for me with this. I have only a few macros, but without them, the code would be significantly uglier. The entire builtin-generator is a big giant macro, and it was very nice to define my own little DSL to build commands. (fun story: I originally started developing this as a Python interpreter, and abandoned it because (a) it was far too slow, and (b) it was difficult to build a clean, abstract, method of writing builtins)

Other than the macros, the other big win was how easy it is to generate lisp code. There's no string munging, just (cons 'add cmds) and you're done.

There are some things I don't like about it. I think Scheme has it right with functions and variables sharing one namespace. I find the common lisp

    (defun something (a)
        (map #'square (funcall a)))

much uglier than the scheme equivalent of

    (define (something fn)
        (map square (fn)))

but that's purely cosmetic.

Yeah, I hope at some point to do that. I expect only a few bytes need to be added to make the outputs be exactly identical. Almost all code-golf programs will be correct output rule "if a 1-d list is on the top of the stack dump it joining on '\n', if a 2-d list is on the top of the stack dump it joining on ' ' first and then on '\n'.

Okay, I had an issue with www.rhoscript.com and rhoscript.com causing XHR errors.

re: the try.html page: don't include the "run" word. That's just a button I put on the pages to send you there automatically.

    "hello" print

Not yet, that's definitely a priority though.

Well that's embarrassing! (fixed)

(By "common problems" I assume you mean "common codegolf problems" and not "common issues programmers encounter using it" -- if you do mean the latter let me know.)

The best compilation of code-golfing problems I've seen is Anarchy Golf [1]. Pick almost any problem you want, implement it in rhoScript naively, and you'll get a much shorter solution. (Except those problems which use things not currently present, anything like, say, floating point numbers.)

If you look at some of the examples I have compared to the programs others have written, you'll get a brief sense. My eight-queens is 17 bytes, the shortest on Anarchy Golf [2] is 42. A solution to the 196 algorithm problem [3] in rhoScript takes 16 bytes compared to 24. But that's just cherrypicking problems I found interesting. I haven't yet done a real random sample to see how well it does.

Note, however, that the programs you write in rhoScript don't yet format the output to conform correctly, so they may require a few more bytes for that.

    [1] http://golf.shinh.org/
    [2] http://golf.shinh.org/p.rb?N+Queens
    [3] http://golf.shinh.org/p.rb?196+algorithm

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.

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.

I submitted a link to this yesterday, but realized I misconfigured nginx/sbcl and so the "try" page ended up almost crashing the server, so I took it the link down a few minutes later. I'm resubmitting now.

If anyone has feedback let me know!