From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=BAYES_20,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!luth!sunic!mcsun!ukc!inmos!mph@lion.inmos.co.uk From: mph@lion.inmos.co.uk (Mike Harrison) Newsgroups: comp.lang.ada Subject: Re: TEXT_IO anomality Message-ID: <9558@ganymede.inmos.co.uk> Date: 13 Aug 90 09:32:52 GMT References: <9007241309.AA00417@ajpo.sei.cmu.edu> <2020@cod.NOSC.MIL> <26496@pasteur.Berkeley.EDU> <2040@cod.NOSC.MIL> Sender: news@inmos.co.uk Reply-To: mph@inmos.co.uk (Mike Harrison) Organization: INMOS Limited, Bristol, UK. List-Id: In article <2040@cod.NOSC.MIL> sampson@cod.nosc.mil.UUCP (Charles H. Sampson) writes: > ... > >| Furthermore, I think that changing the behavior of TEXT_IO to take >| account of interactions between input and output on a terminal would be a very >| bad idea. It would mean, one presumes, that the runtime system would have >| to maintain implicit links between files that read and write from >| terminals; that every write to a terminal would involve first checking >| for input from the terminal (so as to get the correct final values for >| LINE and COL); and a few other implications I have undoubtably missed. > > An implementation that looks promising and easy is to have the file >control block (or whatever the implementation calls it) point to a block >that contains the three numbers and any other data that might be affected >by the interplay between the two files. An action on either would then be >immediately available for the other. Of course, asynchronous access to >either file would cause problems, but asynchronous access to the terminal >is already known to be something that must be handled carefully. > I hit the same problem about 3 years ago (in a previous job), the solution we adopted was to define a new i/o package called TERMINAL_IO, whose syntax was a suitable subset of TEXT_IO, but whose semantics implemented the sort of interactions between input and output that you want at a terminal. Unfortunately, the package was implemented by a colleague, so I can't give any details of the internals or any special problems he had to solve. The result was *exactly* what I wanted and avoided compromising the behaviour of our normal TEXT_IO. The TERMINAL_IO package was included in the delivered Ada product. Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS;