ian@loral.UUCP (Ian Kaplan) (10/20/84)
I have been meaning to write this note for sometime, but I have not
gotten around to it until now. Most of the material below discusses
extensions to Modula. I also briefly outline how I think that multitype
I/O (ala printf) should work in Modula.
* Language Extensions
It appears that no programming language has ever been able to escape
extensions. Ada may be one of the first to have a chance, it already
has almost everything one could imagine in a programming language. The
virtues of an unextended language are obvious: programs written in the
language will be highly protable. The problem is that people have
different problems to solve and it seems that no language can satisify
everone. Herein lie the roots of language extension.
* Is Language Extension Really Evil
There are many versions of FORTRAN, but many people still manage to
write portable FORTRAN programs. They do this by sticking to the core
language and staying away from extensions and programming tricks. With
this in mind I think that if a solid core language exists, extensions
do not necessarily lead to chaos. This is of course not a universal
answer because some common problems may have no portable solution
in the core language.
* Extensions which violate the basic language definition are undesirable.
I like many of DEC's extensions to Modula and I hope that someday their
compiler will become available in the commercial world. What I can not
understand is why DEC made Modula's reserved words lowercase. The
definition for Modula states that case is significant. The definition
also states that ALL reserved words are in upper case. This makes DEC
Modula totally non-standard. I can not understand why this has been
done.
* A Suggestion for a Clean Implementation of Multitype I/O
NEW and DISPOSE are macros which are expanded by the compiler to calls
to ALLOCATE and DEALLOCATE. A multitype I/O routine should work in
the same way. For example:
MODULE AModestProposal;
FROM MyLibrary IMPORT MTWrite; (* Multitype write *)
VAR
AReal : REAL;
ACard : CARDINAL;
AChar : CHAR;
AString : ARRAY[ 0..79 ] OF CHAR;
BEGIN
MTWrite( AReal, ACard, AChar, AString );
END AModestProposal.
MTWrite would be expanded to
WriteReal( AReal, 20 );
WriteCard( ACard, 1 );
Write( AChar );
WriteString( AString );
As in the case of NEW and DISPOSE, the programmer would be required
to import the routines that the expansion produced. One problem with
this proposal is that the standard library, as it is defined to date,
is inadequate for some expansions which might be needed. This is a
problem which should be addressed separately.
Ian Kaplan
Loral Data Flow Group
Loral Instrumentation
ucbvax!sdcsvax!sdcc6!loral!ian
The opinions above are mine and are not necessarily endorsed by the
owners of this computer system.