Bugs and Missing Features in the Alpha Compiler

There are a large number of features which rhoScript will contain in the future, but currently does not. This list contains a few of them.
  • More Number Types. The only number type that currently exists is an unbounded integer. There is no handling of any kind of non-integer numbers (floats, doubles, fixed precision decimals, rationals) -- all of these need to be added.
  • Debugging. Just about the only useful piece of information the compiler spits out is "error: error" at the moment. In the compilation pass running through the code, it would be useful to enter a debugger upon crashing, where you can inspect the stack and identify what went wrong.
  • Format String Printing. Lisp's format string printing is very powerful, and adding such a format language would be useful. It would be good to allow printing of lists in just the right way to match the required output specification. At the moment, formatting data well with rhoScript is nearly impossible, and the user must either rely on the automatic pretty-printing, or construct a string which will be printed.
  • Error "Handling". It should be impossible to cause the runtime system to crash. A crash is never a useful outcome: if at all possible, we should try to recover from any errors. For example, if a function tries to use more arguments than exist on the stack, we could try duplicating an element on the stack at some point earlier and restart execution from there. Or, accessing an array out of bounds should be replaced by accessing some useful element.
  • APL (/R/NumPy/Matlab) style arrays. Lists currently are in a form similar to most programming languages -- lists contain data, and operations are applied to the list and not to the data contained in the lists. By adding APL style arrays, it would be possible to create a list of list of integers, and run "3 add" to add three to every element instead of "((3 add) map) map".
  • An Optimizing Compiler. The current compiler doesn't optimize the generated common lisp code very much. There is a large overhead for every function call, and even sequences of functions are not efficient to run. This is actually important for code golf: if a program can be written in shorter but slower form, it should be doable and the performance of the language should allow it.
  • Regular Expressions. Currently, there are no forms of regular expressions. We use cl-ppcre internally for some string processing, but there is not way for a program to actually use it. It would also be inefficient to use (in terms of space), and we will need to create a new regex format and use it as the the backend.
  • More Advanced Builtins. All of the builtins currently are fairly common functions someone might want to use. If we were to add builtins for complicated, but useful, algorithms, large classes of problems would become trivial. We will start with a constraint-satisfaction solver, a linear program solver, and a few graph algorithms.
  • More Efficient Builtins. There are several builtin functions which are not as efficient as they could be. Also, some builtins behave sub-optimally when dealing with infinite lists. For example, computing the outer product of two infinite lists should eventually reach any given pair of elements, but this doesn't happen; instead, it just shoots off to infinity on the first list and the second stays on its first element.
  • A More Specific Type System. A better type system would allow for more efficient use of command space. While many operations are valid on any list (e.g., concatenate), other operations are only valid on specific types of lists (e.g., sum is meaningless on a list of functions). Related to this, it is possible to type functions better: knowing, at least, how many arguments they take would help determine which builtins can use those functions.
  • Better Builtin Weights. The current weights the arithmetic encoder uses are all 1s. (That is, the arithmetic encoder assumes that all functions with a type matching the arguments on the stack are equally likely to be called, even though this is not the case. As a simple example, both map and uniq-by have types function -> list -> list, but map is (probably) more likely to be called.) After enough rhoScript code exits, it would be good to do an analysis and see which functions are actually used most often and assign weights accordingly. We intentionally did not weight functions differently for the initial releases to minimize bias against picking one function over another during development.