From fa080de7afc95aa1c19a6e6fc0e0708ced2eadc4 Mon Sep 17 00:00:00 2001 From: Joseph Hunkeler Date: Wed, 8 Jul 2015 20:46:52 -0400 Subject: Initial commit --- doc/iraf92.tex | 625 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 625 insertions(+) create mode 100644 doc/iraf92.tex (limited to 'doc/iraf92.tex') diff --git a/doc/iraf92.tex b/doc/iraf92.tex new file mode 100644 index 00000000..46558215 --- /dev/null +++ b/doc/iraf92.tex @@ -0,0 +1,625 @@ +\documentstyle[11pt,paspconf,epsf]{article} +\parskip=4pt + +\begin{document} + +\title{IRAF in the Nineties} + +\author{Doug Tody\altaffilmark{1}} +\affil{National Optical Astronomy Observatories, Tucson, AZ 85726} + +\altaffiltext{1}{NOAO is operated by AURA, Inc.\ under contract to the +National Science Foundation.} + +\begin{abstract} +The IRAF system (Image Reduction and Analysis Facility) has been under +development since 1981 and in use since 1984. Currently, in 1992, IRAF is a +mature system with hundreds of applications which is in wide use within the +astronomical community. After a brief look at the current state of IRAF, +this paper focuses on how the IRAF system is expected to develop during the +coming decade. Certain key new technologies or trends which any new data +analysis system will need to deal with to be viable in the nineties and +beyond are discussed. An overview of the planned enhancements to the IRAF +system software is presented, including work in the areas of image data +structures, database facilities, networking and distributed applications, +display interfaces, and user interfaces. +\end{abstract} + +\keywords {IRAF, image processing, data analysis, graphics, visualization, +software environments} + +\section {Introduction} + +The IRAF data reduction and analysis system has been around since 1981. +Today IRAF is a mature system with hundreds of applications which is supported +on all major platforms. Many institutions, projects, and individuals around +the U.S. and the world have developed software for IRAF. Some of these +packages are comparable in size to the IRAF core system itself. + +At the present time there are half a dozen large groups developing software +for IRAF, plus many individuals or small groups. Coordination of the work +being done by the large groups is the responsibility of the IRAF TWG +(Technical Working Group), an interagency group which oversees IRAF software +development. Scientific review of IRAF development is provided by an IRAF +User's Committee, which oversees IRAF as a whole and which reports to NOAO, +by additional User's Committees reporting on the various projects developing +large layered packages for IRAF, and by the staff and management of the +institutions funding IRAF development. IRAF is used primarily by the ground +based astronomy (NSF) and NASA space astrophysics communities. + +A list of the IRAF layered packages currently installed at NOAO/Tucson is +shown in Figure 1, to illustrate the variety of packages available. This +list is not all-inclusive, i.e., there are additional layered packages +available for IRAF other than those shown here, which were the ones which +happened to be installed at NOAO when this figure was prepared. The +standard IRAF distribution itself, consisting of the core IRAF and NOAO +package trees, contains about 50 additional packages, or several hundred +tasks, totaling approximately 1.3 million source lines. The core IRAF +system includes the IRAF system software (host system interface, run time +and programming environments, command language and other user interfaces, +and core applications) and is required to compile and run any layered +software. + +\small +\begin{tabbing} +\hspace{0.3in}\=\hspace{1.5in}\=\kill +\> adccdrom \> tools for accessing ADC CD-ROM\\ +\> ccaccq \> IRAF CCD data acquisition\\ +\> color \> prototype RGB rendering tasks\\ +\> ctio \> CTIO local tasks\\ +\> demos \> IRAF demos\\ +\> ftools \> FITS tools package\\ +\> grasp \> GONG data processing (helioseismology)\\ +\> ice \> IRAF CCD data acquisition\\ +\> iue \> tools for importing IUE spectral data into IRAF\\ +\> mem0 \> maximum entropy image restoration\\ +\> nlocal \> NOAO/Tucson local tasks\\ +\> nso \> Solar astronomy\\ +\> spptools \> SPP programming utilities\\ +\> steward \> Steward observatory local tasks\\ +\> stsdas \> STScI (HST) data processing\\ +\> tables \> STScI table tools package\\ +\> vol \> volume rendering\\ +\> xray \> SAO x-ray data analysis package\\ +\\ +\normalsize +\> {Figure 1.} IRAF layered packages installed at NOAO (Dec. 1992)\\ +\end{tabbing} +\normalsize +\vskip -12pt + +As of late 1992 the current release of IRAF, which is still in distribution, +is version 2.10. As of December 1992 there were a total of 1068 logged +distributions of the previous version of IRAF, V2.9, of which 196 +distributions were tape distributions mailed to the user at cost, and 872 +distributions were downloaded via anonymous ftp from the IRAF network +archive on iraf.noao.edu. An unknown number of additional distributions +were downloaded via DECNET network transfer (we don't know how many, as we +log only ftp file transfers). These statistics count only distributions +leaving NOAO; since the system is freely available, we have no way of +recording redistribution of the system at remote sites or within large +institutions. IRAF site support traffic totals over 5000 email messages or +phone calls per year, counting both incoming and outgoing messages. Based +on the number of distributions and the site support traffic we estimate +there are currently several thousand active users of IRAF. + +The remainder of this paper focuses on where IRAF is headed over the +remainder of this decade. We look first at some key new technologies that +we feel IRAF (or any modern astronomical data analysis system) must use +effectively to be competitive by the end of the decade. Some pitfalls that +we feel system developers would be wise to consider are also discussed. +Finally, we summarize the work planned for the next few years to enhance the +IRAF system software to meet these new challenges. + +\section {Key new technologies for the next decade} + +IRAF is a long term project. Most of the software or hardware technologies +upon which IRAF is based typically have a lifetime of only 5 or 10 years - +considerably less than the expected lifetime of the IRAF software. To +remain up to date it is necessary to make use of new technology, but one +must do so carefully to avoid tying the software irrevocably to a technology +which will one day become obsolete. It is not easy to change a large system +once a direction has been chosen, so one must take the long term view, +always planning 5 to 10 years in the future, trying to visualize what future +computer systems will be like and what we want our software to look like on +those systems. + +\subsection {Key new technologies} + +The following are some key new technologies and technological issues or +trends which we feel any modern data analysis system should be concerned +with. + +\vspace {-5pt} +\subsubsection {User interfaces} + +As computer systems become more powerful, software systems are becoming +larger and more complex. People do a lot more with computers now than they +did a few years ago. Functionality and efficiency, while still important, +are no longer the overriding concerns they once were. The issues of +managing complexity, and ease of use, are increasingly important concerns. +The challenge of user interface design is to make complex systems +comprehensible, intuitive, and easier to learn and use. Sophisticated user +interfaces will make our software more pleasant to use, and allow more +complex and sophisticated applications to be written. The days are past +when the user interface can be taken for granted when designing new +software. + +\subsubsection {High level languages} + +Our common everyday computers are becoming so powerful that most of the +compute cycles now go to waste. At the level of compiled code, our computer +languages and software systems are becoming increasingly complex, to the +point where it may take an expert with years of training to deal with them. +It may be that the time is rapidly passing when casual users will do very +much programming with general purpose compiled languages like Fortran, C, +C++, and so on. The trend is towards higher level interpreted languages +which are tailored for a particular type of application. Whether these +languages are syntax driven, visual, or whatever does not really matter; in +general the optimum type of language depends upon how the language will be +used, and languages should be customized for a particular application. In +the future, users will still develop custom applications, but they will +increasingly do so using sophisticated, high level, application specific +custom languages which are embedded in feature-rich data processing +environments. + +\subsubsection {Networking and distributed objects and data} + +Our computers are getting powerful enough that for many applications, +further gains in compute power won't make a whole lot of difference. A +powerful computer and sophisticated software aren't worth much unless one +has data or other raw information of some type to process, analyze, or +query. Fortunately a new way has been found to expand the capability of a +computer system: the growth of global networks is opening up a whole new +dimension on what we can do with computers. It is already the case that one +can do wondrous things with even the simplest hand held computer - so long +as it is connected to the global networks. The networks give us access to +an inconceivable amount of data or information of various types. Not only +do the networks provide access to vast amounts of raw information, they make +it possible to export arbitrary {\it services} via the network. Rather than +export data or software, one can now export services which remote clients +can access at runtime to do any number of interesting things. We are only +just starting to learn how to make use of the global networks, but it is +already clear that the networks will change forever how we do computing, and +how we use computers. + +\subsubsection {Object oriented software structure and methodology} + +Every few years something new comes along (e.g., AI, CASE, HyperCard, etc.) +which proponents claim will revolutionize how we do computing. Most of +these ``silver bullets'', useful though they may be in some applications, +are oversold and after a time something else gets all the press. The latest +such hot item is object oriented programming (OOP). The journals are full +of talk about object oriented languages, databases, programming tools, and +so on. This time it is not just another overhyped product though. The +object oriented approach to software development and software design is +probably the most important development in software engineering since +structured programming in the 80's. In fact it is a natural outgrowth of +the best software practices of the 80's. + +What is important about object orientation is not a particular language, +commercial product, or other tool, but the concepts and methodology +underlying the object oriented approach to software development and systems +design. In particular, the object oriented approach places a special +emphasis on the {\it conceptual modeling} of the objects (classes) +comprising a software system. This emphasis on conceptual modeling, and the +encapsulation or information hiding that is a natural part of the object +oriented approach, are fundamentally important in dealing with the +complexity of large modern software systems. Other elements of the object +oriented approach such as subclassing and inheritance are probably +fundamental to a true object oriented software structure, but this is a +fairly specific software structure, and not necessarily the best one for all +applications. Like any technology, OOP will be better for some things than +for others, and we are still learning the limitations of this new technology +and where it can be used most effectively. + +\subsubsection {Database technology} + +There is nothing very new about database technology. To date though, +astronomy has done little with database technology, beyond its obvious use +for indexing data archives. We think that there is much that could be done +by combining, e.g., database technology with a graphical user interface to +perform sophisticated queries of the catalogs produced by astronomical +analysis programs such as are produced by image classification, source +detection, and stellar or galaxy photometry programs. Furthermore our data +sets are becoming larger and increasingly more complex, as is the way we +access data, especially when we take network access to remote databases into +account. Database technology will eventually have to be brought into play +to effectively manage this increased complexity. Conventional relational +database technology will continue to be important for large data archives +and for some types of catalogs produced by analysis programs, but object +oriented database techniques will be better suited to the complex data +objects dealt with by our online analysis systems. + +\subsection {Concerns} + +In the process of employing all this new technology there are a number of +things to watch out for. + +\subsubsection {The coming OS wars} + +UNIX is king right now, but will this be the case ten years from now? Ten +years ago the dominant system in astronomy was the VAX running VMS. Today +it is the UNIX workstation. UNIX is a very good system and it (or more +properly its descendents) might still be the dominant system ten years from +now, but this is by no means certain. There is a very real possibility that +the dominant system for astronomers ten years from now could be the PC. Not +the PC we have now, but the PC we will have then, when a PC is more powerful +than the workstation of today, cheaper, portable, fully connected to the +networks, and capable of running ``shrink wrapped'' personal applications in +addition to specialized astronomical software. The engineering workstations +and servers of today will still be around, and they will be more powerful +than ever, but an increasing share of scientific computing is likely to be +done on mass market PC systems. + +If the PC does so well then we cannot be certain that UNIX will still be the +predominant operating system ten years from now. We might instead be using +an operating system which was designed for the mass market, such as +Windows/NT, or conceivably even some future version of MacOS (most likely a +mixture of all these). UNIX may be more powerful, more elegant, more +technically superior, and less proprietary, but those criteria will not +necessarily prove as compelling to the mass markets as they have to the +academic and engineering markets. Even within the UNIX community there is +still considerable variation in what we call UNIX, and despite efforts like +POSIX there is no real evidence that this situation will ever change. On +the contrary, UNIX systems are becoming increasingly complex and small +differences are correspondingly magnified. + +\subsubsection {Window systems} + +In the past the main concern when porting software to a new platform was the +operating system. Operating system differences are still a concern, but not +as big a concern as in times past. A possibly more significant problem, and +one which is perhaps being overlooked by many folks now writing software, is +the window system, or in the case of X, the window system toolkit. Modern +window systems are comparable in complexity to operating systems but the +technology is much newer, and is still evolving rapidly. It is likely that +any window system specific software written today will have to be thrown out +and rewritten a few years from now. Most window system specific software +today would have to be largely rewritten to ``port'' the application to a +different window system on a different platform. Despite these problems, +most window system applications written today are monolithic applications +with the application specific functions and user interface code tightly +interwoven. Window systems may prove to be the ``assembly language'' of the +90's. + +\subsubsection {Computer languages} + +In the past ten years the major players in the general computer languages +arena have changed, but the game has not. We have seen Fortran 77, K\&R C, +ANSI C, Fortran 90, and lately C++, with others such as Ada, Pascal, and +Objective C on the sidelines. Computer languages are constantly evolving. +Even given language standards, implementations of a language by vendors on +different hardware vary considerably. This is unlikely to ever change. + +The evolution of computer languages is not a problem so long as one is +content to write disposable software. If the projected lifetime of a body +of software is ten years or longer, and the body of software is large enough +that rewriting it may not be practical, the evolution of languages is a +serious problem which may eventually cause the software to become obsolete, +along with the technology it has been tied to. Even in the short run, the +variation in language implementations on different platforms can be a +serious support headache if the body of code is sufficiently large. + +\section {Major IRAF system software enhancements} + +In this section we describe the work being done to enhance the IRAF system +software. This is a long term effort extending over a period of years. +Some of the work discussed has already been completed, but much of it is +either in progress or still to be done. + +The work presented here attempts to exploit the new technologies discussed +in the last section, while avoiding the pitfalls that can come from tying +software too closely to a particular technology. Existing technology is +only useful up to a point; much of the work discussed in this section is an +outgrowth of the work already done on the IRAF system, and reflects problems +some of which appear to be unique (at some level) to astronomical data +analysis. + +The reader is assumed to already have some familiarity with the current IRAF +system software. The software described here is very extensive and it is +impossible in a short review article like this to go into very much detail, +or explain all the terminology used. + +\subsection {Image Structures} + +The term ``image structures'' refers to the representation of the primary +data type in IRAF, the {\it image}. In IRAF an image is not a simple +picture, but an arbitrarily complex data object. An image consists of an +N-dimensional logical data raster (sampled data array) plus various bits of +associated information, some of which may be quite complex objects in their +own right. The logical data raster need not be physically stored as a +sampled data array, for example in the case of event data the data is stored +as an event list and sampled only when the image is accessed. The +information often associated with a data raster includes history +information, any attributes computed by analysis of the image data, world +coordinate systems, pixel or region masks, uncertainty or "noise" +information, and so on. + +A common example of an image is a raw data image, i.e., an astronomical +observation. Examples of raw data images are a 1D spectrum, a 2D CCD data +frame, or a 3D Fabry-Perot or radio spectral image cube. Images of +dimension higher than 3 are rare in astronomy. Typical astronomical data +sets can be quite large, e.g. several gigabytes, perhaps consisting of +thousands of small spectra, or several hundred large 2D images. Individual +images of 32 megabytes or larger are occasionally seen. + +\small +\begin{tabbing} +\hspace{0.3in}\=\hspace{0.3in}\=\hspace{0.3in}\=\hspace{2in}\=\kill +\>{\bf high level image class}\\ + \>\>{\tt IMIO} \>\>image i/o\\ +\\ +\>{\bf image header access}\\ + \>\>{\tt IMIO} \>\>header access\\ + \>\>\>{\tt DFIO} \>datafile manager (*)\\ + \>\>\>{\tt FMIO} \>file manager\\ +\\ +\>{\bf image kernels} (internal to IMIO)\\ + \>\>{\tt IKI} \>\>image kernel interface\\ + \>\>\>{\tt OIF} \>old (original) image format\\ + \>\>\>{\tt STF} \>HST image format\\ + \>\>\>{\tt PLF} \>pixel list image format\\ + \>\>\>{\tt QPF} \>QPOE (event list) image format\\ + \>\>\>{\tt FTF} \>FITS image format\\ + \>\>\>new format \>new DFIO based image format (*)\\ + \>\>\>others \>HDS(?), ``PC'' image formats (*)\\ +\\ +\>{\bf auxiliary classes}\\ + \>\>{\tt MWCS} \>\>world coordinate systems\\ + \>\>{\tt PMIO, PLIO, MIO} \>\>pixel masks or lists\\ + \>\>{\tt QPOE} \>\>event list data files\\ + \>\>{\tt NFIO} \>\>noise function package (*)\\ +\\ +\> \normalsize {Figure 2.} New Image Structures\\ +\end{tabbing} +\normalsize +\vskip -12pt + +When IRAF was first released some years ago the only image format consisted +of a pair of files per image, one for the header and one for the pixel +matrix, with the header file consisting of a fixed binary structure plus a +variable number of FITS cards (not a terribly flexible or efficient +structure). Over time several alternative image formats have been added, as +well as support for some of the auxiliary data objects associated with +images. It has become increasingly difficult to store all this information +in the simple data structures provided by the older IRAF image formats. The +purpose of the new image structures project is to provide a general, well +integrated hierarchy of image object classes for flexibly and efficiently +representing a wide variety of image data. + +The major components of the new image structures are summarized in Figure +2. The new image structures project is further along than most of the other +new software discussed in this paper; everything listed has been implemented +except for the items marked with an asterisk. This is a {\it big} project; +some of the subsystems listed here, e.g., MWCS, QPOE etc., are major +projects in their own right, and in total the new image structures code +will likely exceed 100K lines, not counting the lower level IRAF classes +or other library code. + +A key feature of the implementation of the image interface in IRAF is the +{\it image kernel}. An image kernel is the only part of IRAF that knows +anything about how an image is stored externally, i.e., the physical image +format. The image kernel implements a mapping between the physical image +format and the logical view of an image implemented in the runtime image +descriptor used to access an active image object. The image kernel can +provide a standard interface to a wide variety of image types, including odd +things like photon event lists, image masks, or image display server frame +buffers, in addition to various standard image raster disk file formats. In +principle IRAF can be integrated with any external image processing system +by implementing an IKI image kernel for the image format defined by the +external system. The best example of this is FITS. The FITS image kernel +also allows archival data, e.g. on CD-ROM or on a remote network server, to +be directly accessed by IRAF programs. + +The main work remaining to be done to finish the new image structures +project is to implement a new standard IRAF online image format based on the +general datafile manager (DFIO, discussed in the next section). This will +replace the existing OIF image format. The new format will make it possible +to simply and efficiently group complex objects such as world coordinate +systems, pixel masks, and compressed pixel uncertainty arrays with pixel +arrays to form the objects we call images. + +\subsection {Database facilities} + +Managing complex data structures such as the image structures in a flexible +and efficient manner, while providing features such as data independence, +machine independence, a data recovery capability, transparent storage of +arbitrarily large data elements, capabilities for storing complex objects +(not just simple tables), indexing for efficient lookup, and a good +integration with the higher level IRAF software, is a complex and demanding +problem. The low level interface planned to provide this capability for +IRAF is DFIO, the data file manager. DFIO is layered upon FMIO, the file +manager, which is in turn layered upon IRAF binary file i/o (FIO). DFIO is +a medium level interface designed for embedded applications, e.g. it will +be used internally within IMIO to store image data. For the most part IRAF +applications will not use DFIO directly, rather they will deal with data at +a higher level, e.g. via the image class. + +One of the types of data DFIO will be capable of storing is the table, as in +a relational database. Hence, in addition to its use as an embedded +interface within IRAF system software to store complex data objects, DFIO +will provide a traditional relational database capability for applications +such as catalog access. Since IRAF already provides a builtin networking +capability, DFIO will automatically be usable in client-server applications +to provide a distributed database facility. To be able to access external, +non-IRAF databases, a database server architecture will be used (similar to +the use of image kernels by IMIO). + +\subsection {Networking and distributed applications} + +Networking is an integral part of IRAF and IRAF has always been able to +support distributed applications. In IRAF all access to external resources +is via the IRAF kernel. The IRAF kernel has a builtin remote procedure call +facility allowing kernel procedures to execute either locally or remotely. +(This includes {\it all} kernel procedures that access a named external +resource, be it a file, directory, tape drive, image display, process, or +whatever). In a local reference the procedure is executed directly; when +the resource being accessed resides on a remote node a custom RPC protocol +layered upon the IRAF networking driver is used to remotely execute the +kernel procedure. The only system dependent part of all this is the +networking driver, which can use any standard message or stream oriented +transport layer, e.g. TCP/IP, DECNET, and so on. Since the IRAF kernel +provides a standard host interface, the routing or leaf nodes in a +distributed IRAF process tree can execute on host machines running any +operating system to which IRAF has been ported. It is even possible to +transparently route RPC calls between different networks, e.g. the Internet +and SPAN. + +There are still some significant enhancements planned for the IRAF +networking system but these are for the most part comparatively minor +evolutionary enhancements. One of the most interesting enhancements being +considered is some sort of interface to non-IRAF servers, e.g. ftp or WAIS +servers. This would not provide the full capability of the IRAF kernel, but +might work for simple directory and file access, and would allow any IRAF +application to transparently access arbitrary servers on the network whether +or not they provide an IRAF kernel server. + +\subsection {User Interfaces} + +In general, the IRAF system circa 1992 is very strong in terms of the +functionality provided, but is weak in the area of user interfaces. This +directly reflects the priorities for IRAF development in the late 1980's, +which emphasized getting numbers out of the data. This meant new +applications, and due to the common environment, enhanced system support for +these applications (e.g. the new image structures). In the early 1990's, +with a wealth of software now in the system and more people than ever using +IRAF, the emphasis has shifted towards ease of use and improved user +interaction and data display. + +Enhancements to the IRAF user interfaces are planned in many areas. Two of +the most exciting are a general GUI (graphics user interface) capability, +available to any IRAF application and capable of making full use of the +advanced capabilities of modern window systems, and less obviously, something +called minilanguage support. + +Modern window systems are remarkably complex software systems, and the field +is still evolving rapidly, with many quite different window systems and +window system toolkits being developed or in use. Using window user +interfaces effectively in scientific applications is challenging, as if one +is not careful and the wrong approach is taken, programmers may spend all +their time struggling with complex window system software and not get any +science software written. Due to the complexity of the field, learning a +particular toolkit or user interface builder is time consuming and a +considerable investment in time is required to make use of any particular +tool. A wrong decision could result in a great deal of wasted time, +particularly for a large project where many people may be developing +software. + +%\small +%\begin{verbatim} +% IRAF application <---- (file defining user interface) +% | | +% GIO | +% | | +% Interpreter <====== IPC =======> Interpreter +% | +% Object Manager +% | +% Window System Toolkit +% +% (Client Application) (Widget Server) +%\end{verbatim} +%\normalsize +% +%\hspace{0.3in}{Figure 3.} Widget Server Architecture +%\vspace{12pt} + +\begin{figure} +\epsfxsize=5.0in \epsfbox{iraf92f3.eps} +\hspace{0.3in}{Figure 3.} Widget Server Architecture +\end{figure} + +After considerable time spent studying window systems and graphics user +interfaces we think we have found a solution to this problem. It is called +the {\it widget server}. In the widget server architecture the application +and the user interface are in two separate processes. The application is a +type of minilanguage with a simple parsed command line interface. The user +interface resides in the widget server process. When an application starts +up it downloads a text file to the widget server containing the user +interface to be executed. This defines all the widgets forming the user +interface as well as the code to be executed (interpreted) while the user +interface executes. During execution, the user interface (widget server) +and client application exchange commands and data via interprocess +communication. + +This architecture has many advantages, e.g., a complete separation of the +user interface and functional code, and a high level interpreted interface +to the window system for the programmer, making it easy to develop GUIs (and +easy for the user to customize the user interface). Since only the widget +server knows about a particular window system or toolkit, the widget server +also provides window system and toolkit independence, allowing a new window +system or toolkit to be supported merely by implementing a new version of the +widget server. The widget set provided by the widget server will include +the standard toolkit text, button, scollbar, list, geometry, etc. widgets, +plus some custom widgets (such as graphics and image display widgets) +tailored to IRAF applications. + +As powerful as the graphics user interface can be, it is not the only way to +do a user interface, nor is it necessarily the best type of user interface +for all interactive applications. A quite different type of applications +user interface which is at least as powerful, and also well suited to +complex applications, is the context-based minilanguage. A minilanguage is +a single program (IRAF task) with a syntax driven, command line user +interface. The program maintains an internal state and successive input +statements modify this state. The syntax, command or function set, and +internal data structures are customized for each application. The +individual functions are usually simple, but arbitrarily complex operations +can be performed by stringing together sequences of commands or +expressions. By designing an appropriate syntax very powerful +applications-specific languages can be devised. + +A good language will be extensible, allowing users to define new procedures, +link to external compiled routines, or interface external IRAF or host tasks +so that they appear as functions in the minilanguage. It will even be +possible to combine a graphics user interface with a minilanguage. For +example, the combination of the widget server with a minilanguage will +provide both a fully featured GUI capability and a powerful interpreted +computing engine, both programmable by the user without need to resort to +low level compiled languages. When all this is layered upon the IRAF +environment, providing well integrated access to powerful facilities such as +the IRAF image structures and a wealth of existing external tasks, the +result will be high level applications of unprecedented power, flexibility, +and sophistication. + +\vspace{12pt} +\acknowledgments + +Without the contributions of many people over the years, the IRAF system we +have now would not exist. The author particularly wishes to thank Frank +Valdes and Lindsey Davis of the NOAO IRAF group, who wrote much of the IRAF +software. STScI and SAO have made major contributions to the system over +the years and the IRAF project would not be the same without their +involvement. A grant from the NASA astrophysics data program has made all +the difference as IRAF use continued to grow while the NOAO budget continued +to shrink. Finally, we wish to thank the NOAO directors and scientific +staff for their continuing support and enthusiastic use of IRAF, and for +their help in making IRAF a better system. + +\begin{references} +\reference Tody, D., 1986, ``The IRAF Data Reduction and Analysis System'', +in {\it Instrumentation in Astronomy VI}, David L. Crawford, Editor. + +\reference +Hanisch, R. J. 1991, +``STSDAS: The Space Telescope Science Data Analysis System'', +in {\it Data Analysis in Astronomy IV} (Di Ges\`{u}, V., +Scarsi, L., Buccheri, R., Crane, P., Maccarrone, M.C., and Zimmermann, H.U., +eds., Plenum Press, New York), 97. + +\reference +Worrall, D.M., Conroy, M., DePonte, J., Harnden, F.R., Mandel, E., +Murray, S.S, Trinchieri, G. , VanHilst, M. , Wilkes, B.J., 1992, +``PROS: Data Analysis for ROSAT'' +in {\it Data Analysis in Astronomy IV}, eds.~V. Di Gesu {\it et al.}, +Plenum Press, 145. + +\reference Olson, E. C. and Christian, C. A., 1992, +``The EUVE Guest Observer Analysis Software.'' +in {\it Astronomical Data Analysis Software and Systems I}. + +\reference See also the many technical papers describing the IRAF software, +available in {\tt iraf.noao.edu:iraf/docs}. + +\end{references} +\end{document} -- cgit