Map/TabCalc was and will be a central part of ILWIS. In ILWIS 3 it is a very compact way to do calculations on whole data sets at once. It is easy to learn and forms the basis for many scripts that access ILWIS 3 functionality. However, it is far from perfect.
- There is a confusing set of interfaces with different names and different subsets of the command set. You have the commandline, simplecalc, mapcalc, tabcalc, script; not easy to explain the differences between them. Is this really needed? I don’t think so.
- There is a severe lack of conditionals and looping in the script. That’s ok if you have the IFF constructs, but they only work in a single call. There is no IF/THEN/ELSE. There is no WHILE. This severely limits the control you need for a script. Now you might make a case that you don’t need that since you can integrate ILWIS with the ILWIS-C commandline construct in almost any existing script environment. I do sympathize somewhat with this argument, but I don’t like a mandatory dependency on some external scripting environment (e.g. python). I do need to make a scripting environment for backward compatibility anyway, so improving it is not that big a deal.
- The implementation of the current scripting is a mess. Its performance is ok. It does things reasonably efficiently, but it is one of the very few parts of the code in which I would rather not make any changes. The inner workings of it are rather obscure. As far as I know (the core of it was written before I started with ILWIS), there is no formal syntax with nice EBNF notation that runs through a parser/lexer generator combination to generate some abstract syntax tree or equivalent. It is a meticulously, hand crafted parser/lexer that does all the (very) complicated stuff that is normally obscured from the programmer and you must understand it if you want to make changes. I don’t expect that many readers have ever made custom languages (I have), but that is a horrible way to do it. As programmer, I only want to deal with the EBNF and (in this case) the abstract syntax tree. The unreadable code that connects these two is automatically generated with well know techniques and proven tools (that was also the case 18 years ago. I am a bit puzzled why those tools were not used).