> Michael Feldman wrote:
> > Why not get to
> > work defining what _you_ believe to be the right part A/part H definition,
> > try to produce a compiler, or at least a path to one, and worry about
> > validation later?
> What if having a _validated_ Ada subset compiler gives you a competitive
> advantage over C?
We'll never know till we try, will we? I have had lengthy discussions with
various validation gurus on this subject; these really went nowhere.
Better, IMHO, to follow Sy's suggestion and test the desired compiler
using the appropriate ACVC subset, and leave the politics of _actual_
validation for a later stage.
In the TQM class my wife had to sit through, this was called "cutting
the low-hanging apples first," that is, doing the stuff you can do, and
not holding it hostage to resolving controversial issues. Validation is
a term of art in this business, and trying to get, in essence, prior
approval of validatability is, in my experience, futile.
I think the proper order is
(1) define just what you want. Don;t tinker with the syntax, try to
define the desired set of valid programs using Annex H Restrictions.
(2) build the compiler as simply as possible. This means starting
with GNAT and building a back end for the desired platform; it would
be the height of foolishness to mess with the GNAT front end or try
to write a compiler from scratch (yet).
(3) see who's REALLY interested in it.
(4) discuss validation _only_ after the thing has a track record.
> We seem to have a lot of these "chicken-and-egg" situations. For example:
Much of Ada has been "chicken and egg." We get into these deadly embraces -
everyone has great ideas, but wants others to implement or pay for them.
> 1. Users don't use Ada for tiny processors because there's no Ada
> implementation for their processor. So, they use assembly or C.
> 2. There's no Ada implementation because no vendor has built one.
> 3. No vendor has built one because (opinions vary among the following):
> (a) There's no market for it (see 1 above).
> (b) It is technically difficult to implement full Ada on these
I don;t think this has ever been demonstrated. Ada was conceived for
embedded systems, and based on the early experience with early compilers
for bigger boxes with big OS-es on them, everyone seems to buy into this
> (i) No one has implemented a subset compiler, because there's
> no definition of the subset
Well, this list has a lot of smart people on it. I'll volunteer to host
a small mailing list _just_ for those who are willing to get into serious
discussions on _this_ subject. If in the next week I get a dozen e-mail
notes from serious people (no lurkers or kibitzers, please!), I'll
set up the list at GW. Maybe this will break the vicious circle.
> (ii) There's no definition of the subset, because there's no
> market to drive a subset (see 1 above).
But we seem to have plenty of people on Team-Ada with expert opinions
on the subject, don;t we? Who wants to get down to serious work?
> (c) Ada (even a subset) doesn't "make sense" for small processors
> (I don't buy this, but I could be wrong).
This remains to be seen. There is, in my experience, no a priori reason
to exclude a small-processor _target_, hosted on some other GNAT host
(given the ease of setting up GNU crosses, _any_ GNAT host, even a DOS
box, will do.)
> (d) All of the above.
> My personal belief is that the best way to fix this is at point 2.
> Someone needs to build an implementation for a few popular tiny
> processors (possibly as a subset), market it, and see if anyone buys
Step 1 is to define the desired language, as I outlined above.
> You can do this as a business venture, of course
> (it's called "creating a market"), but I don't see any Ada vendor who
> wants to create this market badly enough.
> So, it will be more likely that someone
> will do this just for the challenge of seeing if it can be done.
Right. This is how GNAT-Mac got started. A few of us decided to just
do it, to break exactly the same kind of vicious circle. Midway through
the doing, it turned out we found some funds to help it along, and
we will end up with a VERY nice forthcoming commercial release.
Earlier, we broke another vicious circle: a cheap, student-oriented
compiler. A lot of volunteer work, augmented later with a teeny bit
($40k) of AJPO funding, produced the 2 GW-Ada/Ed's (DOS, Mac), which
got many hundreds, if not thousands, of students started with Ada
till these systems were superceded by GNAT.
In both of these cases, what made it possible was _leveraging_
existing compilers (Ada/Ed, GNAT) and adding value.
Dunno - maybe it takes a few crazy CS professors to break the loop.
> This has a low probability of success, but it seems to be the only way.
It seems defeatist to say it has a low probability of success. Given
a few people who know what they're doing and want to do it, it could
> > C compilers are not (in general) validated, and C++
> > ones are certainly not, because there is no standard to validate against.
> Tom Peters calls this the "We're no worse than anyone else" problem. To break
> into a new market, you need powerful competitive advantages. It's often smarter
> to do things _because_ your competitors aren't doing them -- like having an
> independent organization (e.g. NIST) make a statement about the quality of your
> compiler, and/or working to a widely-accepted and formally controlled (if not
> internationally standardized) specification of your product, and/or having the
> support of a large group that "gets out the word" on a new project. For this
> project (an Ada subset compiler for tiny processors), I would say we're 0 for 3.
I agree, but you are forgetting that validation has an entrenched "culture"
that is - at the moment, anyway, unfriendly to the idea. THat's a
high-hanging apple; cut it down later!