Gnudl Design Strawman

Here are the design goals of Gnudl.

• Gnudl should provide an interactive interface which allows users to easilly manipulate data and make plots.
• A function applied to an array (or matrix or n-dimensional array) of data should be applied in a scalar manner to all elements of the array.
• An array ind of integers can be used as a subscript into an array x[0..N-1], in which case x[ind] is the sub-array of x containing all the elements indexed by x[ind[i]]. (As long as N >= ind[i] for all i.)
• The where primitive in IDL should be provided. An example of the use of "where": if you have an array x[0..999], and you want to know all the indices i for which x[i] > 3.2, you can just use where(x gt 3.2).
• Gnudl should provide one or many extension languages for programming, with full access to all the interactive mode commands, and with full programming language constructs on top of that. Ideally this language should be Guile (the GNU extension and scripting language, based on Scheme), because it allows other extension languages to be run on top of it (TCL, Python, Emacs lisp, ctax, Java). Switching between these languages should be quite straightforward.
• Gnudl should provide X Window and postscript rendering of all plots. This is easilly achieved if all plots are stored internally in postscript form, and a postscript interpreter is used to give the X Window rendering.
• Gnudl should provide a nice interface to the TK toolkit (via Guile, for example).
• Gnudl should provide an extremely vast library of numerical, signal processing, image processing (and so forth) routines. Our plan is to provide a few of these, enough to get people using the package, and then encourage scientists and hackers all over the world to contribute.
• Gnudl should provide high quality documentation, which should be written in TeXinfo and be made available as an info document, as a WWW page, as a printed manual (via TeX) and as a context-sensitive embedded help system. A way of quickly referencing help on individual functions should also be provided. Yorick's system might work well.
• Gnudl should come with high quality and complete documentation and code-commenting, written as the software is developed, rather than later. This is vital: many products die for lack of documentation, or live when they shouldn't because of good documentation. For example, Yorick is a very useful package, maybe equivalent to IDL for most purposes but cleaner. But Yorick is barely documented. There is no tutorial, no reference manual... And few people are using it, even though it is free. Note: As I am writing the gnudl prototype software, I am keeping the prototype tutorial and the demo file up to date with examples of usage.