> > In situations where that paradigm truly is meaningful, nothing stops you from
> > defining
>
> Nothing helps you ensure you remembered to do so consistently, either.

I'm not sure what you mean by consistency.  If you mean no deviation
tolerated, then Ada is not the right language.  If you mean you just need
to highlight deviations to decide whether they are appropriate, then....

> > I think new pragmas to enforce a particular non-Ada-like style are not
> > wise.  If it takes three pragmas to do it, and three for the next guy's
> > non-Ada-like style, and three for the next style idea, and ....
> >
> > Better to just write an ASIS tool (or employ a very talented proofreader)
> > that suits your needs.
>
> I'm game.  How does the programmer tell the ASIS tool "this is one
> of those things for which I want you to check class purity" (or
> data-flow-design constraints, or no-nested-procedures, or whatever).

DIANA allowed one to reconstruct comments.  I do not know whether this is
true of ASIS.  If not, can ASIS retrieve info on pragmas not recognized by
the compiler vendor?

I still would proceed slowly on "standardizing" new pragmas for stylistic
purposes.  As I said, if we introduce several pragmas to support one
stylistic paradigm, how many other styles might also want pragmas?