cew@censun1.UUCP (SSUID Craig E Warsaw) (09/29/90)
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
stt@inmet.inmet.com (09/29/90)
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 02138danr@SSD.CSD.HARRIS.COM (Dan Rittersdorf) (09/30/90)
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
mfeldman@seas.gwu.edu (Michael Feldman) (09/30/90)
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 ---------------------------------------------------------------------------
emery@linus.mitre.org (David Emery) (10/01/90)
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
arny@cbnewsl.att.com (arny.b.engelson) (10/03/90)
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
sommar@enea.se (Erland Sommarskog) (10/03/90)
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"
adamson@csri.toronto.edu (Alan Adamson) (10/03/90)
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.blakemor@software.org (Alex Blakemore) (10/04/90)
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
mfeldman@seas.gwu.edu (Michael Feldman) (10/04/90)
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 ---------------------------------------------------------------------------
mph@lion.inmos.co.uk (Mike Harrison) (10/04/90)
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;
firth@sei.cmu.edu (Robert Firth) (10/04/90)
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.
mfeldman@seas.gwu.edu (Michael Feldman) (10/04/90)
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),
bhanafee@ADS.COM (Brian Hanafee) (10/05/90)
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
munck@STARS.RESTON.UNISYS.COM (10/05/90)
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
palo@rikka.enet.dec.com (Rik Palo) (10/06/90)
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
defaria@hpclapd.HP.COM (Andy DeFaria) (10/09/90)
>/ 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.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/11/90)
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
defaria@hpclapd.HP.COM (Andy DeFaria) (10/12/90)
>/ 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.