One often uses a particular "pattern" or "paradigm" or "idiom"
to develop a "chunk" of software.  (Intentionally vague.)
Such paradigms, among other things, always impose constraints
on how the code should be written.

Such design intentions, if documented at all, are generally
documented in comments, or a separate design document.  There
is no way to indicate them in the language; they are at a
higher semantic level than the code's syntax will denote.

We would get four benefits from tagging such design intentions,
in a machine-processable way, in the source code:

1. The compiler and ASIS tools can check and make sure you
   did not exceed your own intended boundaries (as strong
   typing does on a lower level of design).

2. Maintainers can see this, and can have confidence that
   the unit meets this semantic specification (before and
   after they change it) because a tool can check it.

3. Graphic design tools can insert them into the code, and
   analysis tools may be able to interpret them to generate
   a higher-level representation of the code than would be
   possible using just the executable statements.

4. You don't have to remember which chunks should be
   interactively checked for what semantic constraints.
   You assert it once, in the code, and the tool only
   checks the things that need to be checked.

These aren't new ideas.  These are the benefits that FORTRAN
provided over assembly.  Ada provides these benefits over
C for many of C's common design idioms.  I'm just interested
in raising the semantic level on which the machine can
backstop my own coding efforts.

It seems to me that Ada, with its ASIS semantic interface
spec, supports this kind of tool to an extent only dreamed
of by developers in other languages (and feared by
hack-n-slash coders).

Is there existing work on this kind of semantic support tool?
Surely so.  Can you give me a pointer to newsgroups, web sites,
or good key words to search on (like names of prototype tools)?

Thanks.

- - - - -
Forget pragmas and OOP, OK?  They seem to be hot buttons
that generate heat without light.

So why did I use them?  Because I think better with concrete
examples.

I used C++ style OOP to work out the idea, because Ada
ALREADY supports it, in some ways better than C++, so it
seems to me that this represents a market opportunity.
This is especially true if we can provide direct support
for their familiar working paradigm.  Besides, it drives
home the fact that you can do C++ style OOP in Ada, if you
LIMIT Ada.

I used pragmas because I assumed they would carry through
a semantic analysis tool like ASIS.  Comment flags, if they
carry through ASIS, would be adequate, although you do have
to worry about things like spelling errors causing the tool
to silently ignore flags.

Best,
Sam Mize

--
Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam