TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
Pascal Obry <[log in to unmask]>
Date:
Sun, 31 Oct 1999 15:49:21 -0800
Reply-To:
Mark Lundquist <[log in to unmask]>
Subject:
From:
Mark Lundquist <[log in to unmask]>
In-Reply-To:
Message from Pascal Obry <[log in to unmask]> of "Sat, 30 Oct 1999 10:13:21 +0200." <[log in to unmask]>
Content-Type:
text/plain; charset=us-ascii
Parts/Attachments:
text/plain (57 lines)
From:  Pascal Obry <[log in to unmask]>

> The more degrees of freedom allowed by the language definition, the
> easier it is to port implementations of the language system.  For
> example, for an 18-bit target architecture you would most likely
> implement an Ada Standard.Integer as an 18-bit wide type.  But you'd
> have to implement 32-bit arithmetic on this machine to implement a Java
> int.
> >>
>
> Ok, so I'am completly confused now. I agree with that but your
> first message seems to imply that Ada compilers are portable
> but not the Ada applications.

Hmm... I didn't mean to imply anything so broad.  Anyway, the underlying
theme here is the range of subtleties of the concept of "portability"...

> Maybe this paragraphe was
> about Java instead of Ada as noted, or is that a language
> problem (I'am french :-) ?

Or it could be a language problem in that my writing style is too
abstruse :-)

Let me try again...

The more that the language specifies rather than leaving implementation
dependent, the more its "portability model" (to use Ben's term) begins
to suggest a guarantee of identical behavior across implementations
(e.g. vendors, target architectures, target OSes, etc.).  But the
tradeoff is going to involve performance penalties and even the
rendering of some architectures impractical or unsuitable for the
language.

So... my point was that the design of Ada is biased toward
platform-targetability of the language in preference over guarantees of
identical behavour, and that this was a good choice.  Since it's futile
to try to guarantee identical behavior anyway, and you would have to
sacrifice performance to even try, the language should not be
overspecified.  Instead it should be designed so that it can produce
reasonably efficient executable code on a wide range of target
platforms and specify what guarantees the implementations should make.

But I'm really more interested in the practical aspects... how do we
convince as many people as possible that Ada is the right language for
high-integrity systems work?


--

Mark Lundquist
Senior Software Engineer
Rational Software
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA

ATOM RSS1 RSS2