Internals

• Overall program structure
• Data representation
• Plotting subsystem
• Programming language
• Internals of the current prototype

Overall program structure

Before doing any prototyping work, I imagined two approaches to implementing Gnudl.

• A C++ program which invokes guile to parse single expressions and for widget callbacks. The C++ program would go into an eval loop (something like that), receive expressions, then either evaluate them directly or pass them to guile for evaluation. Advantages: Writing a large program in C++ is a more familiar thing to me than a large program in scheme. Disadvantages: I still have to go through and properly figure out using guile as an extension language. I am doing that right now.
• A program written using scheme/guile as glue, invoking individual C or C++ routines to perform fast single tasks. Advantages: There is a great immediacy to writing the whole thing in scheme. Tk access, for example, happens directly. Also, many examples in guile, like ctax, are written directly in scheme. Disadvantages: I know nothing about organizing an extremely large scheme program. Maybe looking at jackal could give a clue.

Both approaches would allow the implementation of command-line parsers and language interpreters: these would simply be built on top of guile. There are some rather nice examples already that interpret other syntaxes within guile; for example ctax interprets C-like infix syntax.

I have since implemented a prototype of the first approach: a C program which sits in a read-eval loop and invokes guile to parse all lines except those that match a set of builtin commands.

Data representation

The mechanism guile provides for sharing data between scheme and C is cumbersome but works nicely.

In the prototyping work so far, I have used scheme vectors/arrays (what's the difference?) to store arrays of data. It works quite nicely, but I have not tested the correspondence of vectors with C vectors (I have tested ints, strings and doubles).

Plotting subsystem

Mike Warren has recommended that plots be stored internally as correct postscript commands.

He also says that ghostscript can be used in library mode and called from a program, although this has turned out to be very hard to use.

If this library interface to ghostscript ever works, the rendering of plots would be quite trivial: we would form the postscript representation, and then let postscript handle fonts, scaling, offsets...

It would be nice to store the last several plots made, as Mathematica does.

It would also be nice to merge the plots nicely with the Tk canvas (and other) widgets. Rendering from scheme would also be nice. We will have to explore these issues, since it is not clear to me that one can give the ghostscript library a Tk window and tell it to draw there.

The plotting system should allow multiple plots (it does already in the prototype: n-x-plots and n-y-plots), and the user should be able to specify "the next plot will be in position (2, 3)".

[I propose another project: a good postscript rendering package which really does work both as a library and as a standalone program. This program should allow the user to pass a window in which the drawing will be done, although a NULL window would mean the library should define it.]

My experiments with this have shown it to be very hard to do, even though ghostscript advertises that its use as a library is a feature. The ghostscript source is poorly organized (it comes from MS-DOS), and the library interface is not defined in any document.

The approach I have taken in the prototype is to open a pipe to ghostscript, and define interfaces to ghostscript from both C and scheme. This has worked quite nicely for elementary rendering of plots.

Programming language

I believe that guile will take care of most of these issues, once it comes close to matching Stallman's spec. It will provide scheme as a principal extension language.

Guile already provides ctax: a C-style infix notation translator.

Guile also plans to support a cleaned-up TCL, Python, Latte (a Java-like language), and several other languages on top of scheme.

Internals of the current prototype

[by Mark Galassi]

I finished the design strawman in June 1995, and quickly implemented a couple of the trivial prototypes (those designed to learn guile).

• The program is called "learn_gnudl"; it can be found in ~rosalia/gnudl/prototype.
• The program starts out by initializing a guile interpreter (in the manner described in Tom Lord's docs on libguile).
• It then initializes a postscript interpreter by opening a pipe to ghoststscript. The ghostscript interface (defined in gs_interface.c) basically provides 3 C primitives: void gs_open_interp();
  void gs_config_win();
  void gs_eval_str(char *s);
  void gs_close_interp();
  
• It then registers a few C routines so they can be called by scheme. One important one is scm-gs-eval-str, which allows the scheme programmer to pass a postscript string to the postscript interpreter.
• It then loads a few scheme source files (ps-plot.scm, idl-emul.scm, yorick-emul.scm) so the routines in those files are available directly to the user.
• It then sits in a loop in which it reads a line of input and passes it to guile to be interpreted; this basically means that the user types at a scheme interpreter.

Another section in this documentation provides a tutorial/primer on using the gnudl prototype.