File name conventions for Ada units

File name conventions for Ada units

[SSUID Craig E Warsaw]

I'd like to start a discussion about file naming conventions
for ada units.  It would be ideal if people could quote from
any standards documents they are using.  The Ada Style Guide
used by NASA GSFC says nothing about file naming conventions.

I've been using the following (the convention used in my first
Ada class):

	package spec:	package_.ada
	package body:	package.ada
	subunit:	package__subunit.ada

I've also seen

	package spec:	package_spec.ada	or package_s.ada
	package body:	package_body.ada	or package_b.ada

By the way, there is an annoying aspect of all of these schemes.
If I use wildcarding to print or list files, all of the package
bodies occur before the package specs.  I'd prefer the specs
before the bodies, but that's not too important.

Thanks.

Craig Warsaw
Century Computing, Inc.
1014 West Street
Laurel, MD  20707
Internet:  cew@fox.gsfc.nasa.gov

Re: File name conventions for Ada units

[stt]

Re: file naming conventions.

We use:

    <unit-abbrev>.spc	--  Library unit spec
    <unit-abbrev>.bdy	--  Library unit body
    <unit-abbrev>.sub	--  Subunit
    <unit-abbrev>.dat   --  Body-less library package spec (data/types only)
    <unit-abbrev>.ada   --  Combination of spec and body
			      (Usually used for generics, spec-less subprogs,
			       and units exporting in-lined bodies)

    <unit-abbrev> is a shortening of the library-unit/subunit name
    to satisfy file-system length requirements.
    We have used these conventions with good success for > 500 K lines
    of Ada.  By the way, we try to minimize our use of subunits
    (refer to an earlier flame-battle on this subject!).

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: File name conventions for Ada units

[Dan Rittersdorf]

In article <589@censun1.UUCP> cew@censun1.UUCP (SSUID Craig E Warsaw) writes:
>
>I'd like to start a discussion about file naming conventions
>for ada units.
> ...
>
>	package spec:	package_.ada
>	package body:	package.ada
>	subunit:	package__subunit.ada

	This one seems awkward to me, personally, but personal taste is of less
	concern than being able to infer something about the contents of a file
	from it's name.

>
>I've also seen
>
>	package spec:	package_spec.ada	or package_s.ada
>	package body:	package_body.ada	or package_b.ada

	We use a scheme similar to this, except it doesn't have the annoying 
	attributes you mention below.

		package spec: package.a
		package body: package_b.a
		separate subunit: package_s.a

	The only thing that I would change here would be to name the subunit as
	well.  For example:

		package spec:       calendar.a
		package body:       calendar_b.a
		separate subunit:   calendar_local_time_s.a

	Unfortunately, there is no *written* standard to quote here -- this is a 
	defacto standard we use for naming units in the standard library which we
	release with HAPSE (Harris Ada Programming Support Environment).

>
>By the way, there is an annoying aspect of all of these schemes.
>If I use wildcarding to print or list files, all of the package
>bodies occur before the package specs.  I'd prefer the specs
>before the bodies, but that's not too important.
>
	As you can see, this scheme avoids this annoying aspect.
	BTW, I personally feel the same way -- I like to see related files
	clustered together, and in a compilation order within the group.
	This scheme has the desired effect.

>Thanks.
>
	You're welcome.

>Craig Warsaw
>Century Computing, Inc.
>1014 West Street
>Laurel, MD  20707
>Internet:  cew@fox.gsfc.nasa.gov

-danr
______________________________________________________________________________
  Dan Rittersdorf  (Dan'l fer short...) : danr@travis.ssd.csd.harris.com
  Harris Corporation, Computer Systems Division, Fort Lauderdale, FL 33309
______________________________________________________________________________
  "Even a fool is thought wise if he keeps silent, 
     and discerning if he holds his tongue." --  Proverbs 17:28

Re: File name conventions for Ada units

[David Emery]

The following come from the DEC Ada compiler:
>
>	package spec:	package_.ada
>	package body:	package.ada
>	subunit:	package__subunit.ada
Without a doubt, this is the UGLIEST, WORST naming convention I can
imagine.  I don't know who/why DEC thought this up, but s/he should be
shot, hung, drawn and quartered (and not necessarily in that
order...)!  There are several things that make it offensive:
	1.  the spec name is modified (with the trailing underscore),
while the body name remains "pure".
	2.  the syntax for the spec and subunit is not an Ada identifier
	3.  it's just ugly.
	4.  the body preceeds the spec in "lexical sorting order"

The major requirements I like to place on naming conventions is that
	1.  the spec filename matches (as much as the O.S. permits) the
name of the Ada unit.
	2.  the filename of the body should lexically follow the spec, so
I can do the following:
	ada my_package*
and the spec gets compiled first, and then the body (via expansion of
the wildcard).  

On Unix I use:
		unit_name.a
		unit_name.body.a
on MS-DOS I use:
		abbrname.ada
		abbrname.adb
(sometimes you have to get creative to come up with useful filenames
within the limitations of DOS...)

Incidently, I agree with Mike Feldman about the inconvience of compilers that
force a specific naming convention, such as Verdix.  I've submitted a
bug report to this effect to Verdix after every major release...

				dave emery
				emery@aries.mitre.org

Re: File name conventions for Ada units

[Rik Palo]

In article <EMERY.90Oct1105615@aries.linus.mitre.org>, emery@linus.mitre.org
(David Emery) writes:
;From: emery@linus.mitre.org (David Emery)
;Newsgroups: comp.lang.ada
;Subject: Re: File name conventions for Ada units
;
;The following come from the DEC Ada compiler:
;>
;>	package spec:	package_.ada
;>	package body:	package.ada
;>	subunit:	package__subunit.ada
;Without a doubt, this is the UGLIEST, WORST naming convention I can
;imagine.  I don't know who/why DEC thought this up, but s/he should be
;shot, hung, drawn and quartered (and not necessarily in that
;order...)!  There are several things that make it offensive:
;	1.  the spec name is modified (with the trailing underscore),
;while the body name remains "pure".
;	2.  the syntax for the spec and subunit is not an Ada identifier
;	3.  it's just ugly.
;	4.  the body preceeds the spec in "lexical sorting order"
;

Actually, since Digital's format is an internal format for the compiler's copy
of the files.
It works fine and doesn't impose anything on the user.  As a matter of fact, if
the project
can live without the RECOMPILE command, and keeps the source files in some
repository visible for DEBUG, then the Ada copied files can be disabled
altogether saving the disk space -- this implies that the users wish to do more
work than is necessary keeping track of source files or use Digital's Code
Management System (CMS).  The VAX Ada compiler understands how to get files from
it, so the above is actually quite reasonable -- but not everybody wishes (or
can afford) all the tools all the time.  That's why the default operation works
in the minimum environment.

On the other hand, using a consistent naming convention *is* important. 
Rational's approach is great because it permits forgetting all about a mapping
from source file to target unit;  Digital, with its compilation system [pre]load
function, is aiming for a similar result - namely let the compiler "find"
compilation units in whatever source files they happen to reside. This even
allows *all* units to be in one file!  This would/could allow this time lost
quibbling over file naming to be spent where *I* feel is more important -- the
naming of units and types, a whole other can of worms in a Coding Standard
philosophy.

	regards

		rikki

Re: File name conventions for Ada units

[Michael Feldman]

In article <589@censun1.UUCP> cew@censun1.UUCP (SSUID Craig E Warsaw) writes:
>
>I've been using the following (the convention used in my first
>Ada class):
>
>	package spec:	package_.ada
>	package body:	package.ada
>	subunit:	package__subunit.ada
>
>I've also seen
>
>	package spec:	package_spec.ada	or package_s.ada
>	package body:	package_body.ada	or package_b.ada

Well, much of this depends upon the vagaries of the compiler. We have one
compiler that accepts _only_ filetype .a (VADS) and another that accepts _only_
filetype .ada (Irvine). It is exceedingly annoying to have to change filenames
even on the same operating system (Unix). Meridian suggests (and will accept)
.ads for a spec, .ada for a body or main. In fact, their compiler will accept
any reasonable filetype as long as it is given explicitly. If you carry the
"kind of unit" info in the filetype, then e.g. package specs and bodies can
have the same name (this is what Meridian suggests), e.g.

   package_name.ads and package_name.ada

I would go further and use .ads for a spec, .adb for a body, .ada for a
main, and maybe .sub or whatever for a subunit. Why there are compilers, in
this day and age, that limit file types to some predetermined value, is
absolutely beyond me. At most there should be a default which can always
be overridden.

Are others frustrated with these seemingly unjustifiable compiler limits?
Can some compiler folks out there justify the limitations? Maybe I'm
missing something here.
>
>By the way, there is an annoying aspect of all of these schemes.
>If I use wildcarding to print or list files, all of the package
>bodies occur before the package specs.  I'd prefer the specs
>before the bodies, but that's not too important.
My encoding above would not solve your problem, but nothing better comes to
mind at the moment.


---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: File name conventions for Ada units

[arny.b.engelson]

In article <2190@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
> In article <589@censun1.UUCP> cew@censun1.UUCP (SSUID Craig E Warsaw) writes:
> >
[the DEC convention of pkg_.ada for spec, pkg.ada for body, pkg__unit for subs]

[the more common convention of pkg_s.ada for spec and pkg_b.ada for body]
 
> [VADS only accept ".a", and Irvine only accepts ".ada", how annoying]
> [extrapolating from Meridian's convention...
> I would go further and use .ads for a spec, .adb for a body, .ada for a
> main, and maybe .sub or whatever for a subunit. Why there are compilers, in
> this day and age, that limit file types to some predetermined value, is
> absolutely beyond me. At most there should be a default which can always
> be overridden.
> 
> Are others frustrated with these seemingly unjustifiable compiler limits?
> Can some compiler folks out there justify the limitations? Maybe I'm
> missing something here.
 
I agree that restrictions like Verdix and Irvine put on file types is
unacceptable.  But making Ada file types a standard, or even a uniform
convention, is not (IMHO) a good idea.  There are simply too many different
operating system file name formats still around.  Some limit file types to
3 characters, some (I think) still limit it to 1, others have no limit.
Overall file name length can be limited to 8, 14, or any number of chars.
It's easy to see where any one format could result in conflicts with other
tools in the environment that create files with the same extensions.  (The
".a" is an obvious example).  I don't want to lose my source code because
some CASE tool decides to create a file with the same name, especially in
UNIX where I don't have old versions.

Personally, I like the following:

    spec     body     main    subunit

  x_s.ada   x_b.ada   x.ada   x_subname_b.ada

Where "x" is the name of the compilation unit, which always ends in
"_pkg", "_task", "_proc", or "_func".  Of course, this works best when
file name length isn't limited (or you don't use subunits :-) ).

  -- Arny Engelson   att!wayback!arny

Re: File name conventions for Ada units

[Michael Feldman]

In article <1990Oct2.171010.28845@cbnewsl.att.com> arny@cbnewsl.att.com (arny.b.engelson) writes:
> 
>I agree that restrictions like Verdix and Irvine put on file types is
>unacceptable.  But making Ada file types a standard, or even a uniform
>convention, is not (IMHO) a good idea.  There are simply too many different
>operating system file name formats still around.  Some limit file types to
>3 characters, some (I think) still limit it to 1, others have no limit.

Agreed. We can go too far with trying to impose a standard. But I still
_local_ or project standards are a very good idea, and I am annoyed that
there are compilers around that refuse to let me do that, or impose
arbitrary file extensions on me. I wonder if anyone from Verdix could 
respond here, and at least let us know why they do it. If TeleSoft and
Meridian (under Unix) can accept my file extensions why can't VADS?
Indeed, an earlier version of VADS _could_ do it. What's up?

Mike Feldman
it in an earlier version), 

Re: File name conventions for Ada units

[Erland Sommarskog]

Michael Feldman (mfeldman@seas.gwu.edu) writes:
>I would go further and use .ads for a spec, .adb for a body, .ada for a
>main, and maybe .sub or whatever for a subunit. Why there are compilers, in
>this day and age, that limit file types to some predetermined value, is
>absolutely beyond me. At most there should be a default which can always
>be overridden.

I can only agree. I don't if it has anything to with the O/S, but
it seems like every Unix compiler I have met, not only Ada compilers,
has some suffix you must use - and provide each time. Coming from
the VMS world I find this strange. The normal file type for Ada
files is .ADA, and if you use it you have to tell that to the
compiler, but if you prefer .FOR you can do so.

I guess it is some old Unix conventions hiding here. (And since it
is Unix, it must be good. :-))
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
"Nelly Nilsson n|jer sig numera n{ppeligen med nio n|tter till natten"

Re: File name conventions for Ada units

[Alan Adamson]

     One reason for restricting possible filenames is to allow the compiler
to behave differently depending on the format of the filename it is acting
on.  This is common (universal?) with C compilers.  Were one in a frame of
mind to market this 'feature', one might invoke such terms as "object-
oriented".

     In the middle of the development cycle for our Ada compiler, we had a
convention of extending any filename without a "." in it by "ada".  Much
debate accompanied the final decision to impose no file-naming restrictions 
at all on the user, but we finally chose that path.

      Having now, many months later, been exposed to the variety of ways our
customers name their Ada source files, I am very thankful we followed this 
path.


Alan Adamson
IBM Canada Ltd.

Re: File name conventions for Ada units

[Alex Blakemore]

In article <2152@enea.se> sommar@enea.se (Erland Sommarskog) writes:
> Coming from the VMS world I find this strange. The normal file type for Ada
> files is .ADA, and if you use it you have to tell that to the
> compiler, but if you prefer .FOR you can do so.


You mean if you follow the .Ada convention, you DON'T have to tell
the compiler. I agree enforced file name suffixes are unreasonable.
Even better, some systems (e.g. Rational) don't view source as files
- you edit the actual library units.  This problem never arises. 

-----------------------------------------------------------------------
Alex Blakemore                       Internet: blakemore@software.org
Software Productivity Consortium     UUNET:    ...!uunet!software!blakemore
2214 Rock Hill Rd, Herndon VA 22070  Bellnet:  (703) 742-7125

Re: File name conventions for Ada units

[Mike Harrison]

