Non-strict, purely-functional languages, such as Haskell [1], are perceived to be inadequate for everyday, get-the-job-done tasks; in particular, they are seen to be "bad at I/O". Consequently, an informal working group has been designing an extended variant of Haskell to address these requirements, while remaining within a non-strict, purely-functional framework. Can anyone give me an example---or a reference to an example---which shows that functional languages are "bad at I/O"? And why is Haskell perceived to be inadequate for "get-the-job-done" tasks? Since Lennart added the "Native" mode to hbc and since hbc provides access to many UNIX features (see page 4 of the latest user guide), I have been able to do anything I want (so far). In addition, I have written functions that check the command line arguments and route the input/output accordingly; I just pop these functions into a library and another IO task is made easy. However, I admit that the programs I write have simple I/O: read a "signal" (in the signal-processing sense) from a file, read some data structures from another file, crank the handle, produce output. David M. Goblirsch ([EMAIL PROTECTED]) The MITRE Corporation, McLean VA 22102 voice: (703) 883-5450 fax: (703) 883-6708
