🚀 go-pugleaf

I have been looking at Modula-2, but have been somewhat put-off
by the hodgepodge of I/O functions.  Is this just a problem with
my version (Logitech Version 3), or is it pervasive in all
versions?

Consider the following module hierarchy Logitech supplies:

                              RealIO
                                |
     CardinalIO     LongIO    InOut
         |             |       |  |
         +-------------+-------+  |
         |                        |
     Terminal                 FileSystem          LogiFile
         |
     Termbase
        |  |
        |  +------+
        |         |
     Keyboard  Display   SimpleTerm

Now consider functionality:

SimpleTerm allows reading/writing of strings or characters.  No
other modules use it.

Keyboard and Display are just a character interface.  Termbase
allows redirecting Terminal.

Terminal adds reading/writing of strings, and fakes the command
line into looking like terminal input (is this really a
feature??).

By using CardinalIO and LongIO, one can use Terminal for
Cardinals and Long Integers, but there is no module(s) for
Integers and Reals.

FileSystem (and Logifile, which apparently only Logitech
utilities use) provide basic (unbuffered?) file system support. 
Files are objects that can be read or written in a crude form.

InOut provides character, cardinal, integer, and string
input/output to the terminal, with redirection to a files (but
not using the Termbase mechanism).  Only one file can be accessed
at a time.

RealIO provides real number IO in scientific notation.

Ok, so what does that give us?

1    If you want to access more than one file at a time, you have
     to use FileSystem.  But then only "Binary" access is allowed
     -- no ASCII conversion.

2    Long Integer I/O is only supported for the terminal.

3    A program that only uses the terminal is "forced" to import
     InOut (and therefore all the FileSystem module) if it wants
     to do Integer or Real I/O.  And real output is forced to
     scientific notation (fixed point not supported).

4    The Termbase module adds unnecessary overhead.

5    Not only is there no buffering on file IO, there is also no
     buffering on terminal IO.  The latter makes it impossible to
     edit the current line, but just the last value typed in.

Can anyone defend this?  Are other implementations better? 
Worse?  To add to this mess, I bought a book/disk, "Modula-2
Software Components".  Besides providing some useful data
structure modules, they decided to provide a new, improved
terminal module (still unbuffered, and no support of reals, but
writes directly to display memory) and *two* FileSystem-like file
interfaces, one for binary files and one for ASCII files
(strings, integers, cardinals and reals).  This gives me four
implementations of open-read-write-close and three terminal
interfaces, plus I ended up writing my own modules for buffered
terminal I/O.  But why should I have to do such basic programming
in a presumably mature environment?  And why so many incompatible
file system interface modules?

Tom Almy
toma@tekgvs.TEK.COM
Standard Disclaimers Apply