Version 1.9 Build 000

Latest News FAQ Search Home

Glish Development Plan

Master URL: http://aips2.nrao.edu/aips++/docs/project/glishdev.html

Contents

• Introduction
• Logical Development
• Development Phases
• Active Development

Throughout this document, indicates an item that has been completed.

The AIPS++ project is primarily concerned with the language aspects of Glish because while some communications level changes will be required, e.g. persistent clients, the weakest link in Glish from the AIPS++ perspective is the expressiveness and the user friendliness of the language. This is a direct result of Glish's lineage. It was constructed as a simple scripting language for control system work. While the language is loosely based on S, it has not been used enough as a programming language to round out some of the language rough spots. This is where most of the AIPS++ changes have been and will continue to be made.

This document attempts to organize the future direction of Glish development within AIPS++ in two ways. First, the logical development section lays out the of tasks which are planned for Glish. In this section, logically related changes are grouped together. This provides a view of where AIPS++ plans to take Glish. However, while this presents the entire development in a way most accessible for readers, it does not present the development in a way convenient for management planning. This is because for planning one is interested in only in task ordering and dependence. This is laid out in the second planning section. That section lists the project mile-stones in which Glish will participate along with the Glish functionality required at that point. This will hopefully provide a simple way for people to look at what is being done to Glish and when it is targeted to be done. This will also provide the tie-in to other development plans.

Required Changes

A longer history buffer is required because currently it is very short (last 20 commands). It would also be worth while to look at how the search capability works in order to try to make it nicer and easy to use. It currently has problems with lines which are longer than a single line. This is a lesser concern, however. In addition to an internal history, it is important to have the ability to log commands to a history log file. This will allow users to view and re-execute portions of a previous session. The ability to keep a history log is essential.

Having a facility for function name completion will be very important because much of the way novice users will interact from the CLI with AIPS++ supplied Glish clients will be through function wrappers. As a result, some way of doing function/variable name completion will probably make users' lives much more bearable.

Currently in Glish there is no way to escape to the user's shell. At times, it is important to be able to get to the shell to do some simple operations before returning to Glish with all of its previous state. In addition, ^Z does not currently work as a result on command line editing. For a user friendly environment, one or both of these capabilities should be added.

Arrays which are printed in Glish print all of the elements of the array regardless of the array length. This can be a major problem (as any user who has accidentally printed an array and then waited for minutes while the whole array was dumped to the screen can attest). Some mechanism must be added to Glish to allow for specifying limits for dumping arrays to the screen.

Currently typing ^C cause Glish to exit. It would be nice if instead of simply exiting Glish would return to the toplevel command interface, i.e. stop function evaluation, file inclusion, etc. A second ^C would then cause Glish to exit.

Probably the most important change which will affect the robustness of Glish is the creation of a Glish test suite. Having a test suite will allow Glish to be checked after changes and after ports to new architectures. As such, a test suite would be useful to both users and Glish developers. This is very important and has been neglected for too long.

Possible (Non-)Features

There are reasons to consider adding sexagesimal notation to Glish. The primary reason for adding it to Glish is that its use would be much more natural if it was actually a part of Glish rather than being handled by a function or preprocessor. The reason not to added it to Glish is the fact that it is very specific to astronomy. It could be #ifdefed or perhaps there is a general way to add new notations to Glish. In any event, this possibility should be considered.

Another user suggestion is to change function usage so that the name of the function results in the value for functions with no parameters, e.g.

    func offset() { ... }
    newval := 23 * offset / 30;

Some users have requested vi editing syntax in addition to Emacs editing commands. This is probably a good idea. However, it should be done in a way which is not confusing to users, e.g. not mixing to two command sets.

One other possible (and interesting) thing which could be added to Glish and which may be useful for users is a system for specifying units within Glish. This would allow the users to specify unit relationships and set the units for Glish values. Glish would then verify the unit compatibility as the values were used. While this may be useful, it is probably difficult to get right and it may not be well used; however, it should be kept in mind and is listed here in that spirit.

Programmability

The feature most lacking in Glish with respect to programmability is some module or package system which will allow programmers to segment portions of the name space. This is important because currently it is very easy for users to redefine system functions or variables. This situation is exacerbated by the fact that all variables and functions within Glish share the same name space. It is important that this extension be developed sooner rather than later because packages should be used as AIPS++ subsystems are constructed instead of some ad hoc name mangling scheme.

In addition, some form of const-ness is also probably required. This may be required for packages, individual values, or both. However, since many constants are likely to be required, e.g. PI, it is likely that one would like to be able to assign const-ness at the individual value level.

Another glaring problem is the lack of a way to specify an include path for including Glish script files. This is a problem because it requires that either Glish must be run from the same directory relative to the included files or else the full path must be given. This makes Glish script fragile and difficult to share. Another related feature which was requested was the ability to specify load files on the command line, via e.g. a "-l" flag, before the interactive session was started.

Currently it is very difficult to debug Glish scripts. Scripts are simply included and Glish's error messages give no indication where the error occurred. The long term solution to this problem is to develop a symbolic debugger for Glish. This is a difficult proposition, but if Glish is to be successful as a programming language in the long term, a debugger will be required. Another possibility is to have a mechanism which will force Glish to echo each executed line. While this sort of echo is really a short term solution, it may continue to be of some use even after a debugger is developed. Another way to improve debugability is to at least provide a stack dump when an error is encountered.

Variables which are used in Glish functions are global by default and to make them local they must be explicitly declared as local. This should be changed so that variables are local by default. This is a basic principle of scoping which Glish should be changed to follow. Having the default scope be the most local scope available will reduce programmer error and highlight those places where a function is using global variables.

