Check-ins Using Download Hex

Artifact 6980efe0453034f3eae855cc8f525d65591a8141882f86776f47545766cb8418:

 4-Jun-82 22:09:33-MDT,0000003647;000000000001
Date:  4 Jun 1982 2209-MDT
From: Chip Maguire
Subject: Files
Sender: MAGUIRE at UTAH-20
To: Griss
cc: Benson, Lowder
Reply-To: Maguire at Utah-20

Eric has provided some excellent material for the documentation. However, I think
that we really have quite a lot more to consider with respect to files,
stream, and filenames. Based on the early morning conversation re files
and the generalization of COMPRESS, etc. to multiple incore files
the following is submitted for comments and reactions. In addition it would
seem that a useful funciton is to allow the user to PutSysFCN(FcnName, SysVec)
i.e. put a new definiton into the IO function vectors; as an explicit
operation. This should make it clear when a function is being assigned to a 
channel and allow the user to replace the functions associated with a channel
in a very obvious manner. I would like to seem the initialization of 
object become an Initialization time activity rather than lost of things
being stuck in vectors before hand.  This should only mean a lot of 
time spend doing these initiallizations the first time a system is buuilt,
if a SaveSytem is done, the things which  have been built in stay builtin
unless they are redefined later (so the execution cost is minimal). This
will hopefully allow the IO-DATA.red file vectors to be idential on all machines
as the binding will take place in a system dependent initialization file.

Notes regarding files in PSL:

1. The model is clearly not simply a stream oriented model as there are
   non-stream based behaviour required.
   a. In a stream model the input and output streams are independent,
      there is no association such as streamM (an output stream) is
      the corresponding output to streamN (an input stream) - however,
      this behavior is being required by the RDTTY code on the 20 and the
      faked RDTTY code on the VAX - this hides the fact that the system
      "knows" about a primary terminal output, which is treated specially.
   b. The functions Flatten-size, explode, compress, etc. - a not being
      treated as what they really are - which is simply incore files
      (i.e. a stream which flows to and from a string) - they should
      get allocated just like other streams with the attendant properties that
      there can be many of them and they need to be opened as incore
      streams.
2. The terminal is NOT being handled as a character oriented device,
   it is being handled as a record oriented device - with the system providing
   record editing prior to the entry of the carriage return. It is unclear
   whether the prompting should be done the way it is on the VAX and the 20
   for the Apollo, as the input buffer expands and contracts based on
   the number of lines entered; in hold mode the input is not send to the
   process until the hold is released, and then it is only sent as the lines
   are read; it does not seem to make sense to prompt on the basis of
   one prompt for each line. While it might seem reasonable to prompt for
   each new READ, i.e. so the user know WHO is reading and the MODE that they
   are reading in, it is currently not possible to know this unless the
   terminial handling function remembers theold string and compares it to
   the current one and checks if they are different.

3. The use of the Promptout!* on the VAX does not eliminate all of these
   problems asit does not correlate the PromptOut!* with the changes between
   the set StdIn .  StdOut and ErrIn . ErrOut (but yet who you are prompting
   is clearly related to the StdIn or ErrOut streams!
-------
REDUCE Historical
[ REDUCE Sourceforge Project | Historical SVN Repository | GitHub Mirror | SourceHut Mirror | NotABug Mirror | Chisel Mirror | Chisel RSS ]