Next: The OPUS Pipeline Managers
Previous: Data Structures in STIS and NICMOS
Table of Contents --- Search ---
PS reprint
Karl Glazebrook
Anglo-Australian Observatory, P. O. Box 296, Epping, NSW 2121,
AUSTRALIA
What is a `Glue Language?' Simply, it is a high-level interpreted
language for linking together subroutines written in a lower-level,
compiled, language such as C or FORTRAN. It is generally highly-expressive,
allowing the programmer to use a minimum of code book-keeping and
the interpretive natures facilitates rapid development and maximum
flexibility (e.g., through evaluation of code generated on-the-fly).
Of course these features come at the expense of low-level speed; the
essence of a glue language is that the time-critical parts are coded
in C/FORTRAN and these units are rapidly glued together in a high-level
script expressing the logic.
The canonical example of a glue language is the original
UNIX
shell. More recently much interest has focussed on
the TCL
language primarily because of its ability to glue
together high-level X Window widgets (the Tk system)
to quickly develop Graphical User Interfaces (GUIs).
However there are
numerous problems
associated with raw TCL
for developing larger systems.
A newer alternative is perl , originally written by Larry Wall in 1986 for system administration work (Wall & Schwartz 1991) it has been widely used for many tasks; most notable recently is its predominance in CGI programming on the World Wide Web. The core language has been enhanced greatly in the latest release (v5) to create a well-rounded interpreted language with a style similar to awk and C. It features powerful pattern matching commands and built-in interfaces to operating system calls; and is also overcomes most of the limitations of TCL . perl has proper numbers, data structures, packages and optional OO syntax. Obviously no language is perfect and many people consider the syntax quirky, but most noteworthy for astronomers is the addition of an excellent system for adding compiled language extensions. Dynamic loading is built-in, the perl program only has to say ` use PGPLOT' or ` use OpenGL' to load the required extension. New extensions can be compiled and used without touching the core interpreter. The toolkit Tk , so instrumental in the popularity of TCL , is already available. Dozens of other modules are available for database handling, graphics, Web programming, etc. A perl script can start small, but if the application grows to ambitious scope the language features are there to support it.
TCL is simple to add subroutines too, one simply passes the arguments in the **argv character array exactly as in UNIX commands. However this simplicity is deceptive because the user must provide code to convert these strings to the correct C data type. This, together with the lack of proper arrays, led to my use of perl to interface to the popular astronomy graphics library, PGPLOT. For example consider having the two PGPLOT routines pgdraw and pgbox callable from perl . One would like the user to be able to say:
use PGPLOT; # [+some initialization code such as pgbegin(..)]
pgbox('BCNST',0,0,'BCMST',$tmax*0.2, 5);
pgdraw($x, sqrt($y)+1); pgdraw($x, 1/(sqrt($y)+1));
How does the developer go about glueing this to In perl5 things are both more complex and more straight forward than in TCL . More complex because one has to create a small `XSUB' file which effectively describes the libraries' subroutine parameters. More straight-forward as most of the data conversions are then handled for you automatically. In the XSUB file for PGPLOT ( PGPLOT.xs) pgdraw and pgbox are declared:
void
pgbox(xopt,xtick,nxsub,yopt,ytick,nysub)
char * xopt
float xtick
int nxsub
char * yopt
float ytick
int nysub
CODE:
cpgbox(xopt,xtick,nxsub,yopt,ytick,nysub);
void
pgdraw(x,y)
float x
float y
CODE:
cpgdraw(x,y);
(cpgbox and cpgdraw are the names in the PGPLOT C bindings, if
they didn't have the `c' prefix the CODE: line could be left out
as it would be defaulted).
The CODE: line could be changed appropriately if one was calling
a FORTRAN library directly.
One then writes a makefile (in perl naturally) which might look something
like this:
use ExtUtils::MakeMaker; WriteMakefile( 'NAME' => 'PGPLOT', 'VERSION' => '1.0', 'LIBS' => ['-lcpgplot -lpgplot -L/opt/SUNWspro/SC3.0.1/lib -lF77 -lM77 -lsunmath -lX11 -lm'], 'DEFINE' => '-DHAS_UNIX_FUNCTIONS', 'INC' => '-I/usr/local/pgplot', );(Note the incidental use of a perl structure and the FORTRAN runtime libraries required because PGPLOT is a FORTRAN library.) To build this one then types ` perl Makefile.PL' and ` make dynamic'; the PGPLOT.xs file is used to automatically generate the C code which interfaces perl to C. The typemapping system handles the basic C data types and is extendable (I have extended it to handle C arrays for example). The C code is then compiled into a dynamically loadable object module linked against the required libraries. You also need to provide a short perl module to load it in ( PGPLOT.pm). Then one can call the routines direct from perl with no further need for recompilation exactly as in the example above.
Thus one immediately has an interpreted language that can do graphics, a serious alternative to the niche filled by programs such as MONGO and WIP at a fraction of the effort and with the advantage of being based in a real, extensible language.
Of course there is a catch, in this case it is that, unlike TCL , the extension mechanism is poorly documented. There is a man page, but it is rather technical and hard for beginners. No doubt this situation will improve with time. I feel I am in a good position to comment on how easy this really is because the PGPLOT module was originally developed under perl4 where there was no official extension mechanism available, only a few examples. Moreover it had to be directly compiled into the perl executable, hence the name pgperl. With the new perl5 mechanisms it was orders of magnitude easier, and even easier than TCL as one has to write virtually no actual code---just the template. Better documentation is definitely required though.
Finally another very different astronomical example at this conference is a perl interface to the DSA data-handling library used by the FIGARO package. This module is under development (Economou et al.\ 1996) to provide real-time access to UK Infrared Telescope images and spectra over the World Wide Web.
perl is now a serious contender for the role of glue language in astronomical applications; the ease with which this can now be done is demonstrated by the pgperl example. Arguably it now fills this niche better than TCL , being better able to grow from small to large applications. Of course some of this is personal opinion, languages are notoriously a matter of taste. However the views I have presented are becoming widespread in the non-astronomical computing world. pgperl is freely available to the community by anonymous ftp from: ftp.ast.cam.ac.uk:/pub/kgb/pgperl/ and sundry perl archives.
I would like to thank Frossie Economou for her help in the development of pgperl and the perl-DSA module; and for her insightful reading of the manuscript which removed some of the more outrageous remarks. I would also like to thank the many ever-helpful people out there in the perl and TCL community for the stimulating debates that have excited my interest in this subject.
Libes, D. 1994, Exploring Expect: A TCL-based Toolkit for Automating Interactive Programs, (O'Reilly)
Ousterhout, J. 1994, TCL and the Tk Toolkit, (Addison-Wesley)
Wall, L., & Schwartz, R. 1991, Programming perl, (O'Reilly)