In article <1682@software.software.org> blakemore@software.org (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. 
>

I first heard of this idea several years ago and have always wondered about 
a couple of points:

    - How do you get the validation suite into the program library, it IS a
      set of files (not library units).

    - How do you input programs containing errors detected by the structured
      editor; this may seem to be a silly point, but for educational purposes
      it may be desirable to expose students to (intended) programs with
      errors and they may be required for compiler testing (and there are
      many such in the validation suite).

I presume that such systems MUST be provided with a conventional file input
mechanism in addition to the structured editor, so the problem (cited above)
*does* arise (although it may not impact the user in quite the same way).


While I am on my 'hobby horse', I may as well say that I hate and detest
structured editors (for my own use) in that they force the user to adopt a
particular approach to ordering the input. I often find that I prefer to
input programs in an unstructured order (often arbitrarily copying 'chunks'
of code from other parts of the file or from other files).
I accept that structured editors may appeal to some (particularly to novices
or others unfamiliar with the the syntax of the language) but for the 
'professional program' I believe that they just get in the way!


Mike,



Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;

Re: File name conventions for Ada units

[Robert Firth]

In article <1682@software.software.org> blakemore@software.org (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 this, surely, is the right answer.  An Ada compiler does not
operate on files, but on compilation units.  The association
between those units and entities in some other universe of
discourse is not the proper concern of the compiler, and the
knowledge, or partial knowledge, of the designations of those
entities ought not to be bound into it.

Re: File name conventions for Ada units

[Michael Feldman]

In article <2152@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>
>I can only agree. I don't if it has anything to with the O/S, but
>it seems like every Unix compiler I have met, not only Ada compilers,
>has some suffix you must use - and provide each time. Coming from
>the VMS world I find this strange. The normal file type for Ada
>files is .ADA, and if you use it you have to tell that to the
>compiler, but if you prefer .FOR you can do so.

Meridian AdaVantage for Unix will, I think, accept any filetype
(but of course it must be supplied explicitly). I have not tried to
break it, but it accepts ahny filetype I'd ever use for an Ada file...
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: File name conventions for Ada units

[Brian Hanafee]

In article <2202@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes:
>
>Meridian AdaVantage for Unix will, I think, accept any filetype
>(but of course it must be supplied explicitly). I have not tried to
>break it, but it accepts ahny filetype I'd ever use for an Ada file...

Not quite.  Meridian (at least under Ultrix) is guilty of spitting
out tons (I don't even know how many) of intermediate files, each
with their own predefined extensions.  If you happen to name a file
with one of those (undocumented) extensions, it will fail.  Try
using the extension ".ils", for example.  It also does a very
simplistic job of generating object file names in its ".aux"
directory;  you have to be somewhat careful with units whose names
start with the letter 'b'.

Brian Hanafee

Re: File name conventions for Ada units

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / emery@linus.mitre.org (David Emery) /  7:56 am  Oct  1, 1990 /

>Incidently, I agree with Mike Feldman about the inconvience of compilers that
>force a specific naming convention, such as Verdix.  I've submitted a
>bug report to this effect to Verdix after every major release...
>
>				dave emery
>				emery@aries.mitre.org

I agree whole heartedly.  But doesn't  the C compiler require  .c?  This is
indeed  stupid.  IMHO, you should be  able  to say: ada  sourcefile and the
compiler should look for "sourcefile" first  and then "sourcefile.ada" next
(i.e.  you  could  have your own   naming conventions.  Also if  you   said
sourcefile.ads then the compiler should look only for sourcefile.ads.  This
allows you to  have a breifer  (?)  command  syntax if you  want (i.e.  ada
sourcefile compiles  "sourcefile.ada"  if  "sourcefile"  doesn't exist) and
allows you to override this either by having no .ada suffixed file or using
you own suffixes of your own choosing.

Re: File name conventions for Ada units

[Dan Bernstein]

In article <920035@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes:
> IMHO, you should be  able  to say: ada  sourcefile and the
> compiler should look for "sourcefile" first  and then "sourcefile.ada" next

The beauty of this system being that if sourcefile is ever removed
accidentally, you end up using sourcefile.ada even if it is entirely
different. This contributes greatly to bug concealment, unreliability,
and other software engineering techniques.

---Dan

Re: File name conventions for Ada units

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / brnstnd@kramden.acf.nyu.edu (Dan Bernstein) /  1:59 am  Oct 11, 1990 /
>
>The beauty of this system being that if sourcefile is ever removed
>accidentally, you end up using sourcefile.ada even if it is entirely
>different. This contributes greatly to bug concealment, unreliability,
>and other software engineering techniques.

The    person  that   names one   file    sourcefile  and  a  different one
sourcefile.ada deserves what he gets!   

Same kind of problems occur with things like linked  files  and unprintable
characters in  file  names.  A certain amount of  knowledge about  the file
system and its behaviour has to be assumed.

Re: File name conventions for Ada units

[munck]

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