Looking for PD Ada interpreter

Looking for PD Ada interpreter

[WILLIAMS,BRYAN D.]

I'm looking for a public-domain Ada *interpreter* that will run under
BSD 4.3 or SysV.3 on HP/Apollo workstations (for those in the know,
we're running Domain/OS SR10.3).  Of course I'd prefer something that
is known to be fast and robust, but I fear the real question is
whether ANY such PD software is available.  If anyone out there can
point me to a source, I'd be very grateful.  Please send responses by
e-mail; I'll happily summarize any information I receive.

Re: Looking for PD Ada interpreter

[Dan Vanderwerken]

In article <31357@hydra.gatech.EDU> bw10@prism.gatech.EDU (WILLIAMS,BRYAN D.) writes:
>I'm looking for a public-domain Ada *interpreter* that will run under
[rest of message deleted]

I keep seeing messages like this in this Ada group, and I keep seeing messages
about how _expensive_ Ada compilers, etc. are.  A great many people out there
are asking about PD Ada compilers/interpreters but I've seen no answers.

Do *any* PD Ada compilers/interpreters exist?  Or are all of these people asking
the same FAQ and not getting any answers?

I don't see how any PD Ada compilers could exist.  Ada is a rather large
language and for DoD work must be periodically certified.


-- 
+ Captain Daniel F. Van Der Werken, Jr., USAF |  I do not speak for the Air
+ Rome Laboratory/OCDS                        |  Force, otherwise I'll be
+ Griffiss AFB, NY 13441                      |  in Kansas making big rocks
+ (315) 330-3575/DSN 587-3575                 |  into little rocks!

Re: Looking for PD Ada interpreter

[Michael Feldman]

In article <1991Jun14.183916.867@lonex.radc.af.mil> vanderwerkend@lonexb.radc.af.mil (Dan Vanderwerken) writes:
>In article <31357@hydra.gatech.EDU> bw10@prism.gatech.EDU (WILLIAMS,BRYAN D.) writes:
>>I'm looking for a public-domain Ada *interpreter* that will run under
>[rest of message deleted]
>
>I keep seeing messages like this in this Ada group, and I keep seeing messages
>about how _expensive_ Ada compilers, etc. are.  A great many people out there
>are asking about PD Ada compilers/interpreters but I've seen no answers.
>
>Do any PD Ada compilers/interpreters exist?  Or are all of these people asking
>the same FAQ and not getting any answers?
>
>I don't see how any PD Ada compilers could exist.  Ada is a rather large
>language and for DoD work must be periodically certified.
                                                ^^^^^^^^^
>
As one who has complained as loudly as anyone about the high price of
compilers, I feel obliged to take the other side for a moment. Bear
with me.

First, let's get some terminology straight. The word is "validated." What
does it mean? First, that the compiler developer has tested the product
using the current ACVC (Ada Compiler Validation Capability), several
thousand programs that test conformance to the standard, and found the
compiler to be in conformance ("passed" all the relevant tests). Second,
that a DoD designee has visited the developer site and repeated the tests.
There used to be a user fee for this of a number of thousand dollars, to
defray the cost of the site visit (is the fee still in effect?)

The labor to create a validated compiler, and pay the fees for the official
validation process, makes creating a validated compiler expensive, and so
most developers feel they should collect some revenue to offset these costs. 
That is one important reason that there aren't a lot of shareware or PD Ada 
systems out there. Essentially there are none. The only approximation is the 
various Unix/VMS/DOS versions of Ada/Ed, developed by New York University with 
DoD funding. (I can supply contacts by e-mail if anyone is interested).

What good is validation? Its main virtue is a guarantee of conformance to
the standard. This means that to an extent greater than with ANY OTHER 
LANGUAGE, one can write programs that will compile and give the same
behavior under ANY compiler on ANY platform. Validation does NOT guarantee
100% portability, which given hardware differences and spots where the
standard deliberately allows implementor discretion, isn't really
achievable. 

I believe this is especially useful in the education world, where students
move from OS to OS to get experience in lots of them. Try moving a Turbo
Pascal program (even one that doesn't use PC goodies) from your PC to
Unix to see how hopeless the Pascal standard is. (The Pascal standard
is a joke.) Try moving your Turbo program to Quick Pascal, staying on
the same machine. I can tell you from personal experience that it ain't easy.
With Ada, you can REALLY move stuff around, as long as you stay away from
machine-specific goodies (graphics, say). It works, folks.

We in the Ada community expend LOTS of effort picking apart those
areas of non-portability, and sometimes lose sight of the fact that 
validation offers a far higher degree of machine independence than has
ever been achieved before. Perhaps, as C compilers mature and adhere to
the ANSI standard, programs that aren't too tricky may be as portable as
Ada programs ar But I have had a enough grief moving C programs from
SunOS to HP/UX to appreciate what validation buys us.

I still hear questions from people who used interim compilers 5 years ago
like "does compiler XYZ do tasking?" or "does compiler PQR do generics."
The answer is "if it's validated, it has to." Validation covers ALL of
the language (though some machine-specific things like the stuff in 
Chapter 13 may not be tested too thoroughly, because they are machine-
specific anyway.)

Validation does NOT buy perfection, because validation is TESTING and
we know that "testing only shows the presence of bugs, not the absence of
bugs." Validation does not buy speed, either, because correctness is not the
same as efficiency. "It's easier to make a correct program fast than a
fast program correct."

Since 1983 (my first encounter with Ada compilers), I have watched Ada 
compilers on VM, VMS, Unix, DOS, and Macintosh mature and stabilize very 
nicely over the successive versions. They are MUCH more correct, and they
are MUCH more efficient. Maturity yields correctness; competition yields
speed. Current versions of compilers typically have both.

Someone has to pay the freight for this. The prices are still higher than
for other languages on similar platforms. There's no GNU Ada (yet, though
this might very well happen...). On the other hand, if you're in an
educational institution, have you checked the prices recently? $149.00
for a DOS or Mac compiler is surely getting into the right ballpark. 

And server licenses for Unix compilers are, I think, around $1000. these days, 
which is higher than I wish it were but still kind-of affordable for a school,
considering the number of users it would have. I believe that for multiple
servers the price comes down below that. 

And I have heard (though not from primary sources) that DEC and Sun will 
provide Ada compilers essentially free to their educational hardware customers.
I believe this is also the case for the IBM mainframe compiler, if the school 
has the right arrangement with IBM. I have used this last compiler recently,
and it's quite a respectable piece of software (TeleSoft built it).
Most vendors seem to be in a "be nice to the schools" mood these days.

I hope this little discourse has at least provided some understanding of the
issues. I'll archive it and ship it by e-mail to anyone who posts the
question again.

Cheers -

Mike

Re: Looking for PD Ada interpreter

[Jim Showalter]

An excellent post that I would like to reinforce in a few places with
comments of my own...

>What good is validation? Its main virtue is a guarantee of conformance to
>the standard. This means that to an extent greater than with ANY OTHER 
>LANGUAGE, one can write programs that will compile and give the same
>behavior under ANY compiler on ANY platform. Validation does NOT guarantee
>100% portability, which given hardware differences and spots where the
>standard deliberately allows implementor discretion, isn't really
>achievable. 

Fortunately, the language designers were quite aware of the fact that
100% portability is something of a chimera, and so designed the language
in such a way that non-portability is more often than not flagged by the
compiler. For example, since the bounds of numerics are defined in a
system-dependent package and all numerics descend in one form
or another from these base definitions, the compiler can check for
type declarations that simply cannot be supported by a particular machine
because, say, the range is out of bounds for what the underlying hardware
can support. This is a very nice feature, because one discovers these
things statically, when the satellite (for example) is still on the ground,
rather than at runtime when the satellite starts to spiral slowly into
the sun...

>With Ada, you can REALLY move stuff around, as long as you stay away from
>machine-specific goodies (graphics, say). It works, folks.

And the situation even for things that ARE machine dependent is not
bad, provided you design an architecture that identifies, factors out,
encapsulates, and abstracts machine dependencies into clearly identified
separate subsystems. This "virtual machine" approach to machine dependency
isolation works quite well--outside the machine-dependent subsystem the
interface remains invariant regardless of what platform the software is
running on (POSIX, by the way, is essentially just an attempt to do this
for UNIX). Of course, thinking like this requires discipline and means
that developers have to become less obsessed with bit-fiddling except
when it is truly important to fiddle bits (e.g. when writing a device
driver). I've seen code so poorly designed for portability that nearly
every page of listing contained at least one highly machine-dependent
call, usually without any justification whatsoever.

>Perhaps, as C compilers mature and adhere to
>the ANSI standard, programs that aren't too tricky may be as portable as
>Ada programs are. But I have had a enough grief moving C programs from
>SunOS to HP/UX to appreciate what validation buys us.

When people tell me they write in C, my first question is usually
"Which one?".

>Someone has to pay the freight for this. The prices are still higher than
>for other languages on similar platforms.

Indeed. On the other hand, the cost is more than offset by the increased
portability and repeatability of the resulting code. I keep saying this:
you get what you pay for. For free, one can get a C compiler, which then
permits you to run out and write code that costs a small fortune to
port to a different platform (just ask Microsoft...). Compared to these
sorts of costs, the initially higher cost of an Ada compiler is about
a ninth-order consideration. The phrase "penny wise and pound foolish"
comes to mind.

>Most vendors seem to be in a "be nice to the schools" mood these days.

Regarding the educational cost issues, I just had an idea. If the DoD
is really serious about fostering the growth of Ada awareness in
academia, rather than trying to underwrite the cost of developing a
compiler itself (and effort destined to be approximately as successful
as ALS-N), why not simply directly subsidize the cost of purchasing
Ada compilers by educational institutions. A school would simply buy
an Ada compiler/development environment for whatever hardware it
happened to already own (VAX, Sun, whatever) and send the bill to
the AJPO, who would reimburse them directly. In this way, the schools
could choose the most appropriate compiler from all of those that are
commercially available, and they could do so immediately, as opposed
to after a Big Government Agency finally gets around to producing
something a tenth as good for ten times the price. If the AJPO is
wondering where it would get the money to do this, may I suggest
cancelling ALS-N and using the money thus saved?

This seems so straightforward to me it must be illegal.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *