From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!ucbvax!STARS.RESTON.UNISYS.COM!munck
From: munck@STARS.RESTON.UNISYS.COM
Newsgroups: comp.lang.ada
Subject: Re: File name conventions for Ada units
Message-ID: <9010051204.AA09248@aviary.Stars.Reston.Unisys.COM>
Date: 5 Oct 90 12:04:56 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

Alex Blakemore writes:

>Even better, some systems (e.g. Rational) don't view source as files
>- you edit the actual library units.  This problem never arises. 

and Robert Firth replies:

> And this, surely, is the right answer. ...

Well, maybe.  It seems to me that it just moves the problem under discussion,
since the library itself is a file (always?) with the possibility of being
named "name.type".  The REAL problem, of course, is that UNIX, MSDOS, VMS,
and everything else in wide use allow names of that form, leading good Ada
programmers to equate the ".type" with the TYPE of an Ada object.  Encoding
the type of something in its name is a state-of-the-art solution made popular
by FORTRAN I, except that FORTRAN enforced the IJK.. convention and these
"modern" OSs do not.

The real right answer is that of modern PSE data repositories such as
CAIS-A, PCTE+, and ATIS, the strongly-typed Entity-Relationship-Attribute
data structure.  Ada source code, if that's what your system uses, should
be contained in an object of type AdaSource, with CompiledInto relationships
to objects of type AdaLibrary.  Better, of course, would be what TeleSoft
is said to be doing on PCTE+, implementing the library as an ERA structure.
Then all the tools that need to operate on data found in the library - editors,
compilers, analyzers, linkers, etc - can "see" the entities and relationships
in the library.

Bob Munck