Object oriented programming is a very useful way to encapsulate reusable pieces of a system. While Glish shouldn't be turned into an object oriented system, capabilities should be added which facilitate object oriented programming. AIPS++ programmers will develop object oriented applications in C++, and to some degree, they should be able to carry this skill over to programming the CLI. While Glish values could be used as the basis for objects in Glish given the existence of attributes, the granularity values is probably too small a granularity. Packages, once implemented, should form a more appropriate granularity for object oriented development than values. Care must be exercised in adding object oriented features as a result of the interactive nature of Glish. Trying to mirror a compiled language, like C++, in Glish would be a mistake; Perl 5.0 provides a better example of the direction object oriented capabilities should go. In this same vein, one of the nice features of object oriented languages is the notion of destructors. These functions allow an object to clean up all of the loose ends before exiting. It may also be useful to have a global shut-down function. This hook would allow global resources to be cleaned up before Glish exits. This shut down function would be useful in addition to object destructors. The issues involved with object oriented programming should be borne in mind while packages are designed and implemented.

A minor but useful change is this addition of an installation wide .glishrc file. This allows a particular site to add some customization for a particular site. This is most useful for setting the include path for Glish scripts installed at a given site.

In the long term view, function and event typing should be considered for Glish. Typing helps identify bugs at parse-time rather than during execution. Typing would be useful for functions, whenever statements, and within the Client class. Typing in its simplest form would simply allow the user to specify, for example, that a function (or event) is expected to be numeric. While much more complicated typing schemes are possible, typing in Glish should be kept as simple as possible given Glish's interactive nature.

The final tool which could be very useful for programmers is an eval command . This would allow the Glish interpreter to evaluate strings as input to the Gish interpreter. Other languages have this, e.g. Lisp, Perl, etc., and this will probably be important for some AIPS++ applications

Client Interaction

The primary short coming with respect to clients in Glish is the lack of persistent clients. It is very important for the AIPS++ effort to have the ability to have long-lived clients which users (via Glish) can connect to and disconnect from at will. The details of how this should work have not yet been worked out, but the need for such a capability is evident. Another similar thing which might be important in the future is interconnected Glishes. It may be important to have one Glish bus running controlling data collection at a telescope, for example, and another Glish bus controlling the near-realtime analysis. In the ideal case, these would be two separate Glishes, but they would interact to allow the data to be received in the analysis bus as it becomes available on the collection bus. There are two different aspects to the latter scenario. The first is the act of attaching to a persistent client, e.g. the analysis Glish attaching to the collection Glish, and the second is the case of having an unexpected client join a pre-existing Glish, e.g. the collection Glish having a new client (the analysis Glish) attempt to attach. Both of these capabilities are probably important.

The final aspect of Glish client interaction which is important but is currently missing from Glish is the ability to specify a time out for expected events. This capability would allow for a time out on request and await statements. This would allow a Glish system to recover from the AWOL event. Currently the whole system freezes in a catatonic state.

Efficiency and Security

Finally, there are a couple of efficiency concerns. The first is gratuitous promotion to double. Many functions, for the sake of simplicity, promote floats to doubles. This promotion could be both deceiving and expensive, essentially doubling array size.

The second efficiency concern is related to the confusing semantics of const/ref. It is desirable to replace the current const/ref scheme, which was created mainly for efficient passing of parameters, with a copy on write mechanism which would maintain a references to the underlying data, and only do the copy when a write is done to the data. This will not only provide a more coherent semantics, but it will probably also be more efficient.

There are currently two related (known) security problems in Gish (glishd in particular). The first relates to authentication. glishd does not attempt to authenticate users and hosts with which it communicates. To prevent this, glishd needs to attempt to authenticate the hosts and users who connect to it. Any scheme will likely require keys for users and hosts.

The second related problem is one of glishd ownership. Currently only one glishd daemon is created per host, this daemon controls remote Glish clients on that host. The problem is that even if user and host are authenticated these valid users are still connecting to a daemon which may have been created previously by another user. As a result, clients which are created and commands which are executed run under the uid of the person who originally started the glishd. These glishd security problem must be fixed before Glish is used publicly.

• First incarnation of packages
• Include path handling

• Include path handling
• Persistent Clients

Important

• Event Timeout
• Shut Down Functions
• "Eval" like capability
• Glish Daemon Ownership
• Glish Daemon Authentication

Desired

• Package System
• Scope Defaults to Most Local
• Limited Array Dumping to the Screen

• Packages
• Function Completion
• Shell Escape
• History Log
• Const Values/Packages
• Debugability Improvements
• "Eval" like capability
• Event Timeout
• Glish Daemon Ownership
• Glish Daemon Authentication
• Scope Defaults to Most Local
• Limited Array Dumping to the Screen
• Persistent Clients
• Include path handling
• Installation wide .glishrc

• Packages
• Function Completion
• Shell Escape
• History Log
• Const Values/Packages
• Debugability Improvements
• "Eval" like capability
• Event Timeout
• Glish Daemon Ownership
• Glish Daemon Authentication
• Limited Array Dumping to the Screen
• Include path handling
• Persistent Clients
• Installation wide .glishrc

• Finding tools for developing a Glish test suite
• Update user manual with recent changes
• Work on design for modules
• Misc. Bugs:
  • Fix command line parameters to clients (pshannon@nrao.edu)

Copyright © 1995,1999,2000 Associated Universities Inc., Washington, D.C.