From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!rutgers!bellcore!faline!ulysses!allegra!alice!bs
From: bs@alice.UUCP
Newsgroups: comp.lang.ada
Subject: Re: Ada++ & Objective-Ada
Message-ID: <7587@alice.UUCP>
Date: 3 Jan 88 01:00:44 GMT
References: <871231191213.05i@VLSI.JPL.NASA.GOV>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Summary: take your time and do it right
List-Id: <comp.lang.ada>




 > If pre-processors or translators can be written for C to produce object-
 > oriented languages, then the same ought to be possible for Ada.  Has (is) 
 > anyone done this?  What are the advantages and problems?

It would be possible to extend Ada with an inheritance mechanism either in
the Objective C style or the C++ style.

An objective C style preprocessor would not need to know the Ada type system
and would not provide integration between to ``Objective'' part and the
Ada part. In fact, Brad Cox talked about ``Objective Cobol'' and ``Objective
Ada'' years ago.

The other alternative ``Ada++'' could be much harder work and would involve
extending the Ada syntax and type system to include an inheritance mechanism
in such a way that the benefits of strong typing, data hiding, and associated
environment tools were not compromised. The key problem would be to achieve a
proper ``seamless'' integration between Ada as it stands now and the chosen
inheritance mechanisms. Naturally, the result of this process would have to
look like Ada, not C++, and Ada++ would be an inappropriate name for it
(unless the increment operator ++ was added in the process :-)

I strongly suspect that this work would best be acomplished by extending one
of the better Ada compilers to accept the new constructs. The use of a
translator, that is a compiler front-end that does a complete syntax and
semantic check and uses a C compiler for code generation (only), for C++
as done simply because there (to my knowledge) did not exist a C compiler
with a sufficiently powerful and flexible type system to build on. These days
C++ compilers that do not generate intermediate C exist. I believe that
the translator approach - using C simply as assembly language - was novel at
the time, but these days there exists several language implementations that
takes that route to portability, including (I believe) Common Lisp and Ada
implementations.

 > I can see at least two problems for users.  Debugging of programs produced 
 > by anything other than a compiler means your
 > you're looking at "ugly Ada" rather than the "super Ada" of 
 > Objective-Ada/Ada++.  This was one reason RatFor and company never caught 
 > on widely.

Exactly. Personally, I would never consider using a preprocessor based system
except as a temporary and/or experimental vehicle. Extending a language using
a preprocessor that knows only part of a language is inelegant and a way of
asking for trouble in terms of learning, efficiency, tools, error messages,
debugging, etc.

 > Also, standardization might suffer.  I suspect, however, that the various 
 > super-Adas would be used only in experiments, and that useful features 
 > would eventually find their way into Ada-1993.

Exactly, if you want an Ada with inheritance ready for standardization in 1993
someone must get started quite soon. Designing an inheritance mechanism that
is properly integrated into the Ada type systems and reflecting the changes
into the tools and libraries is going to take years.

	- Bjarne Stroustrup, AT&T Bell Labs, Murray Hill

 >                                                  Larry @ jpl-vlsi