<p><strong>Program Overview</strong></p> <p>INRAC was a language compiler and natural language processing system created by Tom Etter and William Chamberlain (Olsen 161). It required an IBM PC or compatible with 128K of RAM and was available from INRAC Inc. (Olsen 167).</p> <p>INRAC had a wide applicability, and \"[could] be used to prototype formal natural language interfaces, design conversation systems, and develop experimental forms of computer-generated prose and poetry\" (Olsen 161).</p> <p>Mark Olsen reviewed the INRAC system in 1989 for the journal Computers and the Humanities. His assessment was conflicted - though in his view it \"would prove interesting as a means of testing ideas concerning natural language interfaces in, for example, computer-assisted language education\" (181), he also found it unavoidably idiosyncratic:</p> <p style=\"margin-left: 30px;\">While it has many sophisticated features, such as a built-in conjugation system and supports compilation of lists of related lexical items, INRAC is rather poorly designed and implemented...[i]t might be recommended to individuals who are interested in experimenting with writing interactive systems, but only to those who have considerable amounts of time to kill and a very high frustration threshold. (181)</p> <p>To its credit, INRAC somewhat \"reduces the amount of code required to write natural language interface programs\" (Olsen 162). It also included a sophisticated conjugation system (Olsen 164). It included an editor and debugger, E, that checked for syntax errors and inserted code and variables into the appropriate files (Olsen 162). However, E had a number of bugs that made it preferable for Olsen to make his edits in another program and load the files into E only once he was ready to run them (162).</p> <p>INRAC had a number of notable detrimental characteristics. Its documentation was, in Olsen's opinion, \"simply awful\" (Olsen 164). It could only store a limited number of variables (which themselves stored commands and subroutine calls) (Olsen 163). From the user's perspective, its \"[c]onditional statements and control of program flow are rather cryptic,\" compounded by the developers' choice not to include common programming syntax like loops, and instead use small, self-contained modules (163). As a whole, Olsen found that though \"[i]t would be unreasonable to expect INRAC to emulate the logical programming of PROLOG...the current implementation of logical or associative data structures seems to be very weak (Olsen 164).</p> <p>His final assessment of INRAC as a tool for general use within the humanities was firmly negative:</p> <p style=\"margin-left: 30px;\">Ignoring my dislike for the INRAC language compiler's syntax and design philosophy, which I feel would seriously encumber a reasonably large and complex programming effort, I still cannot recommend INRAC since it is not well finished and documented...[t]his is unfortunate, since INRAC's potential...is very great. As currently implemented, however, INRAC is far too idiosyncratic and too poorly finished to be attractive to large numbers of programmers in the humanities. (Olsen 166-167)</p> <p>Nevertheless, Olsen still felt that \"INRAC is an important development in humanities processing\" (Olsen 181).</p> <p>&nbsp;</p> <p><strong>Source</strong></p> <p><span>Olsen, Mark. \"Software Review: Talking Back: The INRAC Language Compiler.\" <em>Computers and the Humanities</em> 23.2 (1989):161-167. <a href=\"http://www.jstor.org/stable/30200156\">Web</a>.</span></p>