Solo Programadores 22/SOLO_22.iso/docs/misc/old/gnatchat.1

Text File | 1996-04-29 | 12.4 KB | 251 lines

GNAT CHAT #1 23 Apr 1993
------------------------

GNAT CHAT is an abstract of discussion items sent to [e-mail].
Since this is a rather giant mailing list, rather than let a free for all
interaction occur on it, we will abstract comments we receive, and then mail
them out from time to time. As you see above, they are numbered, so that you
can make sure you haven't missed one. If you don't want to receive GNAT CHAT
notes, but only the main technical reports and progress reports that we send
out, let us know. I am currently adding the headers, whose format is presumably
clear. I won't object if poeple want to add such headers to their messages to
save me a bit of time, but I won't insist on it! (I = Robert Dewar, for the
moment moderator for GNAT-CHAT). Messages to gnat-chat can either be sent to
[e-mail], or as noted above, to [e-mail] (the latter
address makes it convenient for those who just like to press the reply key!)

------------------------------------------------------------------------------

Reference: GC-1.1
Date: 23 Apr 1993
Author: Richard Stallman
Subject: Syntax checking only mode
References: GNOTE1, April 12

 [referring to the point that the checks for one compilation unit per file
 and the matching of compilation unit names and file names are omitted in
 syntax check only mode]

 >It is unclean for an option for "syntax checking only" to have also
 >the effect of allowing syntax that is normally forbidden!
 >That should be a separate option.

 Robert Dewar replies:

   That's reasonable. The multiple compilation units per file is
   a special check that probably should be controlled by a separate
   switch. The naming convention is actually a semantic check for us,
   so it falls out free for it not to be performed in syntax only mode
   and would be extra work to check during the syntax phase (after all the
   division between syntax and semantics is a little arbitrary, and in
   syntax only mode, there are after all a lot of checks that get omitted!)

------------------------------------------------------------------------------

Reference: GC-1.2
Date: 23 Apr 1993
Author: Richard Stallman
Subject: Names of files
References: GNOTE1, April 12

 [referring to the suggested convention in GNOTE1 for distiguishing spec and
 body names, i.e. to add different suffixes to the names with the default being
 a dash after the end of the spec name]

 >It seems more natural to me to use a different extension for spec
 >files, rather than a dash.

 >  The corresponding object file has the same file name with the extension .o
 >  (which is why the spec and body of a file have to have different file names,
 >  not just different extensions).

 >This is not a necessary consequence. If a spec file is named foo.spc,
 >its .o file does not *have* to be named foo.o. It could be named
 >foo-.o or foo.so.

 > ABC.DEF.GHI (child spec)     abc-def.ghi-.ada

 >Wouldn't this be abd-def-ghi-.ada according to the current rules?

 Robert Dewar replies:

   Current typical Ada usage is divided between the two conventions. For
   example, Dec's standard convention is to add a trailing underscore. We
   changed this to a trailing minus, because otherwise the new Ada 9X feature
   allowing trailing underscores causes confusion (flames to dev/null please!)

   It is also our intention to allow user specification of arbitrary suffixes,
   allowing for example following the Verdix convention which adds a separate
   suffix to specs and bodies.

   However, the convention that Richard mentions is also very common. For
   example, in the Alsys world, a common usage is .ada for a spec, and .adb
   for a body.

   Our general philosophy in GNAT should be to satisfy as wide a variety of
   styles as possible, so it indeed seems a good idea to allow this possibility
   and we will implement this. Actually we discussed this earlier, and the
   only reason we didn't do it was because we were a little nervous about
   introducing object files not called .o, or object files whose name didn't
   match the source name.

   Clearly some tools might be discombobulated by violating either of these
   two standard conventions for object file names, but if it's only one of
   the possible options, I don't see any objection.

   The abc-def.ghi-.ada is a typo, it should indeed be abc-def-ghi-.ada

------------------------------------------------------------------------------

Reference: GC-1.3
Date: 23 Apr 1993
Author: Richard Stallman
Subject: "Subversion" of consistency checking rules

