From: dmg@org.mitre.oceanus (David M Goblirsch)

(Up to Haskerl index.)
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.)


Will Partain, partain@dcs.gla.ac.uk; 1998-03-07.