WishList for Development tools

This page contains a wishlist for the development tools (RML compiler, extended Modelica compiler, Emacs environment, debugger, etc.

Debugger

* Debug binary working as any C/C++ compiled binary, i.e. possible to execute from a shell without getting a prompt. The debugger should then run in fast mode.

* Debugger should in some way indicate last succeded premiss. It is otherwise very hard to follow the program flow, especially if several relations fail in sequence.

* Debugger should be able to run until a fail is encountered. This is very useful since most relations are written such that a fail is a bug, e.g. an uncovered case, etc.

* Remove bug that updates current line in the emacs rmldb mode. For premisses that cover several lines this does not work.

RML compiler

* Better syntax error message format. Now it is hard to read the syntax errors when e.g. a '&' is forgotten. A suggestion is to skip outputting all the tokens that are removed until the parser restarts with a valid grammar. Then if a second or more syntax error occurs that should be printed similarily.

* Allow for more than one type error at the time. It takes too long time to find all the type errors if only a single type error per compilation is detected.

* Implement more of the builtin math functions, e.g. real_tan, real_acos, real_asin, real_atan, etc. Now they are implemented in System.rml, but it is cleaner if they are implemented in RML.

Extended Modelica Compiler

* Allow pattern matching with named arguments. This would allow us to skip writing a lot of underscores for positions not interesting.

* Design and implement support for generics (i.e. like C++ templates). Design goal: It should be possible to reuse the code for a hashtable implementation. It is unclear whether this works today. PA tried to make a generic Hashtable implementation in RML but failed. If this was due to lack of insights in the RML language or limitation in the RML language is unclear.

* Global variables.

PA: This would remove the referential transparency property of a functional language. I would argue that this is not a good idea to add. It is certainly a point to discuss. With a low level imperative language (C/C++) global variables can both be very useful and very dangerous. The question is if we would have the dicipline to use global variables in a good way. The risk is that developers that need global variables implement them in external functions instead.

Tools

* Change the perl hack that outputs latex from .rml files to produce html, so that we get a nice documentation of the code, similar to doxygen.

* Make a tool that transforms the RML-sourcecode to html so that relation-names in code are generated as links to the definition of the relation.