[net.lang.mod2] Extensions to Modula-2

powell@decwrl.UUCP (Mike Powell) (10/24/84)

I agree with Ian Kaplan's comments about language extensions.  I wish Modula-2
were complete enough so I wouldn't want to extend it, but unfortunately it
isn't.  I have tried to make my extensions be in the spirit of Modula-2, such
as I understand it.

His complaint about the case of reserved words is misdirected.  The DECWRL
Modula-2 compiler accepts reserved words and standard identifiers in any case.
Moreover, if you want to use the non-all-upper-case versions of reserved words
as identifiers, you may do so by specifying a compilation switch.  You could
certainly make this the default if you wish.  Since I don't use variables
called begin and end, I don't see why I should have to hold down the shift key
while typing reserved words.  I am careful to make the standard definition
modules so they can be used by both upper casers and lower casers.  It seems
that this is a case where we can have our cake and eat it, too.

I agree with his suggestions for the I/O module.  When I posted its definition,
I did not mean to imply a particular implementation.  In fact, I currently
call Unix printf.  However, other implementations are possible.  Ultimately,
I have plans to make it so that
	writef(output,"s=%s, id=%d, x=%7.4f\n",s,id,x);
translates to
	WriteString(output,"s=",0);
	WriteString(output,s,0);
	WriteString(output,", id=",0);
	WriteInt(output,id,0);
	WriteString(output,", x=",0);
	WriteReal(output,x,7,4);
	WriteLn(output);
and can be implemented by Modula-2 code.  (Glancing back at the above example,
I know which version I'd rather type, but I think Ian and I agree on that).

Similar to the way I handle new and dispose, I would not require an import of
WriteString, WriteInt, etc., if the builtin I/O module is used.  Again, this is
a convenience.  Since you import writef, output, etc., anyhow, it doesn't seem
fair to require importing of identifiers that you don't actually use.

Some people complain about my extensions to the language as being non-portable.
I would point out that all of my extensions are upward compatible.  I can run
any standard Modula-2 program.  For example, implementing Wirth's InOut module
using my I/O module is trivial.  It is incumbent on people who use extensions
but are worried about portability to figure out whether to use them and convert
when necessary or to avoid them altogether.  For example, I have a program that
changes from my case conventions to the standard ones.

					Michael L. Powell
					Digital Equipment Corporation
					Western Research Laboratory
					Los Altos, CA  94022
					{decvax,ucbvax}!decwrl!powell
					powell@decwrl