From: (Bryan O'Sullivan)
To:, blandy
Subject: My research proposal
Date: Tue, 21 Sep 93 19:33:04 +0200


Bryan O'Sullivan
Lazy Research Group
Computer Science Department
J. Random University


With recent advances in the state of the art in the fields of Artificial Intelligence and Functional Programming, opportunities have arisen for innovative projects in the area of Guilt-Driven Compilation, or as it is also known, Lazy (but Functional) Compilation. Building on our other successful research work in the areas of Partial Completion and Incomplete Specification, the Lazy Research Group has obtained funding for a new research effort exploring Guilt-Driven Compilation.


General guilt-driven computation has a long, but largely unacknowledged, history in Computer Science. It is largely responsible for such familiar working practices as: More recently, companies such as Sun Microsystems have explored the guilt-driven area. Sun's foray in this direction was heralded by the release, in June of 1993, of a patch for a well-known security hole in SunOS `ex3.7preserve' which had been documented for *four* *years*. The accompanying press release mentioned that ``well, we hadn't quite gotten round to it up to now''. Sun CEO Scott McNealy was reported in the press as saying ``we felt pretty bad that we sat on our asses for four years, so we thought we'd best plug the hole'', Sun's first public admission that they, too, were doing guilt-related work.


The Lazy Research Group intends to bring guilt-driven techniques in Computer Science into the twenty first century by focussing in particular on the area of guilt-driven computation.

We have begun the design of a special guilt-driven compiler. This will have several guilt-related features:

  1. A special calling convention: "late evaluation". When a procedure is entered, no parameters are pushed onto the stack; rather, the parameters are evaluated after the first few were due to be used. An apologetic message stub (known as a Grovel) is automatically called when a parameter has not yet been evaluated; it explains that "evaluation took longer than was expected, and if you'll wait just a little while, we'll push those values you've been waiting for".
  2. Static analysis techniques will be used by the compiler to allow it to determine which statements it can get away with not compiling. At the moment, the compiler generates object code after parsing 75% of each procedure; a second compilation produces a new executable which contains the other 25% that should really have been in the first executable (this technique has been pioneered by software engineers at Microsoft).
  3. The compiler will automatically keep track of the load during the previous few weeks on the machine on which it runs. If the host has been busy for a long time, the compiler sits idle, in the hope that the user will not notice that it isn't doing anything (and thereby saving on computation). Once either the load goes above a certain critical value or (in a batch system) the compiler's expert system indicates that it might miss its deadline, the compiler is spurred into action.
  4. Human psychology shall be taken into account by the compiler's expert system; it will adapt over time to the degree of lateness and dysfunction which the user is willing to tolerate, and while the compiler will not perform steps 1 through 3 any differently, it will adopt a suitably guilty tone in the messages printed by the Grovel stubs.


It is hoped that the steps outlined in 1 through 4 above will enable compilers to accurately simulate the behaviour of software engineers, thereby increasing the ability of observant and competent engineers to estimate the amount of time that compilations will take.

The Lazy Research Group is loking for sort of motivated researchers. Please apply to the address at the beginning of this announcement; the deadline is September 25th, and we definitely won't take applications after October 15th.