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.