[in response to the discussion of situations in which the consistency
 checking rules stop you doing things which would actually work. In
 particular adding an entity to a package is often safe]

 >This case is so common that I added a feature to GNU Make just for its
 >sake. This is the -o FILE option, which says, "pretend file FILE is
 >very old (i.e., older than everything that depends on it)". I use
 >this frequently when working on GCC.

 >The time stamps in Ada .o files will make -o useless. To me, this seems
 >like a shame. I understand some Ada users are determined to have no way
 >to do what -o is intended for; but I think we should provide a way for
 >users who share my attitude.

 >Perhaps the binder should also have an -o FILE option to disable
 >checking of the timestamps that refer to FILE. Use of this option could
 >be considered "deliberate subversion of the defenses"; also, to get an
 >executable that certainly had the right compilation order, you need only
 >rerun the binder and not specify -o.

 Robert Dewar replies:

   First, the -o option in the binder seems perfectly reasonable. Perhaps in
   contrast with some other Ada thinking in the past, we have no objections
   to options that extend or modify Ada behavior, as long as there is a mode
   in which things work "properly" then that's good enough. [if we abbreviate
   this option to "p" then you can think of it as meaning either "proper" or
   "pedantic" depending on your point of view!]

   An aside here. There has long been a feeling in the Ada community that it
   is somehow improper to have switches of this kind. This feeling comes
   partly from the "Declaration of Conformance" that vendors have to sign
   to get a validation certificate which says that they have not implemented
   extensions. What the DOC means is that you have to have a "proper" mode in
   which Ada works as specified without extensions, and that the validation
   must run in this mode (remember that the validation status report includes
   the options used to run the validation suite). It does NOT mean that you
   can't have switches, that modify normal behavior, and indeed many vendors
   have implemented such switches as "all-checks-off" which clearly is outside
   normal Ada semantics. The 9X reference manual, as well as the 9X validation
   policy, will try to avoid conveying the incorrect impression that such
   "extensions" are somehow immoral or illegal. The no supersets policy of Ada
   is not meant to outlaw such switches, but rather to ensure the existence of
   a mode in which maximum portability is guaranteed. In this respect Ada is
   in practice not so different from say COBOL with its FIPS flag which has a
   similar intention. The difference is that the FIPS flag in COBOL is part of
   the validation procedure, and is not mentioned in the standard itself.

   As an example of another such switch, consider the switch in GNAT which
   specifies the character set to be used for identifiers. The 9X RM requires
   that the standard mode allow only Latin-1 letters in identifiers, however,
   it quite explicitly suggests that other modes might be appropriate,
   depending on local character set usage. The explicit permission here is
   not necessary, since, as described above, even Ada 83 has always had
   general permission for this sort of thing. The statement is however added
   to the 9X reference manual to emphasize that this switch in particular
   is appropriate. In GNAT, we have a switch with the current settings:

       1  Latin-1
       2  Latin-2
       3  Latin-3
       4  Latin-4
       5  IBM PC
       6  Allow all possible upper half ASCII characters
       7  Allow no upper half ASCII characters (like Ada-83)

   The default is Latin-1, except on PC's where the default is IBM PC. Of
   course if anyone ever tried to validate GNAT (we have no current intention
   of doing so, and it's not part of our project), then of course they would
   have to specify Latin-1 as part of the validation switch choice.

   Going back to the original item of discussion, there certainly are cases
   in which it works fine to ignore the consistency checking. Adding an entity
   to a package often, but not always is harmless. Adding an entity to the
   end of a package is always harmless (at least we haven't run into any
   violations of this so far). The -o option of the binder is a reasonable
   way of just doing away with a check on an "I-assume-all-risks" basis.

   As Richard points out there are however, probably many Ada programmers
   who would feel uncomfortable using such an option. After all one of the
   major attractions of Ada over other languages is precisely that it ensures
   safety in such situations. Consequently, while we have no objections to
   the -o switch (in fact I'm writing the binder right now, and I already
   put this switch in earlier this morning!) we are also exploring other
   less drastic options in this area.

   A relatively simple approach is to implement a tool that does the
   following:

     Input:
    Old version of some spec
    New version of some spec
    ADL information from compilation of new spec

     Output:
    Possibly modified version of ADL information for spec

   The idea is to compare the two source files and determine if the changes
   to the new spec are harmless. A very obvious case is a change in comments
   (it's *so* annoying to have to recompile the world because you fix a typo
   in a comment in an important spec!) A more ambitious case is adding an
   entity at the end of a package. One can go further. Examples of possible
   harmless changes are:

    o  Adding a default expression for a subprogram parameter where none
        was present before

    o  Adding an entity in the middle of a package which is not referenced
        later on in the same package

    o  Adding a with clause to a package that was not present before

    o  Adding a pragma Inline to an existing subprogram

    o  Reformatting which does not change the actual program

    o  Uniform name change for a local variable

        (and, to paraphrase Tom Lehrer, "these are the only ones of which the
         news has come to GNAT, there may be many others but we don't know
         where they're at")

   If the new source is found to be compatible with the old source, then the
   modified ADL file contains the time stamps of BOTH the new and old source
   files, with the implication that anyone compiled with either of these
   versions is consistent with the new object module. This will take a very
   minor change in GNAT itself to accomodate the multiple time stamps.

   Obviously implementing a comprehensive tool of this type is a huge
   undertaking, but a simple tool that just took care of some of the most
   common cases would be very useful and would take care of many of the common
   cases of the existing "-o" usage without sacrificing safety. Can this
   behavior be reconciled with the 83 or 9X RM chapter 10? We are not quite
   sure and it really doesn't matter that much, since of course it's only an
   option!

   Going on to more ambitious thinking, Cyrille Comar, a new member of the
   GNAT group, has been investigating the general issues of specification of
   minimal required interfaces in the GNAT context. The general idea is that
   when you with a spec, you don't use all of it, and you really only need to
   be recompiled if the part of the spec you use is modified. This is the
   kind of approach used by the smart recompilation approaches of Dec and
   Rational (is that a Dec trademark? if so, please consider it labeled as
   such!) Although we don't anticipate actually implementing such an approach
   in the immediate future, we want to be sure that nothing in our approach
   precludes it. We'll be distributing a GNAT note on this subject later on!