Re: How to get a »Conventional Ada Library« (Was: Ideas for Ada 200X)

[Marin David Condic <nobody@noplace.com>]

Robert I. Eachus wrote:
> 
> We (meaning the ARG and compiler vendors) have been getting better at 
> that.  But even with unlimited money, standards move very slowly.
> 

It isn't just money. Its that a standard that changes once a week isn't 
really much of a standard, is it? ;-)

But at the end of the day, if there were a library that existed as a 
"reference implementation" and it was maintained under the watchful eye 
of the ARG & Vendors and it was distributed along with most vendor's 
compilers, you'd have a mechanism for dealing with problems like lack of 
a "standard" square root routine as these things came up. I don't think 
anybody wants to see the syntax and semantics of the Ada language itself 
change on a quarterly basis, but a library could easily be released on a 
schedule like that and so long as it has some mantle of "officialness" 
and is distributed with most compilers, it becomes a mechanism for 
plugging up holes as they are found.

Its not that the job wouldn't still require some careful consideration 
regarding exactly what got into the library, what sort of specifications 
would be adopted and what the semantics should be for the 
implementations. You'd probably want the ARG/Vendors to come to some 
agreement about the intent of a given package and what its spec should 
look like. You'd also want them to do some "due diligence" to look over 
whatever has been produced to determine that it was of acceptable 
quality. Beyond that, you could probably leave lots of the details in 
the hands of whoever is actually doing the implementation. (That's 
typically how software gets built in "real world" projects anyway, 
right? And I think we're talking essentially about commissioning the 
development of a single body of software to be shared by all interested 
parties rather than the development of a "standard" that would be 
implemented by many interested parties.) So what I'm thinking about is a 
bit of a different situation than what the ARG and Vendors are typically 
doing with the standard. Rather than debating it endlessly and 
struggling to write formal, verifiable standards, they'd be in the 
business of outlining in broad-brush strokes what they thought they 
wanted for some specific subsystem and then reviewing the end-product to 
see if it met their intent sufficiently to warrant being released.

There are two catches here: One is agreement on the part of the ARG and 
Vendors that something like this should be done & accepted as part of 
"Ada" in some manner. (Its got to end up in most compiler distributions 
or its just another library dangling around on the Internet somewhere.) 
The other problem is to get people to develop the actual code once the 
Keepers Of The Eternal Flame have decided that a given thing is worth 
inclusion in the library. I think both these issues could be resolved. 
#1 is just the willingness of the ARG & Vendors to go down that path. 
(Yes, it would mean diverting some attention to it, so it isn't without 
cost. But if its worth having, its worth spending some $$$ to get it, 
right?) #2 is trickier, but we've seen in the past a variety of 
volunteer efforts in a number of settings that have attempted to do 
parts of this job. That means there are people out there willing to do 
the work, but they perhaps need some direction and incentivising in 
order to accomplish specific goals. I think it could be done with a 
little creativity. Get #1 resolved and somehow, some way, #2 can be 
brought about.


> The other thing that you have to remember is that the programming 
> culture around Ada had not developed when the original ANSI standard was 
> produced.  I was surprised, and so were a lot of other people, at how 
> the Ada culture developed in a way that was loathe to use almost 
> anything that wasn't in the standard.
> 

Sure. But this is not a goal in and of itself. Its more a symptom. (And 
it may be due to Ada over-selling the case for "portability". 
Realistically, most programs never port to a different compiler or 
platform.) I think most Ada users would be thinking along the lines of: 
"If its in the standard, then I know what it does and I can count on it 
being there. If its not in the standard, I may not be portable to a 
different implementation and I may not be able to find out what it does 
without difficulty." That doesn't automatically translate into a "Must 
Be In The Standard" requirement. If Ada had a library that was 
maintained as a reference implementation and distributed with most 
compilers, in some ways this would be even *more* "Standard" than 
something in the ARM. The ARM allows lots of wiggle room that can result 
in significant differences between implementations. If you had a 
reference implementation of a library, you'd have far less divergence in 
behavior between implementations because each vendor's realization of 
the library starts from a common code base. That, coupled with the fact 
that the end user is (presumably) getting source code for the library 
under some reasonably non-restrictive license and I think you'd see 
little difference in how the library would be treated compared to how 
the standard is treated.


