toma@tekgvs.GVS.TEK.COM (Tom Almy) (08/31/88)
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 Applyjbn@glacier.STANFORD.EDU (John B. Nagle) (08/31/88)
With JPI Modula-2, file I/O capabilities are comparable to, say,
older Lattice C systems. All the basics are there.
I/O in Pascal was ill-designed. I/O in Modula I was absent.
I/O in Modula 2 is marginally adequate. Solving the fundamental
conflict between strong typing and I/O remains difficult. The
solution in Ada is in some ways better, but requries the massive
machinery of generics. It may get better in the object-oriented
programming era. Is it better in Oberon?
John Naglebroman@PEANUTS.NOSC.MIL (Vincent Broman) (08/31/88)
I have to agree that the Wirth I/O MODULEs and its Logitech descendents are barely usable. M2's crying need is for a reasonable Std I/O library. The BSI is coming out (sometime before the millenium) with an I/O library standard that looks very well designed. I have online (available for anonymous FTP on bugs.nosc.mil) DEFs and IMPs from an older draft of Stuart Cox, and DEFs only from a newer draft (17 Aug 1987, Version 2.0 of the WG) by Roger Henry. In my opinion, BSI ought to widely publicize the design they have, along with any implementations they can get a hold of, LONG before they have the rest of the details of the language definition formalized. People would gratefully latch on to it, unless too many years of Wirthian tradition accumulate their inertia, for lack of active guidance. Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
BOTCHAIR@UOGUELPH.BITNET (Alex Bewley) (09/01/88)
You read the manual incorrectly. FileSystem does support ASCII i/o with
translation. Ie. <EOF> is character code 32C. <CR><LF> becomes ASCII.EOL.
Read the the FileSystem definition module on page 268 of the version 3 manual.
LongIO uses InOut, so that LONGINTs can be redirected to files or console.
SimpleTerm is for raw fast console ie. It uses DOSCALLS. If anybody has any
questions about the libraries, I have the source code for them (and probably
so does everybody else).
Alexjosef@un21 (09/01/88)
I think part of the confusion comes from the fact, that with
Modula-2 they tried to allow You to enter a library-hierarchy
at different levels of abstraction.
E.g. You should be able to view a file as
1.) a sequence of bytes with no apparent structure (like UNIX (tm) files)
2.) a sequence of characters
3.) a sequence of floating point numbers.
Apart from the fact, that You can enter this hierarchy at different
levels, this has the added advantage that the module implementing
floating point numbers (3) relies only on the module implementing
characters (2) which in turn relies only on the module implementing
bits (1), which in turn is implementation dependent (probably).
I am using Turbo-Modula-2 on my SB180FX and am quite happy with the
different possiblities to in/output data.
But after all: Nobody's perferct, why should Modula-2 :-)
*
** Josef Moellers
* * paper-mail:
***** * c/o Nixdorf Computer AG
* * Abt. EG-3
* * Unterer Frankfurter Weg
* * D-4790 Paderborn
* * telephone:
* * (+49) 5251 104691
***** * e-mail:
* * (USA) uunet!linus!nixbur!nixpbe!mollers.pad
** (!USA) mcvax!unido!nixpbe!mollers.pad
*
PS: Please use e-mail address, josef@un21 is of no use
Standard disclaimer: Blablabla opinion blablabla employer blablabla!toma@tekgvs.gvs.tek.COM (Tom Almy) (09/06/88)
You are right, of course, about longio and text file translation in filesystem. But I still contend that I/O is a hodge-podge mess and could have been implemented in a much more convenient manner. Yes, I have the library sources, too. I can't imagine doing anything without them, as the DEF files are insufficient to figure out what is going on. Tom Almy toma@tekgvs.TEK.COM