From: dmg@org.mitre.oceanus (David M Goblirsch) Subject: a note on the Haskerl extension to Haskell [long] Date: Thu, 1 Apr Date: Thu, 1 Apr 93 07:46:33 EST To: haskell@EDU.YALE.CS 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 (dmgob@mitre.org) The MITRE Corporation, McLean VA 22102 voice: (703) 883-5450 fax: (703) 883-6708(Back to Haskerl index.)