Discussion:
Why are the ISO I/O libraries optional?
(too old to reply)
Nemo
2014-07-07 18:05:51 UTC
Permalink
ISO/IEC 10514-1 does not mandate any of the I/O modules. All 22 are
optional -- compilers need not implement them. Has anyone any clue as
to the rationale for this?

By making them optional, software developed with one compiler and its
libraries need not be portable to any other compiler with different
libraries yet both can be ISO-conformant.

N.
Martin Brown
2014-07-07 19:01:22 UTC
Permalink
Post by Nemo
ISO/IEC 10514-1 does not mandate any of the I/O modules. All 22 are
optional -- compilers need not implement them. Has anyone any clue as
to the rationale for this?
By making them optional, software developed with one compiler and its
libraries need not be portable to any other compiler with different
libraries yet both can be ISO-conformant.
N.
Perhaps they wanted to maintain the status quo?
Every old M2 compiler has its annoying lock in features.

XDS made an effort to handle the most common old dialects PIM2 & JPI/TS.

ISO Modula 2 came too late to do any good. Most practitioners had
already abandoned it by the stage that the standard was finalised.

It is a shame, but history is littered with technically excellent
solutions that were wiped out by inferior ones with better marketing.

Sony Betamax vs VHS being one far enough back to look at objectively.
OS/2 vs Windows was an even bigger one which we still have to live with.

M2 was an elegant minimalist language and deserved to have done better
in the marketplace outside of niche safety critical roles and teaching.

In the 1980's Logitechs PMD and RTD tools were way ahead of their time
on a PC even if the compilers code generator was a bit pedestrian.
--
Regards,
Martin Brown
Marco van de Voort
2014-07-08 07:14:24 UTC
Permalink
Post by Nemo
ISO/IEC 10514-1 does not mandate any of the I/O modules. All 22 are
optional -- compilers need not implement them. Has anyone any clue as
to the rationale for this?
Modula2 is an system language. In the embedded space and even the kernel
mode, there is not always a concept as std i/o.
Martin Brown
2014-07-08 08:26:09 UTC
Permalink
Post by Marco van de Voort
Post by Nemo
ISO/IEC 10514-1 does not mandate any of the I/O modules. All 22 are
optional -- compilers need not implement them. Has anyone any clue as
to the rationale for this?
Modula2 is an system language. In the embedded space and even the kernel
mode, there is not always a concept as std i/o.
I disagree. Originally any respectable computer had a system console
terminal somewhere probably attached to an RS232 port. Any worthwhile
language should provide some basic IO library support guaranteed to be
consistent in all compiler implementations. One thing FORTRAN got right!

The clumsy syntactic sugar of the original PIM Modula 2 InOut library
may well have contributed to its low adoption rate.

It makes more sense to me with the input routines as adopted by JPI.

ch := ReadChar();

ISO disagreed so it is still

ReadChar(ch);

Modula's requirement for strict type safety precluded interpretted
format string typical of FORTRANs FORMAT statement or C's printf(). It
was ahead of it's time, but at the time it didn't seem like that in the
real world. PASCALs Write & WriteLn were more flexible in practice.

If you are doing embedded bare metal code then you know that standard IO
is a non-starter but most people are developing applications!
--
Regards,
Martin Brown
Marco van de Voort
2014-07-08 11:21:44 UTC
Permalink
Post by Martin Brown
Post by Marco van de Voort
Modula2 is an system language. In the embedded space and even the kernel
mode, there is not always a concept as std i/o.
I disagree. Originally any respectable computer had a system console
terminal somewhere probably attached to an RS232 port.
Who said anything about a computer? And note that I didn't say anything
about a device having a stdin and stdout, but I said something about the
concept that every process has a stdin and out.
Post by Martin Brown
Any worthwhile language should provide some basic IO library support
guaranteed to be consistent in all compiler implementations. One thing
FORTRAN got right!
In a standard with multiple levels where some levels are for minimalistic
system, there is general a preference for a certain level expressed in the
standard.
Post by Martin Brown
It makes more sense to me with the input routines as adopted by JPI.
(I never used any other M2 than JPI for more than evaluation, so I don't
know better than module IO)
Post by Martin Brown
ch := ReadChar();
ISO disagreed so it is still
ReadChar(ch);
Specially for strings IMHO there should be procedural versions though, they
are simply more efficient. And it frees up the return value for indications
of error.
Post by Martin Brown
Modula's requirement for strict type safety precluded interpretted
format string typical of FORTRANs FORMAT statement or C's printf(). It
was ahead of it's time, but at the time it didn't seem like that in the
real world. PASCALs Write & WriteLn were more flexible in practice.
Yes. Actually just before writing this, I used the streamio hack to redirect
pascal filehandles to streams, so that I could use writeln.
Post by Martin Brown
If you are doing embedded bare metal code then you know that standard IO
is a non-starter but most people are developing applications!
MOST people, not ALL people.
trijezdci
2015-08-21 10:56:28 UTC
Permalink
Post by Martin Brown
Modula's requirement for strict type safety precluded interpretted
format string typical of FORTRANs FORMAT statement or C's printf().
Not necessarily.

The trouble with format strings is generally that their designers all too often do not differentiate between formatting and typing. Separate the two and you can have type safe format strings.

That is to say, format strings can be save as long as the format string does not determine which type the output data shall be. IOW, the format string only determines formatting, not what type the data is in.
Post by Martin Brown
It was ahead of it's time, but at the time it didn't seem like that in the
real world. PASCALs Write & WriteLn were more flexible in practice.
The plethora of different IO procedures with different names depending on the type they are for is in fact very bad design in terms of readability of source code. It's absolutely horrible.

At the time it was perceived that you can either have nice IO syntax like Pascal or you can have library defined IO, but not both. In Pascal there are polymorphic Read and Write procedures but they only accept built-in types and the IO system is built into the language, not library defined.

Unfortunately Wirth did not realise that he had already invented and used a technique in Modula-2 that would have let him have his cake and eat it too, that is unified READ and WRITE with library defined IO.

The technique in question can be found in NEW and DISPOSE. These are built-in identifiers, but their implementation comes from a library called Storage. NEW maps to Storage.ALLOCATE, DISPOSE maps to Storage.DEALLOCATE. The technique is therefore called a Wirthian Macro.

This could have been used for IO by defining built-in identifiers READ and WRITE and map them to respective library implementations, one IO library per type.

Given the variables ...

VAR n : CARDINAL; i : INTEGER; r : REAL;

... the compiler would then map ...

WRITE(n) => CARDINALIO.write(n)
WRITE(i) => INTEGERIO.write(i)
WRITE(r) => REALIO.write(r)

etc.

This would also extend to library defined types, not just built-in types.

As for formatted IO, a third identifier WRITEF could be provided.

WRITEF( channel, "format string", list of variables to be output );

The variables to be output would all need to be of the same type.

Unfortunately, to provide library implementations, variadic parameter lists are required.

This is another feature that was once thought to be impossible to implement in a type safe manner. Nothing could be further from the truth however ...

PROCEDURE writef ( f : FILE; fmt : ARRAY OF CHAR; list : ARGLIST OF <Type> );

In fact, such polymorphic READ, WRITE and WRITEF procedures and type safe variadic parameters are both an integral part of Modula-2 R10.

User convenience and implementation flexibility and efficiency.

So, yes, you can have your cake and eat it too.

Loading...