> Even more surprising was the antipathy towards using representation 
> attributes and other Chapter 13 features.  By the time the 9X effort was 
> underway, no one was really surprised by the number of change requests 
> that basically translated to, "We want to do unchecked conversions, but 
> our coding standards don't allow us to use Unchecked_Conversion."
> 

I remember back in the olden-days of Ada83 how various lynch mobs formed 
up around some of the vendors, all of them carrying torches and 
pitchforks and chanting "Give Us Chapter 13 - Or Else!" :-) Chapter 13 
is absolutely essential for embedded system development and this was, of 
course, the original intended market for the language. Ada really 
succeeded in alienating that market who pretty much all went out and 
bought C compilers because they could at least get their job done and it 
didn't cost them their first born sons in order to get a working 
compiler. Having successfully driven away the original intended market, 
the ones that were left didn't care much about Chapter 13. But not to 
worry - Ada succeeded in finding enough other ways of alienating the 
remaining crowd that lack of Chapter 13 wasn't necessary to help it 
snatch defeat from the jaws of victory. And probably because Ada had 
concentrated on convincing its users on the virtues of portability and 
type safety, it actually might have created the climate of fear that 
lead to coding standards forbidding things in Chapter 13. Its a shame 
that the case got over-sold to the point where people wanted to chop out 
a critical part of the language rather than take a more practical view 
that aimed to use the features judiciously when and where it made sense.

The amazing thing is that Ada has had lots of die-hard fans who were 
convinced of the inherent goodness of the language. But despite that 
following, the language somehow managed to squander the capital by 
failing in its realization of the vision. Lots of things could be cited 
as missed opportunities. Initial poor quality of compilers, outrageously 
priced compilers, too ambitious a language for the hardware available at 
the time, too "big" a language for some of the smaller microprocessors 
it might have targeted, lack of cross-compilers for embedded hardware, 
etc. I'm sure we could go on but the real question ought to be "How do 
we take what we still have and parlay that into a substantially bigger 
market?"

I think the answer to that question is to focus in on Customer Needs. 
What is it that the average programmer in a given domain needs to get 
his job done? What are the important factors in satisfying that user? 
Rather than looking at this or that syntactic/semantic element of the 
language and asking if it can be enhanced or otherwise made "better", 
the focus should be on "If we do this thing to the language, how does 
that help the Ada user to get his job done faster, better, cheaper?" 
IMHO, most language changes might fall into the category of "This would 
be nice to have if you have unlimited resources to implement things, but 
I could find a reasonable way to program without it..." Whereas a 
library of useful tools that gave me lots of extra leverage because I 
won't be re-inventing the wheel would likely start making a much bigger 
impact on how useful the language would be for me.

The opportunity is there. We have yet to see if Ada can figure out how 
to exploit it.

> 
> I don't know if Rational did modify their compiler.  But the point is 
> that Rational, and their customers, thought that limiting the use of 
> Unchecked_Conversion was a good thing.  Even in this case, where as I 
> said, in Ada 95, one package would be a child of the other, so no 
> conversion, checked or otherwise, would be required.
> 
>

"Limiting the use..." probably is a good thing - but a limiting that 
should be done in the best engineering judgement of the end-user. I 
guess I sometimes resent a compiler trying to save me from myself when I 
am insisting "No, I *really* meant to do that and I *know* what the 
consequence is, so please get out of my way and stop trying to 'help' 
me!" Sometimes Ada gets too picky for the end-user's own good. But then 
again, I can't think of a language I've ever used that *didn't* get in 
my way sometimes, so maybe this is just normal. Still, for Ada's 
original intended audience, I think it was important not to take such an 
extreme approach to items like Unchecked_Conversion.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================