Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.modula2
Subject: Re: C v.s. Modula II
Message-ID: <12992@mimsy.UUCP>
Date: 13 Aug 88 19:30:39 GMT
References: <79500004@p.cs.uiuc.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 110

In article <79500004@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>... had grown used to a Modula-II like language (MESA).

Mesa is considerably more useful for writing Real Programs than is
Modula-II, if only because its I/O really is standard (or at least
only has to deal with one O/S!).  So this is more of a Mesa-vs-C:

>Some of the things that really bothered me about C were:
>
>1.  It's a one-pass-compiler language.  So you must pollute your
>code with multiple declarations if you make forward procedure calls.

As a matter of taste, I happen to like a requirement for forward
declarations that must match the later definitions.  (I have an intense
*dis*like for Pascal's forward, which requires omitting parameters in
the actual definition.)  Forward declarations help me, as a reader,
know what types are attached to functions and arguments.

(Of course, this is less important with better programming
environments, where I can put the definition up in another window at
the touch of a few keys.  On the other hand, I am now at home, typing
away on my H19, and there is no other window....)

>2.  Local changes can require non-local code restructuring.

Not if you format well :-) .

>Adding an else-clause can require you to restructure the {}'s.

Nope:

	if (a)
		foo;
	/* add else here */
	if (b) ...


	if (a)
		foo;
	else {
		stuff;
		more stuff;
	}
	if (b) ...


>Often, for(;;) loops are written with *no body*, and adding additional
>commands can require major restructuring of the loop.

I do not understand this either.

>3.  Include files are hard to keep track of, nest, and structure in a
>big project.  Modules & Interfaces seem to work much better.

Any automated scheme (Mesa's is semi-automated) tends to work better
than any manual scheme.  Some people have developed automated schemes
for C, although since it is not handed down from on high, it can be
hard to get people to use your favourite.

>4.  I really miss the way MESA treats records as first class types.

This really is a serious problem in C.  It is, however, partly fixed
in the dpANS, where automatic aggregates may be initialised.  There are
still no generic aggregate constructors, nor is there any really decent
way to deal with unions (the first-member rule is not useless but does
not do anywhere near enough).

>5.  I miss MESA INLINE procedures.  They are simpler and (often) more
>efficient than C's macro expansions.  

Actually, they are not always simpler.  What are the semantics of the
static variable below?:

	inline int unique_integer() { static int next; return (next++); }

The intended semantics are obvious, but providing exactly those semantics
is not trivial, since all users of the inline function, regardless of
source file, must use the same `next', which must be different from the
`next' of any other inline function.

(GCC, incidentally, does this right, when it does it at all.  The gcc
we compiled a month or two ago on a Sun broke when asked to deal with
inline functions, although the code it tried to generate would have been
right---if that makes any sense to you.)

>6.  C has no provision for callback procedures (you need nested
>procedures and the right semantics for the 'display').  So data
>abstraction is hindered in C.

You need neither, and I personally believe that those sorts of nested
variables (if not the procedures themselves) are a misfeature---they
add a fair bit of expense to the calling sequence (gotta maintain them
displays or static links) and account for very few actual variable
accesses.  Better to use (semi-)hidden pointer parameters a la C++,
which also effectively gives you closures.

Someone else complained about a lack of `var' parameters.  Again, I
think this is a very *good* thing.  One of the worst problems with
reading Pascal code is that every procedure and function call might
potentially alter every variable argument.  If I see a section of C
code that reads

	munch(a, b, &c, d, e + 7);

I can assume that it cannot change a, b, and d (unless they are arrays,
arrh), while the same statement in Pascal, stripped of its warning
`&', tells me no such thing.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris