rmarti@sun.uucp (Bob Marti) (11/04/85)
In response to Bjarne Stroustrup's message <4500@alice.UUCP>:
Let me make a few final remarks in this ongoing discussion about the relative
merits of C++ versus Modula-2.
(1) You still don't seem to have gotten my point that I was comparing Modula-2
to C rather than C++. I do get your point, though, namely that you think
C++ is way better than Modula-2. Let's hope you are right! Maybe you
could write a paper entitled "Why Modula-2 is not my favorite programming
language" :-)
(2) If you try a little harder, you might even find definitions for the terms
data abstraction etc. which only fit C++ and no other language :-)
Moreover, in contrast to your opinion, it *is* possible to declare
variables of an opaque type which are only accessible using a specific
set of procedures declared in the same module. The fact that, in the
current implementations of Modula-2, variables of an opaque type are
typically restricted to a size of 1 or 2 words which forces you to use
a POINTER TO RECORD ... representation is just that: An implementation
restriction. As far as "notational conveniences" are concerned, you are
of course right again, but as you say, they are just conveniences ...
(3) As far as the date of appearance of Modula-2 is concerned, I was absolutely
baffled to find that your quote from Wirth's book checked out. All I can
say is that I was at ETH at the time, that I do have the Modula-2 report
quoted in my last message, and that its publishing date is December 1978.
Why Niklaus Wirth is stating that the language's definition was published
in March 1980 is completely beyond me. I do admit that I was wrong about
the public availability of the compilers.dan@pokey.UUCP (11/06/85)
> The fact that, in the > current implementations of Modula-2, variables of an opaque type are > typically restricted to a size of 1 or 2 words which forces you to use > a POINTER TO RECORD ... representation is just that: An implementation > restriction. > Much as I like Modula-2, I can't agree with this statement. The reason such a type is restricted is because, given the current syntax and semantics of the language, the compiler has no way to obtain size information about an opaque object. Such objects are named in the definition module, but declared in the implementation module. A program importing them may only read the definition module (of course), where no information is available. By making the internal definition of an opaque object a part of the implementation, Wirth has made its size unavailable, by definition, to any other code. See by contrast Ada private types, whose details must be declared, but may not be used by any but the owning package, or C++ class variables, which behave in a similar way.
bs@alice.UucP (Bjarne Stroustrup) (11/07/85)
>From: rmarti@sun.uucp (Bob Marti) >Newsgroups: net.lang >Subject: Re: C++ and Modula-2 (and something about data abstraction) > Message-ID: <2958@sun.uucp> > > In response to Bjarne Stroustrup's message <4500@alice.UUCP>: > >Let me make a few final remarks in this ongoing discussion about the relative >merits of C++ versus Modula-2. There is, of course, no such thing as a really final remark. >(1) You still don't seem to have gotten my point that I was comparing Modula-2 > to C rather than C++. You jumped on my C++ note to pick on C, so I jumped on yours to pick on Modula-2. > I do get your point, though, namely that you think > C++ is way better than Modula-2. Let's hope you are right! Maybe you > could write a paper entitled "Why Modula-2 is not my favorite programming > language" :-) I could be a nice paper. Maybe in a year's time someone will produce a good C++ vs Modula-2 paper based on experience with both. I shouldn't be the one to write that one, though. >(2) If you try a little harder, you might even find definitions for the terms > data abstraction etc. which only fit C++ and no other language :-) I am of the opinion that terms such as "data abstraction" is often defined in such a way that it is far too easy to claim that a language supports it. In particular, you often see definitions so that "data hiding", "data abstraction", and "object-oriented programming" becomes near synonymous. This, I believe, is often the effect of overenthusiasm on behalf of some language (there is a certain perverse logic at work here: "DA is good" and "Language X is good" therefore "language X supports DA"). It is also quite hard to avoid defining "data abstraction" in terms of facilities in a specific language. Niklaus Wirth, for example, comes very close to defining "data abstraction" as "opaque export" (his book, 2nd edition, page 82). This very nearly makes "Modula-2 supports data abstraction" a tautology. > Moreover, in contrast to your opinion, it *is* possible to declare > variables of an opaque type which are only accessible using a specific > set of procedures declared in the same module. You can do that, and handle a very limited set of cases (your note below), but there is a serious snag here. Variables of an opaque type can be copied freely (you don't have to define a copy operation in the module, assignment works by default - correct me if I'm wrong, my Modula-2 compiler has become uninstalled again). This implies, that what you have got is a facility for defining pointers and for defining types for which bitwise copying is ok. The former is of little additional value (given modularity/data-hiding), and it strongly resembles C's rule that you can have variables of type "struct X *" even where the definition of "struct X" is not available. In other words, if data abstraction in Modula-2 is use of opaque types that are really pointers (as recommended by Wirth), C too supports data abstraction, and in nearly exactly the same way. I find that a hard to swallow. If not, the case for Modula-2 supporting data abstraction rests on the ability to opaquely export types that (1) are not pointers, and (2) can be freely copied. C's ``data abstraction facilities'' would be strictly equivalent to Modula-2's had it not been for pointer arithmetic. > The fact that, in the current implementations of Modula-2, variables of > an opaque type are typically restricted to a size of 1 or 2 words which > forces you to use a POINTER TO RECORD ... representation is just that: > An implementation restriction. It is a very hard restriction to lift without causing other problems, though, and as long as it is enforced I don't think one can claim that Modula-2 supports data abstraction (at least not without making the same claim for C, and then the meaning of "data abstraction" has been eroded so far as to be meaningless). Both possess a rudimentary facility that makes a limited form of data abstraction just barely possible. > As far as "notational conveniences" are concerned, you are > of course right again, but as you say, they are just conveniences ... One of the hardest things to do is to live without conveniences you have gotten used too. >(3) As far as the date of appearance of Modula-2 is concerned, I was absolutely > baffled to find that your quote from Wirth's book checked out. All I can > say is that I was at ETH at the time, that I do have the Modula-2 report > quoted in my last message, and that its publishing date is December 1978. > Why Niklaus Wirth is stating that the language's definition was published > in March 1980 is completely beyond me. I do admit that I was wrong about > the public availability of the compilers. Maybe he'll fix the publication date in the next edition. - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill) PS In case someone missed the main points in the details of the discussion: C++ supports data abstraction and object-oriented programming. C++ is available (commercially and educationally).
rmarti@sun.uucp (Bob Marti) (11/09/85)
>> The fact that, in the >> current implementations of Modula-2, variables of an opaque type are >> typically restricted to a size of 1 or 2 words which forces you to use >> a POINTER TO RECORD ... representation is just that: An implementation >> restriction. > Much as I like Modula-2, I can't agree with this statement. The reason > such a type is restricted is because, given the current syntax and semantics > of the language, the compiler has no way to obtain size information about > an opaque object. Such objects are named in the definition module, but > declared in the implementation module. A program importing them may only > read the definition module (of course), where no information is available. This is true if you assume that the compiler allocates storage (and assigns addresses) for variables of an imported opaque type when compiling an implementation module. I guess that this is the way all current Modula-2 (and other) compilers work. (I only know the Lilith M2M 4-pass compiler reasonably well.) Although I have not worked out the idea in all details, I believe that the size information has to be available at link-time, but not necessarily at compile-time. In other words, the compiler could leave hooks in the code instructing the linker to allocate variables of the appropriate size and assign addresses to them. Of course, this requires writing a special linker which handles this case. It also means that linking will be more expensive. Since most Modula-2 implementations have a special linker which checks for compatible versions of the modules to be linked, such a scheme would not really make matters worse. And since Niklaus Wirth's new 1-pass Modula-2 compiler compiles itself in less than 2 minutes on the Lilith (a Lilith has about the computing power of a VAX-11/750), I would expect that even with this "expensive" linking scheme the total time to compile and link still compares favorably to most compilers out on the market (especially to all Ada compilers :-). PS: As far as I know, the new 1-pass compiler is not publicly available (yet).