E.Ireland@massey.ac.nz (Evan Ireland) (10/06/90)
Hi, In my message of 26 September, I asked for information about non-trivial, non-academic, applications of functional languages, and indicated that I might summarise the responses. Thanks to all those who replied. One of the people who replied (Duco Fijma) wasn't sure what I meant by "non-academic", and as a result I suggested an alternative question: > "Did the use of a functional language in application `X' result from a > desire to find applications for functional languages, or did it result > from the functional language being considered appropriate to solve the > problem at hand." A recurring theme in the responses I received was the use of functional languages for prototyping. Other responses indicated a variety of applications, and I have included (edited) versions of all the responses below, since nobody told me they weren't interested! Again, thanks to everyone who replied. I have included the email addresses of respondents so that you may contact them for more information. ------------------------------------------------------------------------------ From: Jack Campin (jack@cs.glasgow.ac.uk) One major database system (Oracle, I think) uses a functional language (Buneman and Nikhil's FQL) in its query engine. The user never gets to see this. ------------------------------------------------------------------------------ From: Graham Birtwistle (graham@cpsc.ucalgary.ca) ... we have written a version of the higher order logic (HOl) theorem prover in SML in essentially variable free mode. a few assignments are used here and there (system flags). ... ------------------------------------------------------------------------------ From: Tom Thomson (tom@nw.stl.stc.co.uk) Over the period 1985 to 1988 we made heavy use of functional language in our parallel systems group at ICL. We worked in Hope+, with the addition of a guardian mechanism used to connect Hope+ modules together. This was a very simple-minded guardian mechanism, implemented at the bottom as a simple non-deterministic merge. We implemented a simple operating system kernel, and a prototype relational database (enough to run the Transaction Processing Council's TPCA benchmark after a fashion). We also implemented a few demonstrator applications. The Hope+ compiler was written in Hope (not Hope+). The development route used a dialect of VDM, which was translated into Hope+ by machine; the dialect of VDM used was effectively functional, as non-functional features would have been difficult to translate. We made heavy use of lazy evaluation (this was difficult, because we couldn't get our academic collaborators to agree to a fully lazy version of Hope+ and we had ended up with a version in which all constructors were lazy while all other functions were eager to weak head normal form); one of the things we found we needed to do was add annotations to the language to express completely lazy evaluation, evaluation of an argument to spine-normal form, evaluation to canonical normal form. We don't work in Hope+ any more (at least only for the odd small prototype and for once-off programs we want to scribble quickly to get some quick result), because we found that the long-run problems outweighed the short-run advantages. We are still working on building a development route which will handle the top level input in purely functional form though. ------------------------------------------------------------------------------ From: Steve Perryman (S.K.Perryman@stl.stc.co.uk) I developed a prototype distributed systems architecture allowing a LISP/CLOS environment to communicate with and use a C/Objective-C equivalent architecture on a remote host (and vice versa). The prototype will be used for studying a distributed applications environment (in CLOS/C/C++) ultimately required for a state of the art multimedia workstation (ESPRIT project MULTIWORKS). The LISP/CLOS code was in the order of 10000-12000 lines. With respect to your qualms on IO and referential transparency... - I had to use foreign functions to implement INET IPC functionality. - I did NOT USE setq anywhere. - I did NOT USE defvar anywhere. - There were side-effects on the objects themselves, but this is unavoidable as state has to be maintained. - I wrote as much NON-SEQUENTIAL code as was possible, as I tried to avoid coding a LISP equivalent of the C (imperative) code. ------------------------------------------------------------------------------ From: Richard Wolski (rwolski@lll-crg.llnl.gov) At a SISAL (Streams and Iteration in a Single Assignment Language) workshop I attended last June, Dr. Greg Egan from the Swinburne Institute of Technology mentioned that they were developing a weather predicting code in SISAL. My recollection is that it was actually in production, but I can't say for sure. ... ------------------------------------------------------------------------------ From: Greg Egan (gke@stan.xx.swin.oz.au) We have a spectral barotropic model coded in Sisal and are currently looking at grid models with the Australian Met Bureau. ... we are also working on other real applications including siesmic modelling (discrete element) with CSIRO Geomechanics, Manipulator control, signal processing (off line filters), etc. ------------------------------------------------------------------------------ From: Duco Fijma (fijma@cs.utwente.nl) I read your request for information about "non-trivial" and "non-academic" applications of functional programming languages on Usenet. I am a member of the functional programming research group of the University of Twente in the Netherlands (this little country in Europe). It's not clear to me what you mean by "non-academic". Do you regard the use of functional programming for prototyping serious software projects an academic business? We have had a PhD thesis about this. Real implementation of software in FPL's is not done at a very high scale, especially not in commercial business. One of the few exeptions is the compiler for the FPL "LML", it is written mostly in LML itself. I think that if functional languages are used, they are used for prototyping, and not as a final implementation language. ... ------------------------------------------------------------------------------ From: Stef Joosten (joosten@cs.utwente.nl) I got your cry for applications. Yes, we are doing quite a lot of serious application work in real, lazy, uncompromised functional programming. We find it very suitable for programming work in the early stages of software development, such as prototyping, making executable specifications of certain (not all) problems, and in general for all programming work in which human cost is more important than computer cost. (This appears to be about everything we do in a university...) ... Two years ago I have finished my PhD thesis on precisely what you are interested in: trying to apply real functional programming for real world applications. We have done lots of real work, and some of it was interesting enough to appear in the thesis. One job was a simulation study in a major hospital in the region I live in. Another was the development of a formal specification of a pretty complicated graphics problem. After the thesis, I have carried on with this type of work, because it is great fun. At the moment I have made a start with the formal design of a client/server protocol of a database system. The system involved is exploited by a small German software house, so we're doing work that is to be used `out there'. Together with these germans, we have done work in the area of public transport modelling, where we tried to make models of the Frankfurt public transport network. ... ------------------------------------------------------------------------------ Evan Ireland (E.Ireland@massey.ac.nz), School of Information Sciences, Massey University, Palmerston North, NZ.