assign help!!

assign help!!

[Ivan Gou]

This is very important to me, is any master-hand can help me?
If you can help, please email me the above email address, thanks.
This is the wrire_page part of the program, I have done so far:

procedure write_page(page: in out page_type;
                      line: in out text_line;
                      next_line: in out text_line) is

-- Writes out one full page of text.

begin -- write_page
  --** Reset the page
   for i in 1..page_length loop
      for j in 1..col_num loop
          line:= ret_line(page(current_col));
          next_line:= ret_line(page(current_col));
        for k in 1..col_width loop
           put(line.buffer(k));  -- line 208 is here, what shall I put instead
of 'line'?
        end loop;
      end loop;
    end loop;

   new_line;
   page_num := page_num + 1;
   for count in 1..(col_width * col_num /2) loop
      put(space);
   end loop;
   put("page "); put(page_num,2);
   new_line; new_line; 
end write_page;

I have error in:

typeset.adb:208:16: invalid prefix in selected component "line"
typeset.adb:236:10: missing argument for parameter "line" in call to
"write_page"

You can ignore line 236 

Re: assign help!!

[Michael F Brenner]

    > This is very important to me, is any master-hand can help me?
    > If you can help, please email me the above email address, thanks.
    > This is the wrire_page part of the program, I have done so far:

I am a master-hand, and a world-class Ada programmer, however I cannot
help for the following reasons:
   (1) This submission did not include the definitions of the types
       which it references: page_type, text_line, etc.
   (2) This submission did not include the definitions of the objects
       which it uses: page_length, col_num, current_col, col_width,
       buffer, page_num, space, line, etc.
   (3) This submission did not include the definitions of the methods
       which it invokes: ret_line, page, put, new_line, etc.
   (4) The above missing specifications, definitions, and elaborations
       make the program snippet ambiguous and therefore there are more
       than one correct answers to the question.

It would have been fun to help, but without the parts, the whole is missing.
This is very disappointing that the components are missing, because
bemoaning the vagaries and bugs in the text_io design are a necessary
step in the evolution of Ada programmers, many of whom are introduced
to hacking (the next step above software engineering) by these very bugs!

To start with, I advise the following:
   (A) make all of the type names plural English noun phrases, i.e.
       change page_type to pages, text_line to text_lines, 
       natural to columns, natural to rows, etc. (This will make
       better use of the type checking facility, but more diagnostic
       messages will reveal the rest of the bugs, and your program 
       will be more readable AS AN ENGLISH SENTENCE. That way you
       will avoid personal preferences for schemes that
       capitalize anything except the first letter of computer program
       and acroynyms.);

   (B) add the preconditions (e.g. after line 206 add the assertion
       <assert (col_width = 0)> to identify when the program works,
       by giving (preferably) executable conditions which are True
       at THIS point in the code);

   (C) add the postconditions (e.g. after line 209 add the comment
       <-- line (1..k) has been sent to the correct URL> so the
       reader of the code knows what has been accomplished, that is,
       what is True at THIS point in the code;

   (D) add the invariant conditions (e.g. after line 207 add the comment
       <-- There are col_width+1-k characters left of the slice line (1..k)>
       so the reader of the code knows that the loop is progressing
       and will actually terminate, because, for air conditioning
       purposes, the person running this program at the supercomputer
       lab has to be locked into the computer room with the source code
       diskette, and it gets very uncomfortable in their when a loop
       fails to terminate;

   (E) after doing the above, and providing the missing component
       definitions, and fixing the diagnostic messages which arise
       from introducing the assertions, comments, and strong typing,
       then resubmit the question and better advice can then be given
       that is more directly helpful to finding the exact path,
       rather than advice that just bullies the asker into facing the
       correct half of the compass, lost in the wide boulevard of
       errors contained in this programming snippet;

   (F) enjoy the process of creating programs with complex logic, and
       enjoy the process of simplifying that logic using the strong
       typing of Ada and the assertions (preconditions, postconditions,
       and invariant conditions) of the Ada methodology.  

Re: assign help!!

[Charles H. Sampson]

In article <5kn8ko$jcc@top.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>
>           ... I advise the following:
>   (A) make all of the type names plural English noun phrases, i.e.
>       change page_type to pages, text_line to text_lines, 
>       natural to columns, natural to rows, etc. (This will make
>       better use of the type checking facility, but more diagnostic
>       messages will reveal the rest of the bugs, and your program 
>       will be more readable AS AN ENGLISH SENTENCE. That way you
>       will avoid personal preferences for schemes that
>       capitalize anything except the first letter of computer program
>       and acroynyms.);

     This has nothing to do with the original poster's issue, but I 
have to disagree with you on this naming convention.  I much prefer the 
one advocated by Ada Quality and Style: Type names should be general 
singular nouns and object names should be specific singular nouns, ex-
cept for predicates as the names for boolean objects.  (I don't just 
prefer it.  I had some influence on its being in AQ&S that way.)  The 
reason is that your program will be more readable AS AN ENGLISH SEN-
TENCE.  For example

                       Error_Count : Natural;

can be read as "Error_Count is a natural number".  It could even be read 
as "Error_Count: Natural".  Notice also, as the rationale to the naming 
section of AQ&S says, it's Integer, Boolean, and Character, not Inte-
gers, Booleans, and Characters.

				Charlie
--
******

    If my user name appears as "csampson", remove the 'c' to get my
correct e-mail address.

Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Charles H. Sampson wrote:
> 
> In article <5kn8ko$jcc@top.mitre.org>,
> Michael F Brenner <mfb@mbunix.mitre.org> wrote:
> >
> >           ... I advise the following:
> >   (A) make all of the type names plural English noun phrases, i.e.
> >       change page_type to pages, text_line to text_lines,
> >       natural to columns, natural to rows, etc. (This will make
> >       better use of the type checking facility, but more diagnostic
> >       messages will reveal the rest of the bugs, and your program
> >       will be more readable AS AN ENGLISH SENTENCE.
[snip]
>      This has nothing to do with the original poster's issue, but I
> have to disagree with you on this naming convention.  

I agree with Charles, in that I disagree :-) with Michael's particular
choice of a naming convention.  However, I also disagree :-) with
Charles' naming convention, see below...

"Readability AS an English sentence" is not a very well-defined or
well-bounded goal (although it is a worthy one, and I do applaud the
sentiment behind it). Trying to get a programming language to mimic any
natural language, and yet still fulfill its purpose to unambiguously
specify programs, is a very hard problem (probably NP complete :-).
English is particularly hard, because it is so fluid and flexible and
ambiguous that almost any sequence of words could be interpreted as a
sentence (given a certain poetic frame of mind).

Yes, a naming convention for programming shouldn't gratuitously diverge
from standard usage of English (or whatever your natural language
happens to be).  (4 instnc, IMHO, rsortng to ad hoc abrvtns z defntly
bad 4m!) But, to be useful, a naming convention should be unambiguous,
prosaic, and systematic -- in fact it should be downright mechanical! By
this I mean that it should consists of simple, unambiguous rules, which
(1) a program author could apply, with very little mental effort, to
generate all the identifiers needed; and which (2) the readers of a
program could apply, with very little mental effort, to instantly
comprehend what those identifiers stand for.  The more mechanical the
rules, the better -- NOT because we're trying to take away from a
programmer's "creativity".  If anything, a mechanical naming convention
can _liberate_ programmers so they can spend their energies applying
their "creativity" to other more important goals -- like, actually
writing programs that work! :-)

A naming convention also ought to be "semantically economical." By this
I mean that, once a programmer has come up with a word describing a
certain concept in the target application (for instance, the name of a
class of objects), he shouldn't be force to invent a _different_ word to
represent the same concept -- in fact, doing so just serves to confuse
the readers.
  
Yet in Ada95, the same concept often must be mapped to several program
entities, and they can't all get the same identifier: For example, let's
say in our warfighting application domain we have a notion of a class of
"Target" objects.  An Ada95 programmer will tend to want to use "Target"
as the name of a type, _and_ as the name of an object (variable,
constant, parameter, record component) of that type, _and_ as the name
of a function that returns a value of that type, _and_ as the name of
the package that encapsulates the type and its primitive operations. But
obviously something has to give here. (A similar problem arises in most
other languages, too.)

The only way to meet the goal of being "semantically economical" is to
find some simple scheme for taking the basic name of your concept and
"marking" it in some systematic way, to generate a family of derived
identifiers. (More on this in a moment...)

> I much prefer the
> one advocated by Ada Quality and Style: Type names should be general
> singular nouns and object names should be specific singular nouns,
[snip]
> (I don't just
> prefer it.  I had some influence on its being in AQ&S that way.)  

Oh, so you're the one ... :-)

Seriously, I once was an staunch advocate of this very approach, but I
have since come to find it unwieldy and impractical. By the criteria I
described above, it fails miserably: The distinction between "general"
and "specific" nouns is quite ambiguous and subjective, depending on
context and point of view. It may take a lot of effort and hours spent
poring over Roget's Thesaurus hunting for synonyms, and then more
agonized hours deciding  which synonym is more "general" and which more
"specific". And for what? A percentage of your readers would've made the
opposite decision you made, so where does that leave readability?

Add to that the challenges of object-oriented programming, where you
have "specific" subclasses inheriting from "general" subclasses.  Would
"specific" noun phrases like "Enemy_Target" and "Friendly_Target"
represent _objects_ of type "Target", or would they be _types_ derived
from "Target"?

The only way I could find to hammer this into something even remotely
approaching a systematic scheme was to follow Grady Booch's lead, and
distinguish "definite" versus "indefinite" noun phrases.  An unmarked
noun such as "Target" is an "indefinite" noun phrase in English -- it
does not refer to any specific instance of the concept.  So that seemed
appropriate as the name of a type.

A "definite" noun phrase seemed appropriate as the name for a specific 
instance.  To form a "definite" noun phrase, you have to add some
"definite" adjective to the base noun, e.g.: 

	The_Target  : Target;
        This_Target : Target;
        That_Target : Target;

and so forth.  In fact, I used to resort to tacking "The" onto most
every object name, as a sort of universal default marker for
"objectness."  (I made a distinction for record components: Since they
"belong" to their record, I used the possessive "Its" instead of "The".
For instance you'd get things like:
"The_Target.Its_Location.Its_Latitude".)  I used to push this scheme
quite vehemently.

However, the trouble with this approach is that it favors short type
names at the expense of longer object names. Yet object names ought to
be shorter, because they are referenced more often, in contexts that are
more demanding on line-length (e.g., statements and expressions).
Whereas types are used in contexts where you have more leeway to be
verbose (e.g., in object declarations and parameter profiles).

I have now come around to accept Norman Cohen's approach: An unmarked
noun should be reserved for an object, e.g.:
"Target.Location.Latitude".  The name of the type should be the one that
gets marked, and what better universal marker for "typeness" than
"_Type"?  e.g.:

	Target   : Target_Type;
	Location : Location_Type;
	Latitude : Latitude_Type;

Before you all shudder at this, let me point out that this is just as
readable "AS English" as anything else: I can read this off as "Target
is an object of Target_Type",etc. (No, you're right, I don't win any
points here, since as I argued above, _anything_ could be read off as
English -- but at least I don't lose any points, either.)

You can still tack modifiers onto your object names to distinguish them
from each other:

	Enemy_Target, Friendly_Target : Target_Type;

but now there's no ambiguity about whether those modifiers mark the
identifiers as object names versus type names.  If you did need to have
more "specific" type names, you'd still use the same "type-marker":

	type Enemy_Target_Type    is new Target_Type with ...
	type Friendly_Target_Type is new Target_Type with ...

	Enemy_Target    : Enemy_Target_Type;
	Friendly_Target : Friendly_Target_Type;

This scheme is quick, painless and "semantically economical." We can get
past naming questions and get on with the business of programming.

> The
> reason is that your program will be more readable AS AN ENGLISH SEN-
> TENCE.  For example
> 
>                        Error_Count : Natural;
> 
> can be read as "Error_Count is a natural number".  It could even be read
> as "Error_Count: Natural".  

What about:

	type Error_Count_Type is range 0 .. Error_Limit;
        -- i.e., don't resort to using a predefined integer type
        -- if you can avoid it...

        Error_Count : Error_Count_Type;

I only wish the original designers of Ada83 had clued into this style
from the start.  I find myself wishing Ada95 looked more like this:

    Integer   : Integer_Type;
    Natural   : Natural_Type;
    Float     : Float_Type;
    Boolean   : Boolean_Type;
    Character : Character_Type;
    String    : String_Type;
    Duration  : Duration_Type;
    ...

    
    generic
      type Object_Type (<>) is limited private; -- vs. "Object"
      type Pointer_Type is access Object_Type;  -- vs. "Name"
    procedure Ada.Unchecked_Deallocation
      (Pointer : in out Pointer_Type); -- vs. "X"

    ...
    procedure Deallocate is new Ada.Unchecked_Deallocation
      (Object_Type         => Target_Type,
       Object_Pointer_Type => Target_Pointer_Type);
    -- instantiations are more understandable this way, because
    -- you can tell at a glance that these parameters are types,
    -- and not, say, objects or subprograms

    ... 
    Target_Pointer : Target_Pointer_Type := new Target_Type;
    ...
    Deallocate (Pointer => Target_Pointer);

    ...
    package Ada.Exceptions is
      ...
      type Exception_Identity_Type is ... -- vs. "Exception_Identity"
      ...
      procedure Raise_Exception
        (Exception_Identity : in Exception_Identity_Type; -- vs. "E"
         Message_String     : in String_Type := "");      -- vs.
"Message"
      ...
    end Ada.Exceptions;

    ...
    Target_Error : exception;
    Target_Not_Found_String : constant String_Type :=
      "Selected target not found.";
    ...
    Ada.Exceptions.Raise_Exception
      (Exception_Identity => Target_Error'Identity,
       Message_String     => Target_Not_Found_String);

Alas, alas, what might have been ... :-)

> Notice also, as the rationale to the naming
> section of AQ&S says, it's Integer, Boolean, and Character, not Inte-
> gers, Booleans, and Characters.

Well, I agree with Charles that you should stick to the singular when
naming objects and their types. You can look at a type declaration as a
description of a "single" thing, but at an abstract level: "This isn't
any particular object, but this is what any given object of this type
would look like."

What still remains, however, is what to do about packages.  Here again,
I've come to adopt Norman Cohen's scheme: Use the plural for a package
name. E.g.:

    package Targets is

      type Target_Type is ...

      procedure Blow_Up (Target : in out Target_Type);
      ...

The plural makes sense for a package name, because a package is a
logical grouping of related declarations -- a package, if you will, is
"about" a topic. Topics are often discussed in the plural: "This package
is about "targets" -- how you declare them, and what operations you can
do with them."

The plural form in English is usually very close to the length of the
singular, which is good because package names will be referenced
frequently (if you avoid "use" clauses).  Usually an English plural is
just one character longer than the singular ("Target" vs "Targets"), or
two characters longer ("Company" vs "Companies"), or occasionally
shorter (!) though these are for words derived from Latin ("Datum" vs.
"Data") or Greek ("Phenomenon" vs. "Phenomena"). (For cases like "Fish"
vs. "Fish", "Moose" vs. "Moose", "Deer" vs. "Deer", etc., that problem
will have to be solved by the legions of engineers developing real-time
embedded code for the Department of the Interior, the Nature
Conservancy, and Greenpeace ... ;-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Kevin Cline]

"John G. Volan" <johnvolan@sprintmail.com> wrote:
>Charles H. Sampson wrote:
>
>I have now come around to accept Norman Cohen's approach: An unmarked
>noun should be reserved for an object, e.g.:
>"Target.Location.Latitude".  The name of the type should be the one that
>gets marked, and what better universal marker for "typeness" than
>"_Type"?  e.g.:
>
>	Target   : Target_Type;
>	Location : Location_Type;
>	Latitude : Latitude_Type;
>

Absolutely agree.  After I switched from C to Ada, and could no longer use
case to distinguish between instances and types, I looked at a lot of code,
including Booch's original Ada components, before settling on the _type
suffix, for all of the reasons Charles gave.  Reading code like:

    The_Node.Left := Into_The_Tree.Root 

gave me a headache.

It's hard to solve this problem in any way similar to natural language because
natural languages (at least all the ones that I'm familiar with) use the same
word for both a category and an instance of the category, relying on the
context to disambiguate.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Kevin Cline wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> wrote:
>
> >I have now come around to accept Norman Cohen's approach: An unmarked
> >noun should be reserved for an object, e.g.:
> >"Target.Location.Latitude".  The name of the type should be the one that
> >gets marked, and what better universal marker for "typeness" than
> >"_Type"?  e.g.:
> >
> >       Target   : Target_Type;
> >       Location : Location_Type;
> >       Latitude : Latitude_Type;
> >
> 
> Absolutely agree.  After I switched from C to Ada, and could no longer use
> case to distinguish between instances and types, I looked at a lot of code,
> including Booch's original Ada components, before settling on the _type
> suffix, for all of the reasons Charles gave.

Point of order: It wasn't Charles who said that, its was me. (It was I?)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Jay Martin]

"John G. Volan" <johnvolan@sprintmail.com> writes:
...
>I only wish the original designers of Ada83 had clued into this style
>from the start.  I find myself wishing Ada95 looked more like this:

>    Integer   : Integer_Type;
>    Natural   : Natural_Type;
>    Float     : Float_Type;
>    Boolean   : Boolean_Type;
>    Character : Character_Type;
>    String    : String_Type;
>    Duration  : Duration_Type;
>    ...

Two thumbs up!

In fact wouldn't be cool if Ada forced all types to have "_Type" suffixes.
Heh probably make those C hackers blood boil.

Jay

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Jay Martin wrote:

> In fact wouldn't be cool if Ada forced all types to have "_Type" suffixes.

I take it this was suggested tongue-in-cheek, but actually it wouldn't
be so hard to get a compiler to do that, if you really wanted to. GNAT
for instance already includes the capability to do some style checking.
Take a look at the -gnatr and -gnatg switches.

> Heh probably make those C hackers blood boil.

What do you mean?  Would they be jealous that we could enforce a nice
readable style when they couldn't, or would they incensed that we'd
_dare_ to enforce a nice readable style when they _know_ the whole point
behind computers is to be as creatively cryptic and as anarchically
obfuscated as possible so as to overthrow any vestige of authority and
establish themselves as a guru priesthood (bow three times toward
Redmond) selling row after row of slick ten-pound glossy-covered how-to
books to the masses of glazed-eyed zombie Internet lemmings?

:-) :-) :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Jeff Carter]

Jay Martin wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> ...
> >I only wish the original designers of Ada83 had clued into this style
> >from the start.  I find myself wishing Ada95 looked more like this:
> 
> >    Integer   : Integer_Type;
> >    Natural   : Natural_Type;
> >    Float     : Float_Type;
> >    Boolean   : Boolean_Type;
> >    Character : Character_Type;
> >    String    : String_Type;
> >    Duration  : Duration_Type;
> >    ...
> 
> Two thumbs up!
> 
> In fact wouldn't be cool if Ada forced all types to have "_Type" suffixes.
> Heh probably make those C hackers blood boil.
> 
> Jay

According to my religion, you guys are heretics. I will give the command
to my followers that you should be killed on sight. Now, if I only had
some followers ...

The problem with putting _Type on the end of all [sub]type names is that
it adds no information. Almost all uses of type names make it obvious
that the name is a type. So all you're doing is putting something on the
end to have a different name for the type, and preserve the name for use
by an object or, more typically, a subprogram parameter. So why not use
the shortest possible suffix, 2 characters: _T? Because it's ugly. But
it wastes fewer characters than the equally ugly _Type.

The only advantage of this approach is that it's a suffix, which is much
better than a prefix. In distinguishing two words, the initial
characters are the most important. Two words that are the same in the
initial characters and differ only in the later characters are more
likely to be confused than two words that differ in the first character.
Thus, the Booch school of prefixing all objects and parameters with The_
is an abomination.

Now, allow me to indoctrinate you into the one true religion. Like you,
I want to preserve the meaningful name (List, Queue, What_Ever) for use
by objects and parameters. Unlike you, I insist that suffixes add at
least some information. So I want my suffix to indicate what kind of
type we're dealing with, as well as differentiating the type name. I use
many; here are a few:

Numeric types: _Value, _Count, _Range

Enumeration types: _Id, _Name

Array types: _Set, _List

Record types: _Group, _Data, _Info

Task types: _Agent, _Controller

Private types: _Handle

I'm also creative in my use of parameter names, using Into, Before,
After, From, To, and so on to avoid as much of this as I can:

procedure Insert (Into : in out String; Before : in Positive; Value : in
String);

procedure Append (Onto : in out List_Handle; After : in Position; Item :
in Element);

However, List_Handle is probably a protected type, so instead we can
write

List.Append (After : in Position, Item : in Element);

Continue in your heresy, and we will burn you alive. Convert, and we
will merely behead you.

Ha! Nobody expects the Sappish Inquisition!
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Jeff Carter wrote:

> According to my religion, you guys are heretics. I will give the command
> to my followers that you should be killed on sight. Now, if I only had
> some followers ...
...
> Continue in your heresy, and we will burn you alive. Convert, and we
> will merely behead you.

By the way, ya oughtta _smile_ when ya say that, pardner.

Or at least, smiley...  :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Jeff Carter wrote:

> The problem with putting _Type on the end of all [sub]type names is that
> it adds no information.

But that's the whole point! Adding any more information is _undesirable_
at this point, because presumably an object and its type _both_
represent the _same_ concept The scheme I described attempts to be
"semantically economical." If the programmer already has a good word or
phrase that describes a concept, then he shouldn't have to waste mental
energy just to find some modifier that adds some extra shading to the
idea, just to generate a different identifier.  Generating the different
identifier should be mechanical.

> Almost all uses of type names make it obvious
> that the name is a type. So all you're doing is putting something on the
> end to have a different name for the type, and preserve the name for use
> by an object or, more typically, a subprogram parameter. 

Exactly!  All that we _need_ here is to be able to generate a different
identifier. We _don't_ need that identifier to add any new information
-- because there really isn't any new information! (See below...)

> So why not use
> the shortest possible suffix, 2 characters: _T? Because it's ugly. 

No, it's because "T" is not an English word, it's an ad hoc
abbreviation. The goal of finding a mechanical naming convention would
actually be satisfied by this suggestion, but it would not satisfy an
orthogonal goal: keeping as much as possible to standard English usage.
 
> But
> it wastes fewer characters than the equally ugly _Type.

"Ugly" is in the eye of the beholder -- "beauty" tends to be whatever
you've gotten used to.  I used to be just as religious as you in
rejecting this kind of suffix as "ugly". But now that I've seen how
_practical_ and _useful_ it is to keep to a simple scheme like this,
I've come to view it as quite elegant. Funny how one's tastes mellow out
with age... :-)

> Now, allow me to indoctrinate you into the one true religion. Like you,
> I want to preserve the meaningful name (List, Queue, What_Ever) for use
> by objects and parameters. Unlike you, I insist that suffixes add at
> least some information. So I want my suffix to indicate what kind of
> type we're dealing with, as well as differentiating the type name. 

I've actually toyed with this possibility, but I've come to the
conclusion that it's a bad idea.

First of all, it complicates the rules for a naming convention, which
adds to the mental work load for both the author and the readers. 
Everyone would need a scorecard just to keep track of what words are
type-marking suffixes and what suffixes need to be used when.  In a
group project, you wind up getting different people deciding they like a
different subset of the suffixes, so readability deteriorates because of
a lack of consistency.  A minimal solution is mor economical: Just say
that all types will be marked in the same mannter.

(By the way, we can level a similar criticism against the AQ&S guide's
"general" vs. "specific" noun phrase scheme:  There are just too many
different adjectives in English that can confer "specificness" to a noun
phrase, and it's a waste of effort having to sort them all out.  You
wind up concluding, as I did, that it's better to just settle on one
universal "objectness" marker ("The_") and be done with it.  But then
you need to take a step back and ask whether it's more practical to mark
all the _objects_, or all the _types_ instead.  My conclusion was that
it's better to mark all the types.)

The other problem I have with your scheme is that, if there _is_ some
"extra information" that seems worthwhile to add to a name, then why
only add it to the _type_ name? Why not add it to the _object_ names
too?  E.g., if you like to add "_Count" onto an integer type, it
probably indicates something about the purpose of that integer type: It
"counts" quantities of some kind of item, rather than, say,
"identifying" individual items (which is another purpose integer types
can serve).  But if that fact is really important to your application,
then it's really an inseparable part of the "base noun phrase" for your
concept, and it should go onto the object names too:

    type Error_Count_Type is range 0 .. Error_Limit;
    ...
    Error_Count : Error_Count_Type; -- counts errors flagged so far

versus

    type Error_Ident_Type is range Minimum_Error_Ident ..
Maximum_Error_Ident;
    ...
    Error_Ident : Error_Ident_Type; -- identifies the last error flagged

But, as you can see, you're still faced with the problem of generating a
different identifier for the type.

IMHO, if you can't justify tacking a suffix onto an object name, then it
really doesn't add any useful information. Appending it onto the type
name just wastes energy and adds confusion.  If the only purpose it
serves is to differentiate the type, a universal type marker would have
been a simpler solution.

That being said, I can understand how under some circumstances you might
find it important to mark what _kind_ of type you're dealing with. (I
might not agree, but I can understand it.) But if that's really
important enough to do, then it ought to be equally important not only
on the type name but on the object names too!

For instance, a separate problem is what to do about naming a designated
type and an associated access type. In this case, marking the access
type as a "Pointer" type is useful:

    type Target_Type is tagged ...
    type Target_Pointer_Type is access all Target_Type'Class;

    Target : Target_Type;
    Target_Pointer : Target_Pointer_Type := new Target_Type;

But once again, I'd want the rule to be simple and minimalistic: Just
always mark access types (and access objects) with "_Pointer".

> I use
> many; here are a few:

TOO many, IMHO. But if they're good for the type, they're good for the
objects:

> Numeric types: _Value, _Count, _Range
>
> Enumeration types: _Id, _Name
> 
> Array types: _Set, _List

I'd only call an array a "Set" or a "List" if it really implemented the
semantics of a "Set" or a "List".  But this implies that the array type
is just the completion of some private type with subprograms that
support the ADT in question, and the fact that it's really an array is
just an implementation detail.

But if this is _not_ the case, and you actually have an array type that
is publicly _visible_ as an array type, then saying it's something else
is misleading.  I'd just say:

   type Target_Array_Type is array (Target_Index_Type range <>) of
Target_Type;
   ...
   Target_Array : Target_Array_Type;

> Record types: _Group, _Data, _Info
> 
> Task types: _Agent, _Controller
>
> Private types: _Handle

"Handle"?  Huh?  What information does _that_ add?  _Every_ data type in
Ada95 "handles" _some_ kind of data...

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

In my programming the name clash that I most often come across is something
like

    Parent : constant xxx := Parent (K);

now of course I don't want to use the same name in both places here, and
I have not really settled on a convention. I don't like The_Parent, because
I find The_ too much noise. Often I use an abbreviation if the scope is
very small, something like

   Parnt : constant xxx := Parent (K);

I know that some coders and some coding standards are allergic to
abbreviations, but I don't mind short identifiers and abbreviations if
they have a small local scope.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert Dewar wrote:
> 
> In my programming the name clash that I most often come across is something
> like
> 
>     Parent : constant xxx := Parent (K);

Just out of curiosity, what is "K"?  "Key"?  "Kid"?  "Kludge"?  :-)

> now of course I don't want to use the same name in both places here, and
> I have not really settled on a convention. I don't like The_Parent, because
> I find The_ too much noise.

I used to be of the school of thought that a function name should be a
noun phrase (possibly including the name of the type being returned,
although this need not be rigorous).  But one inevitably bumps into this
very name clash: The tendency is to want to use the same noun for the
object receiving the result of the function.

My conclusion was to give up on trying to use pure noun phrases for
function names, and instead find a way to mark the function names. 
Booch seems to prefer using a dangling preposition that leads into the
parameters:

   function Parent_Of (Child : in Pointer_Type) return Pointer_Type;
   ...
   Parent : Pointer_Type := Parent_Of(Child);

But I've found this to be awkward sometimes, particularly when the
function has more than one parameter.  Is it necessarily the first
parameter that is the object of the preposition?  Sometimes the most
natural prepositional phrase in English wants a "secondary" parameter as
its prepositional object and not the "primary" (i.e. controlling)
parameter of the function, so you're forced into contortions just to
satisfy English.

An alternative that I've personally settled on is to give up on the
distinction between functions and procedures, and to simply use verb
phrases for all subprogram names.  This emphasizes to the reader that
there is always _something_ happening when you make a subprogram call,
and the programmer should keep in mind the cost of making the call. 
Even when it's a function without side effects, there is the cost of
whatever calculation or retrieval it's performing. And even if that cost
is inlined and optimized away, there is at least a hypothetical cost --
which might not be so hypothetical if there is a design change during
maintenance and the function must be implemented differently.

If no particular verb comes to mind, a function could just tack on
"Get_" as a default:

   function Get_Parent
     (Child : in Pointer_Type) return Pointer_Type;

   procedure Set_Parent
     (Child : in out Pointer_Type; Parent : in Pointer_Type);
   ...
   Parent : Pointer_Type := Get_Parent(Child);

Note that there is a nice symmetry between a procedure that sets a value
and a function that gets it.  This convention has some precedents in the
naming styles I've seen in code written in other languages, and I see no
reason to denigrate this.

> Often I use an abbreviation if the scope is
> very small, something like
> 
>    Parnt : constant xxx := Parent (K);
> 
> I know that some coders and some coding standards are allergic to
> abbreviations, but I don't mind short identifiers and abbreviations if
> they have a small local scope.

It's against my religion to give up on the "Thou shalt not abbreviate"
commandment so easily.  :-)  Where do you draw the line on what counts
as a "small" scope?  Small scopes can have a nasty tendency to grow with
time.

I mean, it's sort of like saying that it's bad to beat up somebody on a
crowded street, but it's okay to beat up your spouse as long as you do
it in the privacy of your own home... hmm, I was going to put a smiley
in there, but that's just not funny.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

John asks

<<Robert Dewar wrote:
  >
  > In my programming the name clash that I most often come across is something
  > like
  >
  >     Parent : constant xxx := Parent (K);
  
  Just out of curiosity, what is "K"?  "Key"?  "Kid"?  "Kludge"?  :-)>>

K is just an abbreviation for some expression which is not important
in this example.

<<It's against my religion to give up on the "Thou shalt not abbreviate"
  commandment so easily.  :-)  Where do you draw the line on what counts
  as a "small" scope?  Small scopes can have a nasty tendency to grow with
  time.>>

I notice again you using the term religeon. I strongly advise an agnostic
viewpoint when it comes to programming. Religeously inspired rules and
views tend to be a menace when it comes to programming style. I understand
the comfort of letting rules substitute for judgment, but I think it is a
bad idea to have any absolute rules (except this self referential one :-)

<<If no particular verb comes to mind, a function could just tack on
  "Get_" as a default:

     function Get_Parent
       (Child : in Pointer_Type) return Pointer_Type;

     procedure Set_Parent
       (Child : in out Pointer_Type; Parent : in Pointer_Type);
     ...>>

Well as you know well if you have looked at the GNAT sources, the
Get_ and Set_ prefixes are extensively used, but again, I think it
is a mistake to take a religeously consistent view here. The
fundamental tree walking functions Next, Prev, and Parent are
used *so* extensively that choosing any other names for them
would add unnecessary obfuscatory expansion to the code.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert Dewar wrote:
> 
> John asks
> 
> <<It's against my religion to give up on the "Thou shalt not abbreviate"
>   commandment so easily.  :-)
> 
> I notice again you using the term religeon. I strongly advise an agnostic
> viewpoint when it comes to programming. Religeously inspired rules and
> views tend to be a menace when it comes to programming style. 

You of course noted my smiley there, right? ... :-)  I knew this
discussion would arouse some strong emotions and challenge some
cherished habits, so I deliberately sought to defuse the situation in
advance with a bit of humor in the subject line...

> I understand
> the comfort of letting rules substitute for judgment, but I think it is a
> bad idea to have any absolute rules (except this self referential one :-)

Every rule has a domain of applicability, beyond which it becomes
oppressive. But within its domain of applicability, I do not see why it
should not be absolute.  Rigor can reap great benefits.  The exercise of
applying a rule rigorously can sometimes, just by itself, crystallize a
person's thinking and reveal flaws in a design.

Where judgment should come into play is knowing where the bounds of a
rule's domain extend. In this discussion, I have been trying to push the
bounds outward a bit, to challenge what I perceive as loose thinking. 
Perhaps in some cases the bounds have been stretched too far and must be
pulled back. If so, it is not going to be satisfying to me if the
rationale for tightening the bounds is simply "we're not used to it" or
"just doesn't _feel_ right."  It is much more satisfying to me if the
rationale is based on some higher order rule freshly discovered, leading
to even greater comprehension.

As for comfort, comfort was not one of my primary goals in devising a
naming convention.  Reducing the mental workload for the author and the
readers was.  Simple rules rigorously applied can eliminate unnecessary
work at a lower level and leave energy available for higher-order
problems.

Also, I believe keeping to Engish reduces work in the long run.  I cling
to English words wherever I can simply because of English's universal
utility: English is the one constant I can guarantee that all readers
will be immediately familiar with, at all times, in all contexts. 
(That's not jingoism, it's just reality: for better or worse, this is an
Engish-speaking world.)

> Well as you know well if you have looked at the GNAT sources, the
> Get_ and Set_ prefixes are extensively used, 

Haven't looked, not recently anyway. But "Get_" and "Set_" have ample
precedent elsewhere.

> but again, I think it
> is a mistake to take a religeously consistent view here. 

Again, it's not religion, but rather a drive for rigor.

> The
> fundamental tree walking functions Next, Prev, and Parent are
> used *so* extensively that choosing any other names for them
> would add unnecessary obfuscatory expansion to the code.

I do not dispute your choice to reserve simple unmarked words for use in
naming these functions, but it does mean that those identifiers become
unavailable for the recipient objects.  The latter must then be marked
in some way.  That's an acceptable trade-off.  I'm just a bit
disappointed that the way you chose to mark them involved devising ad
hoc abbreviations on the spot.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert I. Eachus]

In article <dewar.863324701@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

   Robert Dewar said:

   > In my programming the name clash that I most often come across
   > is something like
   >     Parent : constant xxx := Parent (K);

   My reaction in those cases is to diagnose a misplaced use clause,
and use the package name:

   Parent : constant xxx := My_List_Instance.Parent (K);

   If this is not sufficient, you have a deeper design problem. It may
be possible to call a function in the scope in which it is defined
without ABE in this case in Ada 95:

   function Parent(Foo: Bar) return xxx is... end Parent;

   Parent: constant xxx := My_List_Instance.Parent (K);

   ...but most such cases are very suspicious.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert I. Eachus wrote:
> 
> In article <dewar.863324701@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
>    Robert Dewar said:
> 
>    > In my programming the name clash that I most often come across
>    > is something like
>    >     Parent : constant xxx := Parent (K);
> 
>    My reaction in those cases is to diagnose a misplaced use clause,

That's not the only way this could happen. We might have a subsystem of
child packages.  A subprogram that has widespread utility within the
subsystem might be declared high up in a root package, and a code
snippet like this could be located down in a child package.  Visibility
to the contents of the root package comes for free, without any need for
a use-clause.  Would such an arrangement be "misplaced"?  I wouldn't
think so, I'd view it as a conscious design decision.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

iRobert Eachus says

<<   My reaction in those cases is to diagnose a misplaced use clause,
and use the package name:

   Parent : constant xxx := My_List_Instance.Parent (K);>>

Well you sure take a shaky place to make the no-use-clause stand. I find
it hard to imagine that anyone would think that it made the GNAT soures
clearer to do a global replace of Parent with Atree.Parent. Given that
the whole of GNAT is about tree processing, and the Parent function is
truly fundamental, this seems silly to me.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert I. Eachus]

In article <dewar.863496133@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

   (I said:)

   >>  My reaction in those cases is to diagnose a misplaced use clause,
   >> and use the package name:

   >>  Parent : constant xxx := My_List_Instance.Parent (K);>>

   RBKD said:

   > Well you sure take a shaky place to make the no-use-clause
   > stand. I find it hard to imagine that anyone would think that it
   > made the GNAT soures clearer to do a global replace of Parent
   > with Atree.Parent. Given that the whole of GNAT is about tree
   > processing, and the Parent function is truly fundamental, this
   > seems silly to me.

   I wasn't advocating elimination of use clauses, and I never have.
I tend to be a moderate on the subject.  (Look at my .sig file! ;-)
But in this case, there is a perfectly simple "fix" of the problem by
adding the needed qualification.  The reason for the reference to
misplaced use clauses was because I'll look there to see what the
right prefix is.

   Incidently, and here I am willing to be counted as an extremist,
often the right solution to use cause induced conflicts is to put the
use clauses where needed, rather than in the context clause.  If you
have 20 operations on an ADT, two of which use Text_IO, put a with
Text_IO in the context clause for the body, but put the use clauses in
the IO operations.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

Robert Eachus said

<<   Incidently, and here I am willing to be counted as an extremist,
often the right solution to use cause induced conflicts is to put the
use clauses where needed, rather than in the context clause.  If you
have 20 operations on an ADT, two of which use Text_IO, put a with
Text_IO in the context clause for the body, but put the use clauses in
the IO operations.>>


But you are talking in generalities, responding to my very specific
example. You cannot seriously be suggesting that in the GNAT sources,
for the hundreds, even thousands, of references to Parent, that we
put a use clause in for each of them, and anyway, I don't even see
that putting a use clause in is relevant in this case. Your only
proferred solution that seems to work is

    Parent : constant Node_Id := Nlists.Parent (Other_Node);

But I find the Nlists. here all over the place to be nasty noise, and of
course you cannot eliminate this Nlists. with a use clause, since then
you have the name conflict.

Please note that this is no big deal. Very often we are talking about
tiny routines where

   P : constant Node_Id := Parent (Other_Node);

is quite fine. As many people have noted, short variable names, even one
letter names, are quite fine if they are very local.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Kevin Cline]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>In my programming the name clash that I most often come across is something
>like
>
>    Parent : constant xxx := Parent (K);
>
>now of course I don't want to use the same name in both places here, and
>I have not really settled on a convention. I don't like The_Parent, because
>I find The_ too much noise. Often I use an abbreviation if the scope is
>very small, something like
>
>   Parnt : constant xxx := Parent (K);
>
>I know that some coders and some coding standards are allergic to
>abbreviations, but I don't mind short identifiers and abbreviations if
>they have a small local scope.
>

I think this is an important point.  For identifiers that have small scope,
almost any name will do if it has some mnemonic value.  Because I don't like
to even remember which abbreviation was chosen, I use single letter variable
names for temporaries in small functions whenever possible.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

<<I think this is an important point.  For identifiers that have small scope,
almost any name will do if it has some mnemonic value.  Because I don't like
to even remember which abbreviation was chosen, I use single letter variable
names for temporaries in small functions whenever possible.>>

For me that goes too far, I have seen far too much code with cryptic
one letter identifiers like D, where short names would have helped a 
lot (something like Depth). Interestingly, I note that this preference
for one letter identifiers often seems to go along with an allergy to
writing comments.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert Dewar wrote:
> 
> <<I think this is an important point.  For identifiers that have small scope,
> almost any name will do if it has some mnemonic value.  Because I don't like
> to even remember which abbreviation was chosen, I use single letter variable
> names for temporaries in small functions whenever possible.>>
> 
> For me that goes too far, I have seen far too much code with cryptic
> one letter identifiers like D, where short names would have helped a
> lot (something like Depth). Interestingly, I note that this preference
> for one letter identifiers often seems to go along with an allergy to
> writing comments.

Robert, can you see how your relaxed attitude towards small scopes can
be abused by other programmers, and lead us down this slippery slope?  I
have been trying to make a distinction between two different kinds of
abbreviations: (1) conventional abbreviations, which are established at
a project level, documented, and used consistently and universally; and
(2) ad hoc abbreviations, which are invented on the spot, idiosyncratic,
and inconsistent.  Often times, one engineer will choose one ad hoc
abbreviation and another will choose and entirely different one -- for
the same concept! Chaos!

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

John says

<<Robert, can you see how your relaxed attitude towards small scopes can
be abused by other programmers, and lead us down this slippery slope? >>

Indeed. Almost all my suggestions, and anyone else's for that matter can
be abused. My solution to that is not to imagine that abuse can be prevented
by over fanatic application of arbitrary rules, my solution is to get rid
of abusive programmers, either by removal or education!

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Wayne Magor]

clines@delete_this.airmail.net (Kevin Cline) writes:
>
>dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>>
>>I know that some coders and some coding standards are allergic to
>>abbreviations, but I don't mind short identifiers and abbreviations if
>>they have a small local scope.
>
>I think this is an important point.  For identifiers that have small scope,
>almost any name will do if it has some mnemonic value.  Because I don't like
>to even remember which abbreviation was chosen, I use single letter variable
>names for temporaries in small functions whenever possible.

Good point.  It is a matter of degree and scope.  Single letter variable
names are very appropriate in certain contexts.  For example, I use them
extensively as FOR loop variables, since it usually has no meaning other
than to count which iteration we are on.

Using long names too often can actually make code *harder* to read.  We
are already deluged with so many concepts, classes, and structures that
we don't need to clutter things by naming unimportant items.  The reader's
attention should be focused on what is important.  Those are what deserve
good (possibly long) names.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

Wayne says

<<Good point.  It is a matter of degree and scope.  Single letter variable
names are very appropriate in certain contexts.  For example, I use them
extensively as FOR loop variables, since it usually has no meaning other
than to count which iteration we are on.>>

Certainly that's reasonable for small loops. However in the GNAT style
standards, we do not permit the use of the variable I, since in a
sans-serif font, it is too easily mixed up with the digit 1. The single
letter O is a bad choice for similar reasons.

(amusing completely irrelevant anecdote. This morning I called up UA and
asked them to locate a record, I gave the locator as

Tango-Zero-Echo-Echo-Boy-Queen

The agent couldn't find it ...

she was looking for T0EEBQ

my locator was TZEEBQ

:-)

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Nick Roberts]

Are we avoiding 'Zulu' for P. C. reasons?

Nick ;-)

naming convention discussion

[Peter Hermann]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

> (amusing completely irrelevant anecdote. This morning I called up UA and
UA?
> asked them to locate a record, I gave the locator as

> Tango-Zero-Echo-Echo-Boy-Queen

> The agent couldn't find it ...

> she was looking for T0EEBQ

> my locator was TZEEBQ

> :-)

which is spelled: tango zulu echo echo bravo quebec
BTW: zero still keeps to be zero: she was correct   :-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Wayne Magor wrote:
> 
> We
> are already deluged with so many concepts, classes, and structures that
> we don't need to clutter things by naming unimportant items.  

This is a curious statement. There are very few things that can be
declared anonymously in Ada.  Generally, if you're declaring it, you
have to give it _some_ identifier.  How do you propose to get away with
_not_ naming something?  :-)

Well, if what you really meant was that you want to give some things
cryptic short names, in an effort to reduce the client's mental overload
in dealing with the complexity of your software, I'd say you're fooling
yourself -- at best, that's a bandaid approach to complexity.

If you want to reduce the number of details that a user has to
understand, use _abstraction_.  Wrap the darn thing in a package.  Wrap
the types up as private types.  Hide the more arcane details in the
body/private part.  Provide a streamlined interface.  Reduce coupling,
increase cohesion.

Yada, yada, yada... how often is this litany professed, yet never
_really_ understood, and carried out? :-)

> Using long names too often can actually make code *harder* to read.
...
> The reader's
> attention should be focused on what is important.  Those are what deserve
> good (possibly long) names.

Names don't have to be "long" to be "good."  The shorter the better, I
say -- within limits, and for me those limits are English.  There's an
art to picking short, but meaningful names. But there's still the
problem of distributing the same short meaningful name to several
program entities that all "want" that same name. Some kind of systematic
"noise" has to be attached to get different identifiers.

If you're saying that this "noise" should be shortened to the bare
minimum, at all costs, well okay, I'll buy that.  Maybe you'd prefer:

Project Convention: "_T" shall be the universal type-marking suffix

   type Target_T is ... 
   -- a "target" is the weapon system's hypothesis of some 
   -- real object flying out there
   procedure Create (Target : in out Target_T);
   procedure Assess_Threat (Target : in out Target_T);
   procedure Engage_Attack (Target : in out Target_T);
   ...

   type Track_T is ...
   -- a "track" is a sensor phenomenon; several tracks might be
   -- associated with the same hypothesized target
   procedure Create (Track : in out Track_T);
   procedure Update (Track : in out Track_T);

As opposed to the barbarous:

   type Target is ... 
   -- a "target" is the weapon system's hypothesis of some 
   -- real object flying out there
   procedure Create (Trg : in out Target); -- Abe wrote this
   procedure Assess_Threat (Targ : in out Target); -- Becky wrote this
   procedure Engage_Attack (Tgt : in out Target); -- Chris wrote that
   ...

   type Track is ...
   -- a "track" is a sensor phenomenon; several tracks might be
   -- associated with the same hypothesized target
   procedure Create (Trk : in out Track); -- Abe wrote this
   procedure Update (Trac : in out Track); -- Becky wrote that
   
Or the truly horrendous, but all too tempting:

   type Target is ... 
   -- a "target" is the weapon system's hypothesis of some 
   -- real object flying out there
   procedure Create (T : in out Target);
   procedure Assess_Threat (T : in out Target);
   procedure Engage_Attack (T : in out Target);
   ...

   type Track is ...
   -- a "track" is a sensor phenomenon; several tracks might be
   -- associated with the same hypothesized target
   procedure Create (T : in out Track);
   procedure Update (T : in out Track);

At what point will our pour befuddled maintenance engineer start
confusing "T" for a Track with "T" for a Target?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Ben Brosgol]

Robert Dewar wrote:
> 
> In my programming the name clash that I most often come across is something
> like
> 
>     Parent : constant xxx := Parent (K);
> 
> now of course I don't want to use the same name in both places here, and
> I have not really settled on a convention. I don't like The_Parent, because
> I find The_ too much noise. Often I use an abbreviation if the scope is
> very small, something like
> 
>    Parnt : constant xxx := Parent (K);

Here's a modest proposal for Ada 0Y that will solve this problem: allow
an identifier to include a single trailing underscore.  That way you
could write:

     Parent_ : constant xxx := Parent (K);

with a minimum of notational overhead.  

Too bad nobody thought of this idea for Ada 9X :-) :-)

Ben Brosgol
Aonix
brosgol@aonix.com

naming convention: trailing underscore

[Peter Hermann]

Ben Brosgol (brosgol@world.std.com) wrote:

: Here's a modest proposal for Ada 0Y that will solve this problem: allow

Do we all accept "Ada 0Y" as official project name for Ada 2007?

: an identifier to include a single trailing underscore.  That way you
: could write:

:      Parent_ : constant xxx := Parent (K);

I strongly disagree.
This topic has been discussed in leeength...

: Too bad nobody thought of this idea for Ada 9X :-) :-)

two smileys acknowledged

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: naming convention: trailing underscore

[John G. Volan]

Ben Brosgol (brosgol@world.std.com) wrote:
> 
> Here's a modest proposal for Ada 0Y that will solve this problem: allow
> an identifier to include a single trailing underscore.  That way you
> could write:
> 
>      Parent_ : constant xxx := Parent (K);

Gadzooks! Get thee behind me, Satan! :-) :-)

What were we saying about religion? :-) :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: naming convention: trailing underscore

[Michael F Brenner]

If we did, we would be giving bad example of how to handle the Year
2000 problem in all who saw it. Everyone knows that there was no
leap year in the year 0, but there is in the year 00. THerefore,
to prevent people from thinking that they will fix the problem by
keeping their two-digit years, we should write it out Ada-200x. 
Otherwise, people might think there was a data-overflow in Ada :).

naming convention discussion

[Peter Hermann]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

> But on the final vote, the French delegation in particular made a major
> issue of opposing this, and insisted on its deletion, so it was deleted.
> They felt it encouraged bad identifiers such as A__________________B,
> which is horrible, indeed, though not much worse than OOOOOOOOOOOOO0000OOOO
> and no one has yet proposed a rule to somehow eliminate the ability to
> write the latter (or for that matter a simple syntactic rule which would
> make it imopssible to choose bad identifier names :-)

"bad" is relative. We designed a finite element code (still running)
for computation of dynamical structural problems. The user of our system
could deliver fortran code fragments to be called by our system,
the so-called excitiation functions, subject to be frequently called
e.g. for math. integration, etc. .
This was accomplished by reading his statements and generating wrapping
fortran functions, compiling them, and binding them in the next major step
on OS-level, of course. The potential name clashes' problem was solved
by chosing unlikely names like O00O0O for real variables and I0OO0O for 
integer variables in the same scope of the users' variables.
The project part within the system was "O0NUFU" (numerical functions spoiled)
and the teamers still tease me for that name ;-)

-- I cannot accept any superfluous constraint upon the choice of names.
-- with excess experience on portability/maintenance/linkers/OSs in mind, 
   I am reluctant to allow trailing underscores in identifiers:
   They open several cans of worms.

BTW, the dynamic updating process of software upon a running process
should be emphasized in Ada200x (I have the Mars mission in mind), IMHO.

With Robert de War in mind, I am putting my flame suit on. :-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: naming convention discussion

[Robert Dewar]

Peter Herman said

<<   I am reluctant to allow trailing underscores in identifiers:
   They open several cans of worms.>>

(did you say this, I was a little unclear, it was indented like a quote,
but no signs of a quote>>

I don't understand what cans of worms would be opened by this feature ...

Re: naming convention discussion

[Peter Hermann]

> Peter Herman said

> I am reluctant to allow trailing underscores in identifiers:
> They open several cans of worms.

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
> I don't understand what cans of worms would be opened by this feature ...

Apart from the standard software as used by the majority, there happens to 
exist everywhere(IMHO!) software doing some work of editors, browsers, linkers,
maintenance tools, program development environments, little chunks of
software, small tools, home brewn examination programs, etc.
for which the "normal" appearance of a variable is just accepted 
with a minimum of effort as a token/name_nail/ etc.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert A Duff]

In article <dewar.863717431@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>This proposal was unanimously accepted at the DR/WG9 meeting the South of
>England in the forest (I forgot the name :-)

My memory is *slightly* different: There were three separate votes taken
(which I thought was silly), on three separate issues.  Whether to allow
(1) leading underscores, (2) two underscores in a row, or (3) trailing
underscores.  To my astonishment, the votes came out different.  I'm not
too sure, but I think (2) lost by a little bit, (1) lost by a greater
margin, and (3) won by a little bit.  So the design team published the
next version of the document allowing (3).  However, this annoyed some
people greatly.  It was more than just the French delegation.  So,
although I had been in favor of free use of underscores, I pushed on
Tucker to go back to the Ada 83 rule, because (A) I thought that it was
ludicrous to change the rule, but not change it fully, and (B) although
the split was roughly 50-50, the people against trailing underscores
felt much more strongly (fanatically, I would say!) than the other side,
so we shouldn't piss people off over such an unimportant feature.  So we
proposed this at the next meeting, and that's the way it ended up.

I can't remember the name of the forest, either.  :-)

>Anyway, there you are -- it's not in Ada 95 (you can guess which side
>Robert_ Dewar_ was_ supporting_ :-)

I was on the same side as Robert.  The really annoying thing is that we
were trying to have a good interface to C, and *leading* underscores
would come in really handy, there.

I suppose the design team could have insisted on having our way, but we
wanted to save our insisting for cases we felt were important enough to
go against the majority opinion.

- Bob

Re: Underscores in identifiers (was: Warning: Religious naming convention discussion :-)

[Ben Brosgol]

Robert A Duff wrote:
>  ...                            There were three separate votes taken
> (which I thought was silly), on three separate issues.  Whether to allow
> (1) leading underscores, (2) two underscores in a row, or (3) trailing
> underscores.  To my astonishment, the votes came out different.  I'm not
> too sure, but I think (2) lost by a little bit, (1) lost by a greater
> margin, and (3) won by a little bit.  So the design team published the
> next version of the document allowing (3).  However, this annoyed some
> people greatly.  It was more than just the French delegation.  So,
> although I had been in favor of free use of underscores, I pushed on
> Tucker to go back to the Ada 83 rule, because (A) I thought that it was
> ludicrous to change the rule, but not change it fully, and (B) although
> the split was roughly 50-50, the people against trailing underscores
> felt much more strongly (fanatically, I would say!) than the other side,
> so we shouldn't piss people off over such an unimportant feature.  So we
> proposed this at the next meeting, and that's the way it ended up.
> ...
> >Anyway, there you are -- it's not in Ada 95 (you can guess which side
> >Robert_ Dewar_ was_ supporting_ :-)
> 
> I was on the same side as Robert.  The really annoying thing is that we
> were trying to have a good interface to C, and *leading* underscores
> would come in really handy, there.
> 
> I suppose the design team could have insisted on having our way, but we
> wanted to save our insisting for cases we felt were important enough to
> go against the majority opinion.
> 
> - Bob

Let me add my recollections, since I guess I'm responsible for stirring
up the pot here with my earlier article.  At one point in the Ada 9X
design (I think this was in mid '93 or so) we had reached a grudging
compromise allowing an identifier to include a single trailing
underscore.  Just as the embers of this issue were dying down, a member
of the design team, Offer Pazy, came along with a figurative can of
gasoline and sent out a message to the reviewers to the effect that
allowing identifiers to end with an underscore was a violation of
fundamental Ada design principles, or something to that effect.  (Offer,
if you're out there and reading this, you can confirm or deny this
point.)  In any event, there's nothing like an argument about lexical or
syntactic issues to get people's language designer juices flowing  --
some would be amazed at how much time was spent at the Villars WG9
meeting (March '94) before settling on "Adjust" for the name of the
procedure that is invoked during assignment for a controlled type -- and
it wasn't long before it was obvious that the "compromise" solution for
a single trailing underscore was unraveling.  As Bob mentioned in the
quote above, the dynamic was that noone felt passionatley in favor of
allowing more generality for underscores in identifiers, but at least
one delegation (and I think others as well) felt _extremely_ strongly
that such liberalization would seriously compromise program
readability.  So back to the Ada 83 identifier rules we reverted.  

Ben Brosgol
brosgol@aonix.com

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Arthur Schwarz]

Robert Dewar wrote:
> 
> iBen wrote, with smileys
> 
> <<Here's a modest proposal for Ada 0Y that will solve this problem: allow

> England in the forest (I forgot the name :-)

Had to be 'Sherwood' - robbing from the poor and giving to the rich :-)

> 
> But on the final vote, the French delegation in particular made a major
> issue of opposing this, and insisted on its deletion, so it was deleted.
> They felt it encouraged bad identifiers such as A__________________B,
> which is horrible, indeed, though not much worse than OOOOOOOOOOOOO0000OOOO


The contention that underscores undermine any naming characterization
is ludicrous. As you pointed out above, it is just as possible to
generate ridiculous names using existing conventions. So what was
really sticking in the craw of the French?

art

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

art said

<<The contention that underscores undermine any naming characterization
is ludicrous. As you pointed out above, it is just as possible to
generate ridiculous names using existing conventions. So what was
really sticking in the craw of the French?>>

Well -- I see my style in denouncing things as ludicrous is catching :-)

Actually, it was the French who lead the charge here, but they had
sympathizers in other delegations :-)

To be fair, the underscores are a little more of a problem consider
a__________b

and

a0000000000b

and now imagine that we were not using a junk monospaced font (one of the
less attractive inventions of the computer age). Then we would be completely
unable to tell how many underlines are there.

Still, over all, I have to agree with the use of the "L" word here :-)

P.S. A little anecdote about the use of the "L" word. We were at an ARG
meeting, and Jean and I always use to argue ferociously -- so much so
that some Americans were quite surprised to learn that we are, now, then
and earlier, very good friends -- Americans always have trouble distinguishing
argument from quarrelling :-)

At one point, Jean got up and said "Ah, now I see thinks more clearly, now
that Robert has said my position is ludicrous nonsense, I see that I must
be completely wrong!"

A most charming way of complaining about excessive rhetoric. We all laughed
and continued the discussion at a more constructive level :-)

By the way, the word argument is interesting. In England it tends to have
much more positive connotations. I was always brought up to consider
argument as a valuable method for intellectual exploration (for more on
this see my father's autobiography -- Michael J.S. Dewar in the ACS
autobiography series). On the other hand, in the US, people tend to
equate argument with quarrelling, and find it hard not to argue without

getting emotionally involved.

I have a good principle on argument. Never argue a position unless you are
willing to argue the other side. If you are not willing to argue he other
side then eitther

(a) you are too emotionally involved
(b) you don't understand the other side well enough

Either reason is good enough to avoid arguing the point.

Once John Goodenough and I planned a debate on some Ada related subject,
where the deal was we would toss a coin just before the debate to see
who took what side, to emphasize this principle, but it never materialized :-)

Of course another trouble is that if you do argue both sides, then people
get confused -- "but I thought you believed ...." To me, belief is about
religeon, and is better excluded from technical discussions about programming
languages -- none of the issues we talk about is important enough to invest
emotional commitment and religeous belief in them :-)

Robert

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

This might be a bit off-topic, but...

Robert Dewar wrote:
> 
> Of course another trouble is that if you do argue both sides, then people
> get confused -- "but I thought you believed ...." To me, belief is about
> religeon, 
  ^^^^^^^^
> and is better excluded from technical discussions about programming
> languages -- none of the issues we talk about is important enough to invest
> emotional commitment and religeous belief in them :-)
                           ^^^^^^^^^

... this has been nagging at me: are "religeon" and "religeous" British
spellings for "religion" and "religious"?  Just curious... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Andrew Dunstan]

John G. Volan (johnvolan@sprintmail.com) wrote:
: This might be a bit off-topic, but...
[snip]
: ... this has been nagging at me: are "religeon" and "religeous" British
: spellings for "religion" and "religious"?  Just curious... :-)

not according to my SOED :-)

cheers

andrew
--

-------------------------------------------------------------------------
  There's nothing either good or bad, but thinking makes it so - Hamlet
  http://www.gr-lakes.com/~andrew (including PGP key)
  PGP Key fingerprint = 5C 44 7D E4 76 A3 31 DE  3D 11 FA 15 4D 87 1F 5E
-------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Nick Roberts]

Andrew Dunstan <amd001@its.maynick.com.au> wrote in article
<337e56fe.0@news2.maynick.com.au>...
> John G. Volan (johnvolan@sprintmail.com) wrote:
> : This might be a bit off-topic, but...
> [snip]
> : ... this has been nagging at me: are "religeon" and "religeous" British
> : spellings for "religion" and "religious"?  Just curious... :-)
> 
> not according to my SOED :-)


But sometimes the religious think themselves righteous.

It is interesting to note that many (not all) English, myself included,
find it very hard to engage in any kind of argument (i.e. a conversation
which involves the slightest disagreement of any kind) without feeling that
it implies criticism, and thus being emotional charged. This is the root of
the famous taciturn nature of the English: we would often rather simply
stay quiet than risk offending somebody. It is not a really a very useful
trait.

So if some of my arguments appear a bit too 'two-sided', that is, trying to
be too appreciative of the counter-argument, now you know why. I am
desperately trying not to annoy! I shall retire to the patio now, and sup
my Earl Grey tea :-)

Nick.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Nick Roberts wrote:
> 
> It is interesting to note that many (not all) English, myself included,
> find it very hard to engage in any kind of argument (i.e. a conversation
> which involves the slightest disagreement of any kind) without feeling that
> it implies criticism, and thus being emotional charged. 

Hmm, you rather contradict Robert Dewar (another Britisher, I believe),
who has on numerous occasions claimed that "an argument" has the
positive connotation of "a friendly debate" in England, versus the
negative connotation of "a fight" in the United States.

> This is the root of
> the famous taciturn nature of the English: we would often rather simply
> stay quiet than risk offending somebody. It is not a really a very useful
> trait.
> 
> So if some of my arguments appear a bit too 'two-sided', that is, trying to
> be too appreciative of the counter-argument, now you know why. I am
> desperately trying not to annoy! I shall retire to the patio now, and sup
> my Earl Grey tea :-)

Ah, but here you somewhat concur with Robert, who has also indicated
that one is not really qualified to convincingly debate in favor of
one's own position, unless one is also prepared to convincingly debate
_against_ it.  We may debate :-) whether Robert's assertion is
justified, but at any rate you put rather a different spin on what might
motivate a Britisher to hold such an assertion... :-)
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Nick Roberts wrote:
> 
> Andrew Dunstan <amd001@its.maynick.com.au> wrote in article
> <337e56fe.0@news2.maynick.com.au>...
> > John G. Volan (johnvolan@sprintmail.com) wrote:
> > : This might be a bit off-topic, but...
> > [snip]
> > : ... this has been nagging at me: are "religeon" and "religeous" British
> > : spellings for "religion" and "religious"?  Just curious... :-)
> >
> > not according to my SOED :-)
> 
> But sometimes the religious think themselves righteous.

Hmm, there could have been an unconscious association between "religeon"
and "dungeon", but so far as I know the last time religious folk spent
any significant amount of time hanging around in dungeons was during the
office of Torquemada.  Rather casts the expression (I paraphrase):

"The answer to such people is to either to educate them or to get rid of
such people"

in a whole new light. :-)  Well, I knew I was flirting with heresy...
:-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Kaz Kylheku]

In article <3373EAB5.73A0@sprintmail.com>,
John G. Volan <johnvolan@sprintmail.com> wrote:
>Jeff Carter wrote:
>
>> The problem with putting _Type on the end of all [sub]type names is that
>> it adds no information.
>
>But that's the whole point! Adding any more information is _undesirable_
>at this point, because presumably an object and its type _both_

Since taking on the learning of Ada95, I have adopted the old Pascal style
convention of prefixing 'a' to a capitalized type name: aTree, aList,
aStack, etc.

In C, I would favor a '_t' suffix, but this appears foreign in Ada
source. It just somehow seems impious.

Incidentally, the only reason I
would use such suffixes is to spare the fundamental type name for use
as a variable, e.g.    

    List : aList;

Other than that, I'm opposed to elaborate suffix or prefix schemes:
that Hungarian Notation thiing is a pet peeve!

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Kaz Kylheku wrote:
> 
> Since taking on the learning of Ada95, I have adopted the old Pascal style
> convention of prefixing 'a' to a capitalized type name: aTree, aList,
> aStack, etc.

Except that Ada is case-insensitive, so this should really be "A_Tree",
"A_List", "A_Stack".  By the way, would it be "An_Airplane" and
"An_Item"?

Personally, I don't quite like those as names for types.  When you do
something like this:

>    List : aList;

I think you're trying to cater too much to the "readability AS English"
school of thought: "List is a list".  I prefer "List_Type" for a list
type, because that's what the thing is: a list _type_.  Not actually "a
list" itself.

> Incidentally, the only reason I
> would use such suffixes is to spare the fundamental type name for use
> as a variable, e.g.

Precisely the goal I had in mind, and yes, your scheme would satisfy my
criterion that the naming convention be minimalistic and mechanical. I'd
just prefer calling a type what it _is_: a "_Type".

> Other than that, I'm opposed to elaborate suffix or prefix schemes:
> that Hungarian Notation thiing is a pet peeve!

I agree that HN is distasteful. It uses cryptic abbreviations -- but
that's endemic in C culture anyway. And it obsesses over the detailed
machine representation of things -- but that's the fault of the C
language itself, what with all the weaknesses in the type system.  I
mean, when you have implicit coercions, ambiguity between pointers and
arays, sentinel values marking the ends of characters strings instead of
attribute dope, it's no wonder you'd have to obsess about implementation
details.

I will give Micro$oft this much credit, however: They seem to apply HN
thoroughly and consistently, and _any_ naming convention, if applied
consistently, cannot help but enhance readability, once a sufficient
number of worker drones^H^H^H^H^H^H ahem, engineers have been
indoctrinated^H^H^H^H^H^H^H^H ahem, become familiarized with it.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Aaron Metzger]

John G. Volan wrote:

> But once again, I'd want the rule to be simple and minimalistic: Just
> always mark access types (and access objects) with "_Pointer".
> 

You really put a different spin on the whole debate with this example.
Up to this point I think people were just expressing different naming
conventions for types and objects in the "problem" space.  With
"_Pointer" you are stepping into implementation details.  Maybe in a
small local scope such conventions won't hurt you too much but I hope
you don't propose suffixes such as _Pointer, (or others that I combat
daily --> _Record, _List, _Array) for any type names that are exposed in
package specs.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Simon Wright]

Aaron Metzger <ametzger@erols.com> writes:

>           I hope
> you don't propose suffixes such as _Pointer, (or others that I combat
> daily --> _Record, _List, _Array) for any type names that are exposed in
> package specs.

Since access types are so important in class-wide programming
(Rationale II.2) I think their names will have to be visible
sometimes.

-- 
Simon Wright                        Work Email: simon.j.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Divsion            FAX: +44(0)1705-701800

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

John G. Volan wrote:

> But once again, I'd want the rule to be simple and minimalistic: Just
> always mark access types (and access objects) with "_Pointer".

Bad suggestion. Access types are NOT pointers. They may be implemented using
pointers some of the time (but not all the time -- we often find people
using GNAT being surprised to find that access types are not always
represented using simple pointers in some cases, but of course there is
nothing in the language that suggests or requires that access types be
implemented using pointers).

Suffixing access types with _Pointer emphasizes the confusion, and seems
inappropriate to me. It is analogous to saying that all integer types
should be suffixed with

  _Twos_Complement_Bit_String

or somesuch. Names should be chosen to emphasize the meaning at an
appropriate level of abstraction, not the low-level implementation
dependent representation.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert A Duff]

In article <dewar.863365392@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Bad suggestion. Access types are NOT pointers. They may be implemented using
>pointers some of the time (but not all the time -- we often find people
>using GNAT being surprised to find that access types are not always
>represented using simple pointers in some cases, but of course there is
>nothing in the language that suggests or requires that access types be
>implemented using pointers).

I disagree.  I think "pointer" means "thing that can point".  I don't
think it's a low-level machine-oriented concept at all.  I use the term
"address" or "machine address" for the low-level notion.  I would amend
your last sentence to say, "... there is nothing in the language that
suggests or requires that access types be implemented as machine
addresses."

Note that Pascal calls them "pointers", not "access types", and there is
nothing in Pascal that suggests or requires pointers to be implemented
as machine addresses.  This is even true of C, and there are in fact
implementations of C that implement "foo*" as something other than an
address -- for the purpose of doing bounds checking and whatnot, which
is very expensive in C, but nonetheless useful for debugging.

If I have a private type whose full type is some sort of index into a
table, then I'm perfectly happy to call that a "pointer", even though
it's not implemented as an address, and it's not even implemented as an
access type.

People talk about Lisp/Smalltalk/etc as languages in which "everything's
a pointer", which is an informal phrase intended to mean that all the
variables and whatnot have reference semantics -- not that they're all
implemented as machine addresses (which they might be, but that's
irrelevant).

So, no, I don't think that "pointer" universally means "address".  It
does only in the minds of some people who have only been exposed to
languages that allow or encourage address arithmetic on something called
"pointers".  If people with that background learn a higher-level
language, they simply have to learn that access types, or reference
types, or pointer types, simply aren't addresses.

Analogy: You might say that some programmers assume that "procedure
calls" involve a call instruction at the machine level.  Therefore, we
shouldn't call them "procedure calls" in Ada, because compilers might do
inlining (either in response to pragma Inline, or automatically), and
using the term "call" therefore confuses.

>Suffixing access types with _Pointer emphasizes the confusion, and seems
>inappropriate to me. It is analogous to saying that all integer types
>should be suffixed with
>
>  _Twos_Complement_Bit_String
>
>or somesuch. Names should be chosen to emphasize the meaning at an
>appropriate level of abstraction, not the low-level implementation
>dependent representation.

I don't buy the analogy here.  Two's complement bit-string *is* a
low-level machine-oriented notion.  Address is.  But Pointer is not, at
least for a substantial portion of the software industry.

- Bob

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

<<I disagree.  I think "pointer" means "thing that can point".  I don't
think it's a low-level machine-oriented concept at all.  I use the term
"address" or "machine address" for the low-level notion.  I would amend
your last sentence to say, "... there is nothing in the language that
suggests or requires that access types be implemented as machine
addresses."

Note that Pascal calls them "pointers", not "access types", and there is
nothing in Pascal that suggests or requires pointers to be implemented
as machine addresses.  This is even true of C, and there are in fact
implementations of C that implement "foo*" as something other than an
address -- for the purpose of doing bounds checking and whatnot, which
is very expensive in C, but nonetheless useful for debugging.>>

says Bob Duff, and I agree in theory, but in practice, say pointer to
most people, and then think of a machine address ... it is that
perception of connection that causes confusion.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert A Duff]

In article <dewar.863448507@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>says Bob Duff, and I agree in theory, but in practice, say pointer to
>most people, and then think of a machine address ... it is that
>perception of connection that causes confusion.

Well, at least we agree "in theory".  ;-)

In practise, I *like* the word pointer (with it's fairly high-level
meaning), and I'm not about to give it up to those who think it means,
merely, "machine address".

Who are these "most people"?  There are a lot of C and C++ programmers
in the world, and yes indeed many of them think pointer=machine address.
Sigh.  They're wrong, of course, since it's not even true in C or C++,
much less Pascal or Ada or Lisp or ....  To paraphrase a recent quote
from you in a different thread: "Get rid of such people, either by
educating them, or by getting rid of them."  Anybody who's got
experience in a language where "pointer" doesn't allow (e.g.) address
arithmetic, and anybody who's programmed in a language where
"everything's a pointer", can understand the difference.

I mean, by your reasoning, we shouldn't call Ada's arrays "arrays",
because they might be confused with C arrays, which are a very low-level
notion indeed!  ;-)  (And, by the way, I have no objection to a language
with associative arrays calling *those* things arrays, even though some
poor, low-level, Ada programmer might think they're getting a contiguous
chunk of storage with random access performance.  ;-))

So I'm sticking to my meaning of "pointer", which I think is shared by
at least a substantial minority of software folk: It's a pointer if it
points -- i.e. if you have reference semantics.  That is, if you modify
what X points to, and what Y points to can see the change, you've got
reference semantics.  That's why I sometimes say, "So-and-so (an index
into an array) points to such-and-such thing (an element of that
array)."  (In fact, I said such things about array indices when I was
programming in assembly language!)

- Bob

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

Bob Duff said

<<I mean, by your reasoning, we shouldn't call Ada's arrays "arrays",
because they might be confused with C arrays, which are a very low-level
notion indeed!  ;-)  (And, by the way, I have no objection to a language>>

Why are C arrays very low-level notions?
I agree they are often used this way, but I don't see this from the standard.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[David L Brown]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Bob Duff said

> <<I mean, by your reasoning, we shouldn't call Ada's arrays "arrays",
> because they might be confused with C arrays, which are a very low-level
> notion indeed!  ;-)  (And, by the way, I have no objection to a language>>

> Why are C arrays very low-level notions?
> I agree they are often used this way, but I don't see this from the standard.

Probably because the notation in C:

	foo[bar]

is semantically equivalent to

	*(foo + bar)

Since addition is commutative, array_name[42] is the same as
42[array_name].  The array notation is just shorthand for pointer
arithmetic.  Fortunately, you don't have to use it this way.

Dave Brown

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[W. Wesley Groleau (Wes)]

Re: Is "_Pointer" an implementation detail or an abstraction?

Answer: Depends on how you use it.  If neither my algorithm nor
my abstraction _depends_ on using a "pointer" or whatever it might
be called, then it's an implementation detail.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

David Brown said

<<Probably because the notation in C:

        foo[bar]

is semantically equivalent to

        *(foo + bar)>>

Robert replies

Actually this is not nearly so "bad" as you might think, as I pointed out
in an earlier reply.
A pointer in C is a structured value with two parts
A reference to the base (in this case the array foo), and an offset
in storage units.

Pointer arithmetic adjusts the storage unit offset to correspond to the
appropriate number of typed components (i.e. in Ada terms component_size
is equal to the type'size, and the offset is adjsuted by bar * component_size.

So really one could say that *(foo + bar) is simply a shorthand for
foo[bar] rather than the other way round!

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert A Duff]

In article <dewar.863495951@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Why are C arrays very low-level notions?

Because:

1. They don't carry their length (or bounds) with them.  You have to
pass this information "by hand", as a separate thing.

2. There are no "whole array" operations, such as assignment and
comparison.  (Yes, there are library functions for these, but they don't
operate on whole arrays -- they take pointer-to-first-element and
size/length parameters separately.)

3. You can't pass an array as a parameter -- you have to pass a pointer
to the first component, instead.  (Or, looking at it a different way, an
array *is* a pointer to the components.  C is pretty confused on this
point.)  And having done that, there's no way to tell, in the language,
whether a given formal parameter of type t* is pointing to a t, or to
the first element of an array of t's.

4. Array indexing is defined in terms of pointer arithmetic.
(Well, I admit this is a rather weak reason.)

5. The lower bound is always zero, rather than whatever makes sense to
the programmer.  E.g. if you want a table that maps the numbers A..B
onto something-or-other, you have to subtract off A "by hand"

All of the above give me the feeling that a C array is, conceptually, a
pointer to a hunk of contiguous storage.  That's a low-level,
machine-oriented, notion.

>I agree they are often used this way, but I don't see this from the standard.

- Bob

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Kaz Kylheku]

In article <EA4J04.LpH@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>In article <dewar.863495951@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>>Why are C arrays very low-level notions?
>
>Because:
>
>1. They don't carry their length (or bounds) with them.  You have to
>pass this information "by hand", as a separate thing.

C structures don't carry a count of their elements with them either.
Are they low level notions?

>2. There are no "whole array" operations, such as assignment and
>comparison.  (Yes, there are library functions for these, but they don't
>operate on whole arrays -- they take pointer-to-first-element and
>size/length parameters separately.)

This is more due to a quirk in the language which disallows an array 
from being a modifiable lvalue. However when arrays are embedded in
structures, they may be assigned along with the structure, and may also
be passed into functions by value, and returned from functions.

>3. You can't pass an array as a parameter -- you have to pass a pointer
>to the first component, instead.  (Or, looking at it a different way, an

You can also pass a pointer to the whole array. For example;

    typedef char user_id[8];

    int user_exists(user_id *foo);

The argument foo is a pointer to array of 8 char. Getting to the first
character in that array would look like this:  (*foo)[0] . 
In many circumstances, this technique is far preferred.

>array *is* a pointer to the components.  C is pretty confused on this
>point.)

C isn't confused: some C newbies are confused perhaps. It's a hard rule
though. It's a major failing of the language that it doesn't provide
``bona fide'' arrays. It has to do with C's historical roots dating
back to the B language.

In fact, in the B language, arrays _were_ pointers. Arrays actually contained,
in their first cell, a pointer to their data section. A pointer was just an
array with no data section, just the pointer cell (declared by not writing
anything between the square brackets as in ``int foo[]'' which would be
interpreted in C as an incomplete array declaration).  This became a problem in
the design of C which allowed arrays to be embedded into structures---with no
automatic initialization or finalization constructs, how would the cell be 
properly initialized inside a dynamically created structure?  So Ritchie
changed the rules so that evaluating an array would cause a pointer to its
first element to be computed rather than loaded from a cell.  A few badly
behaved B programs had to be changed: those which actually played with the cell
contents to relocate an array. The alternate notations for declaring a pointer
argument to a function (e.g.   char **argv and char *argv[]) are a merely a
historic artifact left over from B.

>And having done that, there's no way to tell, in the language,
>whether a given formal parameter of type t* is pointing to a t, or to
>the first element of an array of t's.

That's unfortunate in many circumstances, though convenient in others.  It's
good in those circumstances when the extra array management overhead isn't
needed. It's bad in those circumstances when a C programmer is forced to invent
a more general array data type, such as a structure containing a length and a
pointer to data. Today, I wouldn't think of designing a language without decent
arrays. What I find appealing are two dimensional slice extractions. Even
Ada doesn't have those!  The ``Dragon Book'' gives a good discussion for
the representation of arrays such that efficient extractions of rectilinear
sub-arrays portion are possible.

>4. Array indexing is defined in terms of pointer arithmetic.
>(Well, I admit this is a rather weak reason.)

These are all weak reasons for the argument that arrays are a low level
construct; they are good reasons for some other claim though, such as the claim
that C arrays are insufficiently general for some purposes.

>5. The lower bound is always zero, rather than whatever makes sense to
>the programmer.  E.g. if you want a table that maps the numbers A..B
>onto something-or-other, you have to subtract off A "by hand"

If you program C long enough, nothing but zero based arrays makes sense! :)))

>All of the above give me the feeling that a C array is, conceptually, a
>pointer to a hunk of contiguous storage.  That's a low-level,
>machine-oriented, notion.

Except that the elements of that hunk still have a type, possibly a const
qualifier, etc. The true low level notion in C is that any object can
be treated as though it were an array of characters, and that all storage
is measured in characters.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert A Duff]

In article <5laovr$l7t@bcrkh13.bnr.ca>,
Kaz Kylheku <kaz@vision.crest.nt.com> wrote:
>In article <EA4J04.LpH@world.std.com>,
>Robert A Duff <bobduff@world.std.com> wrote:
>>In article <dewar.863495951@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>>>Why are C arrays very low-level notions?
>>
>>Because:
>>
>>1. They don't carry their length (or bounds) with them.  You have to
>>pass this information "by hand", as a separate thing.
>
>C structures don't carry a count of their elements with them either.
>Are they low level notions?

No.  C structures don't have a "give me the N'th component" operation,
so of *course* they don't need to know how many components they have.
The *do* know they're size, though (sizeof(x)).

>>2. There are no "whole array" operations, such as assignment and
>>comparison.  (Yes, there are library functions for these, but they don't
>>operate on whole arrays -- they take pointer-to-first-element and
>>size/length parameters separately.)
>
>This is more due to a quirk in the language which disallows an array 
>from being a modifiable lvalue. However when arrays are embedded in
>structures, they may be assigned along with the structure, and may also
>be passed into functions by value, and returned from functions.

What you call a "quirk" I call a major language design flaw.  Anyway,
I'm not sure what you mean by "more due to...".  The fact is, in C, you
can't pass arrays, but only pointers.  That makes the notion of arrays
"low level", IMHO.

>>3. You can't pass an array as a parameter -- you have to pass a pointer
>>to the first component, instead.  (Or, looking at it a different way, an
>
>You can also pass a pointer to the whole array. For example;
>
>    typedef char user_id[8];
>
>    int user_exists(user_id *foo);
>
>The argument foo is a pointer to array of 8 char. Getting to the first
>character in that array would look like this:  (*foo)[0] . 
>In many circumstances, this technique is far preferred.

Granted.  But it only works if the "8" happens to be a
compile-time-known quantity, which if often isn't.  And, anyway, inside
user_exists, you can't know whether user_id is a pointer to a foo, or a
pointer to an array of foo's.

>>array *is* a pointer to the components.  C is pretty confused on this
>>point.)
>
>C isn't confused: some C newbies are confused perhaps. It's a hard rule
>though. It's a major failing of the language that it doesn't provide
>``bona fide'' arrays. It has to do with C's historical roots dating
>back to the B language.

OK, perhaps C isn't confused.  I should have said "C is inconsistent",
since sometimes an array is an array, and sometimes it's merely a
pointer.  And that *leads* to confusion.  Don't blame the "newbies" --
the *language* is at fault here.  The fact remains that within a
function, a *thing could be a pointer-to-a-thing, or a
pointer-to-the-first-element-of-an-array-of-things, and there's no
language-defined way to tell.

>In fact, in the B language, arrays _were_ pointers. Arrays actually contained,
>in their first cell, a pointer to their data section. A pointer was just an
>array with no data section, just the pointer cell (declared by not writing
>anything between the square brackets as in ``int foo[]'' which would be
>interpreted in C as an incomplete array declaration).  This became a problem in
>the design of C which allowed arrays to be embedded into structures---with no
>automatic initialization or finalization constructs, how would the cell be 
>properly initialized inside a dynamically created structure?  So Ritchie
>changed the rules so that evaluating an array would cause a pointer to its
>first element to be computed rather than loaded from a cell.  A few badly
>behaved B programs had to be changed: those which actually played with the cell
>contents to relocate an array. The alternate notations for declaring a pointer
>argument to a function (e.g.   char **argv and char *argv[]) are a merely a
>historic artifact left over from B.

I don't know B.  But I fail to see how blaming C's poor language design,
in this area, somehow makes it "high level".  Maybe B was quite
consistent in this regard.  So what?  We're talking about C.

>>And having done that, there's no way to tell, in the language,
>>whether a given formal parameter of type t* is pointing to a t, or to
>>the first element of an array of t's.
>
>That's unfortunate in many circumstances, though convenient in others.  It's
>good in those circumstances when the extra array management overhead isn't
>needed. It's bad in those circumstances when a C programmer is forced to invent
>a more general array data type, such as a structure containing a length and a
>pointer to data. Today, I wouldn't think of designing a language without decent
>arrays. What I find appealing are two dimensional slice extractions. Even
>Ada doesn't have those!  The ``Dragon Book'' gives a good discussion for
>the representation of arrays such that efficient extractions of rectilinear
>sub-arrays portion are possible.

But that's all about "good" vs. "bad", which isn't *quite* the same
thing as "low level" vs. "high level".  My claim is that the C
definition of arrays is "low level", as compared to Ada's definition of
arrays.  I certainly didn't claim that Ada's arrays are at the highest
possible level -- after all, they require the index type to be discrete!
(We're talking about "level" of abstraction, here, not level of goodness
or some such thing.)  And I certainly agree that a C struct containing
bounds info plus an array (plus associated operations) might be at the
same abstraction level as an Ada array.

>>4. Array indexing is defined in terms of pointer arithmetic.
>>(Well, I admit this is a rather weak reason.)
>
>These are all weak reasons for the argument that arrays are a low level
>construct; they are good reasons for some other claim though, such as the claim
>that C arrays are insufficiently general for some purposes.

I disagree.  An Ada array is more-or-less at the same level of
abstraction as a C struct that has bounds plus array components.
The plain-old-array, in C, is at a lower level of abstraction.

>>5. The lower bound is always zero, rather than whatever makes sense to
>>the programmer.  E.g. if you want a table that maps the numbers A..B
>>onto something-or-other, you have to subtract off A "by hand"
>
>If you program C long enough, nothing but zero based arrays makes sense! :)))

That's the problem with programmers, today.  ;-)

>>All of the above give me the feeling that a C array is, conceptually, a
>>pointer to a hunk of contiguous storage.  That's a low-level,
>>machine-oriented, notion.
>
>Except that the elements of that hunk still have a type, possibly a const
>qualifier, etc.

Granted.  It's not quite as low-level as I claimed -- you still have the
notion that ptr++ increments by the "right" amount.  And you still have
const.  I.e., granted that ptr++ is not quite as low level as address
arithmetic.  Hence my caveat on point (4) above.  I still stand by the
other points.

>... The true low level notion in C is that any object can
>be treated as though it were an array of characters, and that all storage
>is measured in characters.

Yeah.  That, too.

- Bob

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Kevin Cline]

kaz@vision.crest.nt.com (Kaz Kylheku) wrote:

>Today, I wouldn't think of designing a language without decent
>arrays.

Why?  What makes arrays more important that lists or maps? This wss one of my
pet peeves with Ada83 -- it provided very nice array support, but nothing
else.  This just encouraged mediocre Ada programmers to solve every problem
with an array, even when another structure would have been considerably faster
and easier to use.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

Kevin says

<<Why?  What makes arrays more important that lists or maps? This wss one of my
pet peeves with Ada83 -- it provided very nice array support, but nothing
else.  This just encouraged mediocre Ada programmers to solve every problem
with an array, even when another structure would have been considerably faster
and easier to use.>>

I think Ada 83 made the right choice here. It provided the abstraction
mechanisms for creating lists and maps, but did not put in direct support,
and I think this decision (common for languages at this level) is exactly
right. On the other hand, arrays are fundamental, and really need to be
there as a primitive.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

Bob Duff said

<<4. Array indexing is defined in terms of pointer arithmetic.
(Well, I admit this is a rather weak reason.)>>


Actually I think that's a bit backwards, I would say that pointer arithmetic
in C is defined in terms of indexing in some sense. A pointer in C is
conceptually a pair (base address, offset), and pointer arithmetic adjusts
the offset, which is closely related to an array index.
(indeed it is EXACTLY what COBOL would call an array index :-)

But I agree with some of your other reasons, although I do not agree
that pointers and arrays are synonymous in C, it is just that there
are implicit coercions between these two types.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <dewar.863575928@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

   Bob Duff said

   <<4. Array indexing is defined in terms of pointer arithmetic.
   (Well, I admit this is a rather weak reason.)>>


   Actually I think that's a bit backwards, I would say that pointer arithmetic
   in C is defined in terms of indexing in some sense. A pointer in C is
   conceptually a pair (base address, offset), and pointer arithmetic adjusts
   the offset, which is closely related to an array index.
   (indeed it is EXACTLY what COBOL would call an array index :-)

   But I agree with some of your other reasons, although I do not agree
   that pointers and arrays are synonymous in C, it is just that there
   are implicit coercions between these two types.

From "The C programming language", 2. ed., page 99:

"The correspondence between indexing and pointer arithmetic is very
close. By definition, the value of a variable or expression of type
array is the address of element zero of the array."

and further:

"In short, an array-and-index expression is equivalent to one written
as a pointer and offset"

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert Dewar wrote:
> 
> John G. Volan wrote:
> 
> > But once again, I'd want the rule to be simple and minimalistic: Just
> > always mark access types (and access objects) with "_Pointer".
> 
> Bad suggestion. Access types are NOT pointers. They may be implemented using
> pointers some of the time (but not all the time -- we often find people
> using GNAT being surprised to find that access types are not always
> represented using simple pointers in some cases, but of course there is
> nothing in the language that suggests or requires that access types be
> implemented using pointers).

I think you're reading too much into my usage of the word "pointer". I
did not mean at all to imply any implementation details by using this
word, in fact I had in mind exactly the high-level abstraction of an
access type. I'm a bit surprised that "pointers" would somehow be a
low-level implementation concept. Ever since my Pascal days, I've always
viewed them as quite a high level abstraction.  Today, with my
experience with Ada, I'd tend to use "Address" for the low-level
implementation, and indeed, access types are not necessarily simple
addresses.  Perhaps your interpretation of "pointer" comes from C, where
pointers seem to be treated synonymously with addresses. (Although I'm
not so sure about that, aren't C pointers sometimes implemented as an
address plus an element index?)

In fact, the only reason I would suggest this usage would be when you
are providing an abstraction that includes both a designated type and a
visible access type -- _both_ as part of the visible interface.  Both
types would relate to the same concept, but they would still need to be
differentiated by each other. So one type must be marked somehow. 
"_Pointer" seems a convenient marker, but if that hits any raw nerves,
how about "_Access"?

   package Targets is

     type Target_Type is tagged limited private;
     type Target_Access_Type is access all Target_Type'Class;
     ...

By the way, this would be a case where my naming convention might relax
a bit: Not every variable of Target_Access_Type would necessarily have
to be called [Optional_Prefix_]Target_Access.  The "_Access" could be
dropped if you were in a context where you were only working directly
with an access variable, and didn't have to have a separate name for the
designated object, e.g.:

    procedure Do_Something_Classwide (Target : in Target_Access_Type);

This is especially true if the access type were anonymous:

    procedure Do_Something_Primitive (Target : access Target_Type);

The only time "_Access" would have to be used in an object name would be
in (relatively rare) cases where you needed to name both the designated
object and the access object in the same scope.

The only difficulty with using "Access" as a marker instead of "Pointer"
is that "Access", being a reserved word, cannot stand alone as a
variable name. When would you want to do that?  Consider a generic:

    generic
      type Object_Type (<>) is limited private;
      type Pointer_Type is access all Object_Type;
    package Garbage_Collected_Refs is
      -- by convention, let "Ref" mean "Reference"

      type Ref_Type is private;

      function "+" (Pointer : in Pointer_Type) return Ref_Type;
      function "+" (Ref : in Ref_Type) return Pointer_Type;

    private
      type Ref_Type is new Controlled with ...
    end Garbage_Collected_Refs;

The first "+" overloading takes an access value and generates a
garbage-collected reference value for it, the second retrieves the
access value from a reference.  At this level of abstraction, we don't
have any particular designated type and access type, so there is no
compelling reason to mark the access parameter as anything other than
"Pointer".  If the convention were to use "Access", then we have
trouble:

   generic
     type Object_Type (<>) is limited private;
     type Object_Access_Type is access all Object_Type;
   package Garbage_Collected_Refs
      -- by convention, let "Ref" mean "Reference"

      type Ref_Type is private;

      function "+" (Object_Access : in Object_Access_Type) return
Ref_Type;
      function "+" (Ref : in Ref_Type) return Object_Access_Type;

    private
      type Ref_Type is new Controlled with ...
    end Garbage_Collected_Refs;

It might be misleading in this case to take the suggestion I made above
and drop "_Access" from the parameter and just call it "Object".  These
operations are more concerned with the access value rather than the
designated object.

> Suffixing access types with _Pointer emphasizes the confusion, and seems
> inappropriate to me. It is analogous to saying that all integer types
> should be suffixed with
> 
>   _Twos_Complement_Bit_String
> 
> or somesuch.

Reductio ad absurdum at its finest. :-)

> Names should be chosen to emphasize the meaning at an
> appropriate level of abstraction, not the low-level implementation
> dependent representation.

Why, I quite agree, and have already said so several times in this
discussion. We merely misunderstand each other as to which words refer
to abstractions and which to implementation details.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Kaz Kylheku]

In article <dewar.863365392@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>John G. Volan wrote:
>
>> But once again, I'd want the rule to be simple and minimalistic: Just
>> always mark access types (and access objects) with "_Pointer".
>
>Bad suggestion. Access types are NOT pointers. They may be implemented using
>pointers some of the time (but not all the time -- we often find people

You are assuming that a pointer is a lower level construct, that is, 
a machine address. Whether this is true depends on the context. If an
assembly language programmer speaks about pointers, he or she probably
means address words. A Pascal programmer might use the word to designate
the high level reference type of that language.

An access type is basically a pointer. You can say that a URL embedded in
someone's web page is also a pointer of sorts.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Aaron Metzger wrote:
> 
> You really put a different spin on the whole debate with this example.
> Up to this point I think people were just expressing different naming
> conventions for types and objects in the "problem" space.  With
> "_Pointer" you are stepping into implementation details.

Nope, not at all. See other followups for why "_Pointer" refers to a
high-level abstraction.  I can be persuaded to substitute it with
"_Access" but this just refers to the same high-level abstraction.

In Ada83, you may well have been indoctrinated in the idiom that says
that access types should be implementation details hidden inside
packages. In some cases of abstract data types, that's still quite
correct.

But object-oriented software tends to get heavy into the use of
reference semantics. An "object" (in the OO sense) has an "identity"
distinct from its "state". Two objects with the same state are still
distinct objects, because their identities are different.  Objects tend
to cross-reference each other by storing each other's identities (_not_
copying their states).  There are many ways such identity references can
be implemented, but one very convenient way is with an access type.
Therefore, a common object-oriented idiom for Ada95 will be to have a
package that implements a notional "class" of objects by declaring a
tagged type (preferably limited and private) with an accompanying access
type (usually general access to classwide).

> Maybe in a
> small local scope such conventions won't hurt you too much but I hope
> you don't propose suffixes such as _Pointer, (or others that I combat
> daily --> _Record, _List, _Array) for any type names that are exposed in
> package specs.

I can see little justification for marking a type with "_Record", so I
agree with you on that.

"_List" I would reserve as a marker for some private type (probably from
a generic instance) that actually implemented some kind of "list"
abstraction.

"_Array" I do find to be useful.  If an array type is publicly visible
in a package spec, I think "_Array" is a perfectly valid marker to put
on its name.  It tells it like it is: The thing _is_ an "_Array_Type".
That's the abstraction clients see: Objects of that type can be indexed
and sliced and so forth.  Other markers, such as "_Table", "_Vector",
"_Matrix", might also be acceptable for a visible array type, but those
markers might be even better suited for private types, and anyway,
"_Array" just seems more honest.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Jeff Carter]

John G. Volan wrote:
...
> (By the way, we can level a similar criticism against the AQ&S guide's
> "general" vs. "specific" noun phrase scheme:  There are just too many
> different adjectives in English that can confer "specificness" to a noun
> phrase, and it's a waste of effort having to sort them all out.  You
> wind up concluding, as I did, that it's better to just settle on one
> universal "objectness" marker ("The_") and be done with it.  But then
> you need to take a step back and ask whether it's more practical to mark
> all the _objects_, or all the _types_ instead.  My conclusion was that
> it's better to mark all the types.)

The AQ&S is generally too vague and contradictory to be useful. This is
perhaps best demonstrated by the fact that its "complete example" does not
conform to its recommended style, and contains errors.

...
>     type Error_Count_Type is range 0 .. Error_Limit;
>     ...
>     Error_Count : Error_Count_Type; -- counts errors flagged so far

   type Error_Count is range ...

   Num_Errors : Error_Count;

> 
> versus
> 
>     type Error_Ident_Type is range Minimum_Error_Ident ..
> Maximum_Error_Ident;
>     ...
>     Error_Ident : Error_Ident_Type; -- identifies the last error flagged

   type Error_Id is ...

   Last_Error : Error_Id;

> 
> But, as you can see, you're still faced with the problem of generating a
> different identifier for the type.

Nope. See above.

> 
> IMHO, if you can't justify tacking a suffix onto an object name, then it
> really doesn't add any useful information. Appending it onto the type
> name just wastes energy and adds confusion.  If the only purpose it
> serves is to differentiate the type, a universal type marker would have
> been a simpler solution.

You should never tack type suffixes onto object names. That's adding type
information to object identifiers. That should be unnecessary. That's what
M$'s horrible Hungarian notation is.

Although I claimed in jest to be religious about this, I trust that the
jest was obvious. I'm most interested in creating readable code; I don't
always stick these suffixes on type names. Note, for example, the type
Position in the List example.
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Jeff Carter wrote:
> 
>    type Error_Count is range ...
>    Num_Errors : Error_Count;

Nope, that's the synonym method, semantically uneconomical.

  type Num_Errors_Type is range ...;
  Num_Errors : Num_Errors_Type;

But I don't want to use plurals in type/object names, because I want to
reserve the plural form as my marker for a package.

>    type Error_Id is ...
>    Last_Error : Error_Id;

Nope, that's marking the object with a "specific" adjective. If "error"
is enough to convey the sense that it's an id and not a count, then why
not just dispense with "_id"?

  Last_Error : Error; -- marking the object vs. the type

But what would you do if you're in a context where you don't have any
convenient adjective for the situation? Resort to a default marker?
("The_"?) I say, mark the type and don't force programmers to mark the
objects. e.g., My scheme:

  procedure Display
    (Error : in Error_Type);  -- it' just some error you want displayed
                              -- not necessarily the last one

Your scheme (?):

  procedure Display
    (The_Error : in Error); -- marking the object vs. the type


------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[W. Wesley Groleau (Wes)]

John G. Volan wrote:
> 
> Jeff Carter wrote:
> 
> > The problem with putting _Type on the end of all [sub]type names is that
> > it adds no information.
> 
> But that's the whole point! Adding any more information is _undesirable_
> at this point, because presumably an object and its type _both_
> represent the _same_ concept 

If 
   Angle : Angle_Type;
is the only object of Angle_Type, then perhaps the declaration of
Angle_Type is just clutter.  (See my recent post about anonymous
array types.)  But "Angle" is rather vague.  Might we in the future
want to deal with more than one Angle?  

The "same concept" argument could be interpreted to recommend:

   Angle_1   : Angle_1_Type;
   Angle_2   : Angle_2_Type;
   Sum_Angle : Sum_Angle_Type;
.....
   Sum_Angle := Sum_Angle_Type (Angle_1) + Sum_Angle_Type (Angle_2);

If "adding any more information is _undesirable_" then I would say
that a language construct that _must_ be there (though it adds nothing)
is either a flaw in the language or (more likely) a sign that the
program still needs some abstract thought.

The above snippet is much clearer as

   Start_Point, Rotation, End_Point : Angle;
.....
   End_Point := Start_Point + Rotation;

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e s e r v 3  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

W. Wesley Groleau (Wes) wrote:
> 
> John G. Volan wrote:
> >
> > Jeff Carter wrote:
> >
> > > The problem with putting _Type on the end of all [sub]type names is that
> > > it adds no information.
> >
> > But that's the whole point! Adding any more information is _undesirable_
> > at this point, because presumably an object and its type _both_
> > represent the _same_ concept
> 
> If
>    Angle : Angle_Type;
> is the only object of Angle_Type, 

Nope, that's a nice strawman, but that's not my position at all, you're
reading that into what I said.  "Angle" is not necessarily the only
Angle_Type object _in the program_, but it may be the only Angle_Type
object _in a given local scope_.  In that local context, why should I be
forced to call that object anything other than the simple word "Angle"?

> then perhaps the declaration of
> Angle_Type is just clutter.  (See my recent post about anonymous
> array types.)  But "Angle" is rather vague.  Might we in the future
> want to deal with more than one Angle?
>
> The "same concept" argument could be interpreted to recommend:
> 
>    Angle_1   : Angle_1_Type;
>    Angle_2   : Angle_2_Type;
>    Sum_Angle : Sum_Angle_Type;
> .....
>    Sum_Angle := Sum_Angle_Type (Angle_1) + Sum_Angle_Type (Angle_2);

Again, quite a pretty strawman. (I can't believe you are being serious
here.)  Of course you can have as many Angle_Type objects as you like,
prefixing (or even suffixing) the "Angle" word with whatever "specific"
modifiers you like, e.g., 

   Start_Angle, End_Angle, Rotation_Angle : Angle_Type;
   ...
   End_Angle := Start_Angle + Rotation_Angle;

or perhaps:

   procedure Rotate
     (Angle          : in out Angle_Type;
      Rotation_Angle : in     Angle_Type)
   is
   begin
     Angle := Angle + Rotation_Angle;
   end Rotate;

My scheme has the advantage that a "specific" identifier such as
"Start_Angle" is clearly the name of an object, and can never be
confused as the name of a "specific" derived- or sub-type of Angle_Type.
A subtype or derived type would always be marked "_Type" just like any
other type:

  type Angle_Type is digits ... ;
  -- for angular values in general (in degrees)

  subtype Proper_Angle_Type is
    Angle_Type range 0.0 .. Angle_Type'Pred(360.0);
    -- for angular values constrained to non-negatives
    -- within one cycle

  subtype Signed_Angle_Type is
    Angle_Type range -180.0 .. Angle_Type'Pred(+180.0);

  type Direction_Type is new Proper_Angle_Type;
  -- for navigational compass-directions

  type Longitude_Type is new Signed_Angle_Type;
  -- for geographic longitudes

> If "adding any more information is _undesirable_" then I would say
> that a language construct that _must_ be there (though it adds nothing)
> is either a flaw in the language or (more likely) a sign that the
> program still needs some abstract thought.

Go back a couple posts and look again.  I was objecting to Jeff Carter's
suggestion of a whole smorgasbord of different type-marking suffixes for
the different classes of types. For example, for a floating point type,
you might have something like (not one of Jeff's examples but similar):

  type Angle_Real is digits ...;
  -- "Real" marks it as a floating point type

  Angle : Angle_Real;

I say, why encode such an implementation detail into the type name and
not inro the object name, too?  You should either encode it in both or
in neither (and I strongly favor encoding it in neither!)

> The above snippet is much clearer as
> 
>    Start_Point, Rotation, End_Point : Angle;
> .....
>    End_Point := Start_Point + Rotation;

The synonym scheme again.  This blithe violation of semantic economy
will cost you later if you decide to use the word "Point" to refer to a
two-dimensional cartesian-coordinate vector, and use "Rotation" to refer
to a rotational transformation matrix.  It may be wiser to be thrifty
with your semantics from the start, and simply retain the word "Angle"
in your objects of Angle_Type:

  Start_Angle, Rotation_Angle, End_Angle : Angle_Type;
  ...
  End_Angle := Start_Angle + Rotation_Angle;
  ...

  function Get_Rotation
    (Angle : in Angle_Type)
     return Rotation_Type;
     -- generates coordinate transformation matrix to rotate 
     -- points around the origin by the given angle

  function "*"
    (Rotation : in Rotation_Type;
     Point    : in Point_Type)
     return Point_Type;
     -- applies rotational transformation matrix to point

  ...
  Start_Point, End_Point : Point_Type;
  Rotation : constant Rotation_Type :=
    Get_Rotation (Angle => Rotation_Angle);
  ...
  End_Point := Rotation * Start_Point;

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[W. Wesley Groleau (Wes)]

John G. Volan wrote:
> W. Wesley Groleau (Wes) wrote:
> > John G. Volan wrote:
> > > Jeff Carter wrote:
> > > > The problem with putting _Type on the end of all [sub]type names 
> > > > is that it adds no information.
> > > But that's the whole point! Adding any more information is
> > > _undesirable_ at this point, because presumably an object and 
> > > its type _both_ represent the _same_ concept
> >
> > If
> >    Angle : Angle_Type;
> > is the only object of Angle_Type,
> 
> Nope, that's a nice strawman, but that's not my position at all, 
> you're reading that into what I said.  "Angle" is not necessarily 
> the only Angle_Type object _in the program_, but it may be the only
> Angle_Type object _in a given local scope_.  In that local context, 

So you are suggesting I have independent objects all named "Angle"
all over the place?

> why should I be forced to call that object anything other than the
> simple word "Angle"?

My answer is in the last two lines of this post (not counting .sig)

> > then perhaps the declaration of
> > Angle_Type is just clutter.  (See my recent post about anonymous
> > array types.)  But "Angle" is rather vague.  Might we in the future
> > want to deal with more than one Angle?
> >
> > The "same concept" argument could be interpreted to recommend:
> >
> >    Angle_1   : Angle_1_Type;
> >    Angle_2   : Angle_2_Type;
> >    Sum_Angle : Sum_Angle_Type;
> > .....
> >    Sum_Angle := Sum_Angle_Type (Angle_1) + Sum_Angle_Type (Angle_2);
> 
> Again, quite a pretty strawman. (I can't believe you are being serious
> here.)  

Straw(_Type) has nothing to do with it.  I am not trying to start a 
flame war, but just to discuss different approaches.  You apparently 
need to clarify, "presumably an object and  its type _both_ represent
the _same_ concept"

> Of course you can have as many Angle_Type objects as you like,
> prefixing (or even suffixing) the "Angle" word with whatever 
> "specific" modifiers you like, e.g.,
> 
>    Start_Angle, End_Angle, Rotation_Angle : Angle_Type;
 [snip]
> My scheme has the advantage that a "specific" identifier such as
> "Start_Angle" is clearly the name of an object, ....

...(and "specific" is the way AQS recommends making the distinction)...

> ... and can never be confused as the name of a "specific" derived- 
> or sub-type of  Angle_Type.  

in a group of statements, it's rather hard to confuse _any_ identifier
as the name of any (sub)type.  It's also difficult to misinterpret 
whether a colon is to the left or right of the identifier.  Where
besides in a few pragmas) is such confusion possible?

> > If "adding any more information is _undesirable_" then I would say
> > that a language construct that _must_ be there (though it adds nothing)
> > is either a flaw in the language or (more likely) a sign that the
> > program still needs some abstract thought.
> 
> Go back a couple posts and look again.  I was objecting to Jeff Carter's
> suggestion of a whole smorgasbord of different type-marking suffixes for
> the different classes of types. For example, for a floating point type,
> you might have something like (not one of Jeff's examples but similar):

In other words, you object to a recommendation that we _avoid_ 
"information hiding"  :-)  I object to that even more than I object to
a blanket "_Type" suffix.  I use "_Type" myself once in a while (on this
project, alwaysm its the law :-) ) but I still hold to my opinions that
it
is usually just five characters of "noise".  In fact, I consider it
usually
a milder form of the same sin you say Jeff promoted.

> >    Start_Point, Rotation, End_Point : Angle;
> > .....
> >    End_Point := Start_Point + Rotation;
> 
> The synonym scheme again.  This blithe violation of semantic economy
> will cost you later if you decide to use the word "Point" to refer to a
> two-dimensional cartesian-coordinate vector, and use "Rotation" to refer
> to a rotational transformation matrix.  It may be wiser to be thrifty
> with your semantics from the start, and simply retain the word "Angle"
> in your objects of Angle_Type:
> 
>   Start_Angle, Rotation_Angle, End_Angle : Angle_Type;

"Synonyms" are not the Point :-) "Angle" would actually have been better 
than "Point"  Either way, there's still no need for "_Type" to make the
identifiers unique.  

The "_Type" suffix has been mandated by more than one project
coding standard at more than one company.  When on such a project, 
I comply.  Nevertheless, the syntax almost always makes it plain 
which identifiers are (sub)types and which are objects, so "_Type" 
adds no meaning.  The extra keystrokes are better used where they 
_do_ add information.  THAT is what _I_ call "semantic economy."

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Sorry I got abrasive before, I don't really mean to start a flame war
either.  But to address your points:

W. Wesley Groleau (Wes) wrote:
> 
> So you are suggesting I have independent objects all named "Angle"
> all over the place?

Sure. Why not?

  package Angles is

    type Angle_Type is digits ...;  -- in degrees

    subtype Proper_Angle_Type is
      Angle_Type range 0.0 .. Angle_Type'Pred(360.0);

    subtype Signed_Angle_Type is
      Angle_Type range -180.0 .. Angle_Type'Pred(+180.0);

    -- Angle_Type primitives (inheritable on derivation):

    function Get_Complement     -- = 90 - Angle
      (Angle : in Angle_Type)
       return Angle_Type;

    function Get_Supplement     -- = 180 - Angle
      (Angle : in Angle_Type)
       return Angle_Type;

    function Get_Proper_Form    -- a kind of "abs" for angles
      (Angle : in Angle_Type)
       return Proper_Angle_Type;

    function Get_Signed_Form    -- a kind of "abs" for angles
      (Angle : in Angle_Type)
       return Signed_Angle_Type;

    ...
  end Angles;

Here are at least 4 functions that contribute to an abstraction for
Angles, there may be many more.  Each of these functions takes an Angle
and transforms it in some way.  What shall we name the parameter in
each? With "Angle_Type" as the name of the type, the simple name "Angle"
is available.  But if the type were already named "Angle", we'd have to
find something else for the parameters.  Should it be "The_Angle", as
Booch would suggest?  Do we have to resort to barbarous abbreviations
such as "Ang" or "A"?  Do we need to spend (i.e., waste) time hunting
around for synonym for "Angle"? 

> You apparently
> need to clarify, "presumably an object and  its type _both_ represent
> the _same_ concept"

Maybe taking an example will help: What we have here is the concept of
an "Angle" -- what one is, and what we can do with one. We have a
package that encapsulates this concept, a type that implements a data
abstraction for this concept, and formal parameters standing for
instances of this concept being acted upon by primitive subprograms. 
One concept, versus multiple program entities all needing names that
don't clash.

Semantic economy means that I should only need to decide on the word
that stands for the concept ("Angle"). At that point, the creative work
of naming should be done, end of story.  The names for the program
entities should fall out automatically, without mental work:

  concept: "Angle"  -->  instance:  "Angle"
                    -->  type:      "Angle_Type"
                    -->  package:   "Angles"


> > Of course you can have as many Angle_Type objects as you like,
> > prefixing (or even suffixing) the "Angle" word with whatever
> > "specific" modifiers you like, e.g.,
> >
> >    Start_Angle, End_Angle, Rotation_Angle : Angle_Type;
>  [snip]
> > My scheme has the advantage that a "specific" identifier such as
> > "Start_Angle" is clearly the name of an object, ....
> 
> ...(and "specific" is the way AQS recommends making the distinction)...
> 
> > ... and can never be confused as the name of a "specific" derived-
> > or sub-type of  Angle_Type.
> 
> in a group of statements, it's rather hard to confuse _any_ identifier
> as the name of any (sub)type.  It's also difficult to misinterpret
> whether a colon is to the left or right of the identifier.

Once correctly written and successfully compiled, that may be true.  But
when an author is actually in the process of writing the abstraction (or
even some client code that uses the abstraction) keeping track of which
identifiers stand for the types, vs the packages, vs the
objects/parameters, vs the primitive subprograms, is easier to do if the
distinctions between the identifiers follow simple systematic rules.

> Where besides in a few pragmas) is such confusion possible?

Booch-like style:

  package Angle_Set is new Set
    (Item  => Angle,
     Count => Angle_Count); -- is this a type or a constant?

Cohen-like style:

  package Angle_Sets is new Sets
    (Item_Type  => Angle_Type,
     Count_Type => Angle_Count_Type);

But, more important than any confusion on the page, there's the
confusion in the mind, when the software is thought about or discussed.
Although Robert Dewar has made the point that source code
editors/browsers with cross-reference capabilities now make it easier to
trace back to the original definition of an identifier, IMHO if the only
reason you're bouncing back to the definition is just to recall what
various things were named, then it's a waste, no matter how facilitated
the bouncing.  Better if you didn't have to bounce at all, but instead
could just rely on a naming system that only requires you to remember
what _concepts_ (object classes) you have in your application.

(Clarification: I do think that this kind of cross reference browsing
feature is useful, when it's applied to helping the reader understand
the _semantics_ of the program, rather than just surface aspects like
naming. For example, bouncing back to a type declaration to see what
record components it contains, or bouncing to the body of a procedure to
see exactly what algorithm is implemented there.)
 
> In other words, you object to a recommendation that we _avoid_
> "information hiding"  :-) 

Quite.

> I object to that even more than I object to a blanket "_Type" suffix.

Good.

> I use "_Type" myself once in a while (on this
> project, alwaysm its the law :-) ) but I still hold to my opinions that
> it
> is usually just five characters of "noise". 

Seems like quantum mechanics must apply to software, because this noise
appears to be irreducible given the structure of the language.  (To me,
abbreviations are noise. :-) ) We're forced to distinguish identifiers
somehow, but any distinction means adding some amount of noise. I just
think distinctions that are self-evident in the surface form (syntax) of
the identifiers is less mental work distinctions buried in the meanings
(i.e. semantics) of the identifiers (e.g., "specific" vs. "general").

My question to you is this: is the "The_" in "The_Angle" noise?  

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Do-While Jones]

Speaking from a maintenance point-of-view, I certainly prefer

  package Angles is

    type Degrees is digits ...;

to

>  package Angles is
>
>    type Angle_Type is digits ...;  -- in degrees

because it eliminates the need to "grep Angle_Type angles.ads" to see if a
variable of Angle_Type (declared in a different package) is expressed in 
degrees or radians. 

Never express in a comment that which can be expressed in the code.

  DIRECTION : Angles.Degrees;

is safer than

  DIRECTION : Angles.Angle_Type; -- in degrees

Furthermore, one is more likely to make this mistake:

  THETA_IN_RADIANS : Angles.Angle_Type;

than to make this mistake:

  THETA_IN_RADIANS : Angles.Degrees;

Do-While Jones

-- 
Science Against Evolution is a California Public Benefit Corporation whose
objective is to make the general public aware that the theory of evolution
is not consistent with physical evidence and is no longer a respectable
theory describing the origin of life. 

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Stephen Leake]

Do-While Jones wrote:
> 
> Speaking from a maintenance point-of-view, I certainly prefer
> 
>   package Angles is
> 
>     type Degrees is digits ...;
> 
> to
> 
> >  package Angles is
> >
> >    type Angle_Type is digits ...;  -- in degrees
> 
> because it eliminates the need to "grep Angle_Type angles.ads" to see if a
> variable of Angle_Type (declared in a different package) is expressed in
> degrees or radians.

But this package does not prevent someone from writing:

	Angle_In_Radians : Angles.Degrees := Item / 360.0;

If you are trying to enforce units, you need a private type. But then
you need a system of private types providing all units, so this is not
an isolated case.
 
> 
> Never express in a comment that which can be expressed in the code.
> 

More importantly, don't pretend you are providing an abstraction that
you are not!

> 
> Do-While Jones
> 

-- 
- Stephe

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Do-While Jones wrote:
> 
> Speaking from a maintenance point-of-view, I certainly prefer
> 
>   package Angles is
> 
>     type Degrees is digits ...;

Do-While, you're running the risk here of resurrecting another
unkillable thread... :-)  My emphasis has been that if you have a clear
abstraction (=concept=object class) then naming should just fall out of
that.  People have been side-tracking this point by moving the
abstraction boundaries around. If I answer this, I run the risk of yet
another tangent.

Oh, well, here goes anyway:

What if the units are an implementation detail that you want to hide? 
What if you decide later that, for efficiency reasons, all Angles are
best implemented in radians rather than degrees?  Then your suggestion
would lie closer to the Hungarian end of the naming spectrum: encoding
implementation details in the name.

  with Unitless;
  package Angles is

    type Angle_Type is private;
    -- Going with a private type is a tough decision here.
    -- I'm not necessarily recommending it.  An alternative
    -- could be to make this a visible float type and just
    -- override as abstract any built-in functions (e.g. "*")
    -- that violate unit dimensionality. But as an academic
    -- exercise, let's see where this leads us ...

    function "*"
      (Left  : Unitless.Quantity_Type;
       Right : Angle_Type)
       return Angle_Type;

    function "*"
      (Left  : Angle_Type;
       Right : Unitless.Quantity_Type)
       return Angle_Type;

    function "/"
      (Left  : Angle_Type;
       Right : Angle_Type)
       return Unitless.Quantity_Type;

    ... -- etc.

    -- the following are functions rather than constants
    -- in order to make them inheritable

    function Zero return Angle_Type;

    function Degree return Angle_Type;

    function Radian return Angle_Type;

    function Cycle return Angle_Type;
    -- = 360.0*Degree = 2.0*Pi*Radian

    function Hemicycle return Angle_Type;
    -- = 180.0*Degree = Pi*Radian

    function Quadrant return Angle_Type;
    -- = 90.0*Degree = 0.5*Pi*Radian

    ... etc.

    function Get_Complement     -- = Quadrant - Angle
      (Angle : in Angle_Type)
       return Angle_Type;

    function Get_Supplement     -- = Hemicycle - Angle
      (Angle : in Angle_Type)
       return Angle_Type;

    function Get_Proper_Form    -- a kind of "abs" for angles
      (Angle : in Angle_Type)
       return Proper_Angle_Type;

    function Get_Signed_Form    -- a kind of "abs" for angles
      (Angle : in Angle_Type)
       return Signed_Angle_Type;

    ... -- etc.
  end Angles;
 
> Never express in a comment that which can be expressed in the code.
> 
>   DIRECTION : Angles.Degrees;
> 
> is safer than
> 
>   DIRECTION : Angles.Angle_Type; -- in degrees

Or perhaps:

  with Angles;
  package Directions is

    type Direction_Type is new Angles.Proper_Angle_Type;

    function North return Direction_Type renames Zero;

    function Northeast return Direction_Type;
    -- = 45.0*Degree = 0.5*Quadrant

    function East return Direction_Type renames Quadrant;
    -- = 90.0*Degree

    function Southeast return Direction_Type;
    -- = 135.0*Degree = 1.5*Quadrant

    function South return Direction_Type renames Hemicycle;
    -- = 180.0*Degree = 2.0*Quadrant

    ... -- etc.

  end Directions;


And then somewhere:

  Direction : Directions.Direction_Type;
  -- I don't care what the units are,
  -- the abstraction protects me from them


> Furthermore, one is more likely to make this mistake:
> 
>   THETA_IN_RADIANS : Angles.Angle_Type;
> 
> than to make this mistake:
> 
>   THETA_IN_RADIANS : Angles.Degrees;
> 

Or perhaps:

    Theta_Angle : Angles.Angle_Type;
    -- I don't care what the units are,
    -- the abstraction protects me from them

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

John G. Volan wrote:
> 
>     function Get_Proper_Form    -- a kind of "abs" for angles
>       (Angle : in Angle_Type)
>        return Proper_Angle_Type;
                ^^^^^^^^^^^^^^^^^

Woops, I forgot that if I make Angle_Type private I lose the ability to
have visible constrained subtypes.  Should be:

      function Get_Proper_Form
        (Angle : in Angle_Type)
         return Angle_Type;

      function Is_Proper_Form   -- substitutes for 
        (Angle : in Angle_Type) -- subtype membership test
         return Boolean;

>   with Angles;
>   package Directions is
> 
>     type Direction_Type is new Angles.Proper_Angle_Type;
> 

Should be:

      type Direction_Type is new Angles.Angle_Type;

      function Is_Valid -- i.e., as a Direction
        (Direction : in Direction_Type)
         return Boolean
        renames Is_Proper_Form;

      function Get_Valid_Form -- i.e., for a Direction
        (Direction : in Direction_Type)
         return Direction_Type
        renames Get_Proper_Form;

      ...

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Tangent to Religious naming convention discussion ......

[W. Wesley Groleau (Wes)]

John G. Volan wrote:
>   with Unitless;
>   package Angles is
> 
>     type Angle_Type is private;

This is an excellent approach (though in itself it doesn't
support the "_Type" concept--to lessen :-) the "tangent").
Just make sure you provide the clients with something like

  function Degrees ( From : Angle[_Type] ) return Float;
  -- or at least
  function Degrees_Image ( From : Angle[_Type] ) return String;

>     -- Going with a private type is a tough decision here.

There is a disadvantage (easily overcome) to losing the use of
attributes, .... 

>     -- I'm not necessarily recommending it.  An alternative
>     -- could be to make this a visible float type and just
                                 ^^^^^^^^^^^^^^^^^^
>     -- override as abstract any built-in functions (e.g. "*")
>     -- that violate unit dimensionality. 

.... but this way some fool is sure to peek into your package 
body and, taking advantage of the "fact" that you implemented in 
Radians, write something like:

  Put_Line ( "Heading:" & 
             Integer'Image ( Integer ( Heading * 180.0 / Pi ) ) );

Before we go off on _another_ tangent about engineering discipline,
remember that many software "engineers" develop a strange form of
insanity when managers start grumbling about schedules..... 

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Tangent to Religious naming convention discussion ......

[John G. Volan]

W. Wesley Groleau (Wes) wrote:
> 
> John G. Volan wrote:
> >   with Unitless;
> >   package Angles is
> >
> >     type Angle_Type is private;
> 
> This is an excellent approach (though in itself it doesn't
> support the "_Type" concept--to lessen :-) the "tangent").
> Just make sure you provide the clients with something like
> 
>   function Degrees ( From : Angle[_Type] ) return Float;
>   -- or at least
>   function Degrees_Image ( From : Angle[_Type] ) return String;

Float may not be very appropriate if Angle_Type isn't implemented with
Float.  I was assuming that Unitless.Quantity_Type was a floating-point
type with some connection to Angle_Type's implementation.

Technically speaking, the functionality you suggest is already provided
by "/":

  Degrees_Quantity : Unitless.Quantity_Type :=
    Some_Angle / Degree;  -- angle / angle = unitless
  -- Since we're reducing this to a unitless coefficient with
  -- the "angle" dimension stripped off, we now have to keep
  -- track of what units we used to reduce it, hence the 
  -- encoding of "Degrees" in the name.

The reverse operation is "*":

  Some_Angle : Angle_Type := Degrees_Quantity * Degree; 
    -- unitless * angle = angle

For efficiency reasons, however, I can see the rationale for avoiding
division as the method for doing the reduction (especially if the
internal units happen to be degrees), but if you're going to include
functions like the one you suggested, they should be written in terms of
Unitless.Quantity_Type:

   function In_Degrees
     (Angle : Angle_Type)
      return Unitless.Quantity_Type;
      --     ^^^^^^^^^^^^^^^^^^^^^^

   Degrees_Quantity : Unitless.Quantity_Type :=
     In_Degrees (Angle => Some_Angle);


In other words, the Angles package is part of an integrated subsystem of
dimensional units packages, with Unitless providing a floating-point
"unitless" Quantity_Type which acts as the common numeric currency for
the subsystem.  "Unitful" private types such as Angle_Type presumably
use Quantity_Type as their underlying representation, either by being
privately derived from it or perhaps being records with one
Quantity_Type component.

Unitless.Quantity_Type might very well be (an unconstrained subtype of)
Float'Base, or derived from Float'Base, or it might be some user-defined
float, or it might be (hint-hint) derived from some generic formal
floating point type parameter defining the floating-point representation
for the subsystem.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

naming convention discussion

[Peter Hermann]

John G. Volan (johnvolan@sprintmail.com) wrote:
:   package Angles is
[etc]

this contribution was quite interesting to me.
I am just in (infinite) search for the best method for myself.
One thing which I observed on myself was the positive fact,
that when I forced myself to omit the "_type"-extension,
I was indeed forced to think deeper about the correct meaning of
both objects and types of the abstraction;
which in turn led to better names.
You may try it yourself   ;-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: naming convention discussion

[John G. Volan]

Peter Hermann wrote:
> 
> One thing which I observed on myself was the positive fact,
> that when I forced myself to omit the "_type"-extension,
> I was indeed forced to think deeper 

IMHO, thinking deeply about the kind of name distinctions I've been
talking about is wasted effort.

> about the correct meaning of
> both objects and types of the abstraction;

I do that anyway. What you describe is the tail wagging the dog: Use the
great name hunt as the way to force you to analyze your semantics.  I
say, think deep thoughts about the semantics (e.g., do some
object-oriented analysis, build OMT or UML models, etc.), and then let
the names fall out automatically from that.

> which in turn led to better names.
> You may try it yourself   ;-)

Oh, I have, I have. Gave it up as a lost cause... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: naming convention discussion

[Peter Hermann]

John G. Volan (johnvolan@sprintmail.com) wrote:
: Oh, I have, I have. Gave it up as a lost cause... :-)

Although this is certainly the ultimate wisdom for all of us,
I can't stop trying to improve my habits.
Not to strive for this would mean I am old ;-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: naming convention discussion

[John G. Volan]

Peter Hermann wrote:
> 
> John G. Volan (johnvolan@sprintmail.com) wrote:
> : Oh, I have, I have. Gave it up as a lost cause... :-)
> 
> Although this is certainly the ultimate wisdom for all of us,
> I can't stop trying to improve my habits.
> Not to strive for this would mean I am old ;-)
> 
> --
> Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
> Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
> Team Ada: "C'mon people let the world begin" (Paul McCartney)

Clarification: I meant that I gave up on

  good names => good semantics

in favor of 

  good semantics => good names

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: naming convention discussion

[Peter Hermann]

John G. Volan (johnvolan@sprintmail.com) wrote:

:   good names => good semantics

: in favor of 

:   good semantics => good names

   good semantics <=> good names           :-)   :-)   :-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: naming convention discussion

[W. Wesley Groleau (Wes)]

> I can't stop trying to improve my habits.
> Not to strive for this would mean I am old ;-)

Thanks--I was looking for an excuse to stop trying  :-)
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Not Yet Fifty But On The Way                       Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

John Volan says

<<"John G. Volan" <johnvolan@sprintmail.com> writes:
...
>I only wish the original designers of Ada83 had clued into this style
>from the start.  I find myself wishing Ada95 looked more like this:

>    Integer   : Integer_Type;
>    Natural   : Natural_Type;
>    Float     : Float_Type;
>    Boolean   : Boolean_Type;
>    Character : Character_Type;
>    String    : String_Type;
>    Duration  : Duration_Type;>>

It really is remkarable how some people can take a good idea, and then
kill it by applying it in a completely blind manner. Assuming (a bit
of a reach) that the above is NOT meant as humour, I really find it
hard to believe that anyone would prefer Integer_Type to Integer.
For the last 40 years, millions of programmers have read billions or
even trillions of lines of code in which we have a firm convention of
using very simple words like int or Integer for simple predefined types.
Why would anyone want to type extra junk in their program to override
this universal convention?

At the same time, I find it quite reasonable to add a suffix of _Type
in cases which are less familiar and where it helps the reader. For
my view of the dividing line look at the GNAT sources. So for example,
universal integers, which are so pervasive, are called Uint, but
on the other hand, we use Line_Number_Type. I do not see for a moment
that changing Uint to Universal_Integer_Type throughout the GNAT sources
would achieve anything except to make the sources a bit harder to read,
and to increase the size of the tar file!

In its blind use-it-all-the-time mode suggested above, I find the _Type
suffix rule to be similar to the horrible encoding rules that some C
coders use.

P.S. The issue of how much to worry about classification of names like
this quite depends on availabilty of tools. If you have a tool (like
GNAT running under EMACS using GNATF to provide xref information) that
allows you to instantantly locate the defining occurrence of a given
identifier (useful Algol-68 term :-) then the balance shifts in favor
of less encoding.

The trouble is that in choosing a name, we are trying to satisfy two needs
at the same time.

  o  Give maximum help to someone looking at the sources for the first
	time who does not know their way around.

  o  Don't generate too much unnecessary noise for someone who *does* know
        their way around the sources.

Obviously familiarity plays a big role. Every Ada programmer knows the
type name Integer, and therefore changing it to Integer_Type would badly
damage the second objective without helping the first objective.

On the other hand, a less familiar type name may suggest giving more weight
to the first objective.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert Dewar wrote:
> 
> John Volan says
> 
> <<"John G. Volan" <johnvolan@sprintmail.com> writes:
> ...
> >I only wish the original designers of Ada83 had clued into this style
> >from the start.  I find myself wishing Ada95 looked more like this:
> 
> >    Integer   : Integer_Type;
[snip]
> It really is remkarable how some people can take a good idea, and then
> kill it by applying it in a completely blind manner. Assuming (a bit
> of a reach) that the above is NOT meant as humour, I really find it
> hard to believe that anyone would prefer Integer_Type to Integer.
> For the last 40 years, millions of programmers have read billions or
> even trillions of lines of code in which we have a firm convention of
> using very simple words like int or Integer for simple predefined types.
> Why would anyone want to type extra junk in their program to override
> this universal convention?

Obviously I was writing science fiction in trying to describe a parallel
universe where the original Ada83 designers ignored the prevailing
convention of:

    X : INTEGER;

i.e., totally cryptic short variable name inspired by the cryptic
notation of mathematics (because the first applications of computers
happened to be purely mathematical), and required to be different from
the nicely readable simple unmarked type name, because the type name got
the simple unmarked word first.

Well, in this universe, they didn't ignore convention, so we got what we
got, and I can live with that.

The trouble, though, is that the way the standard types are dealt with,
and the style in which the standard packages are written, has had an
influence on programmers, such that it's sometimes hard for them to see
(at first) the utility of adopting a style like the one I described,
meeting the kind of criteria that I described.  So you wind up with
abominations like:

   T : Target;

The usual argument is: "Hey, c'mon, it's not so bad, you and I both know
that T is a target.  It's just like what they did in the RM, so it must
be cool.  Look at the standard packages, man. How come they just use "E"
for an exception identity?  Don't be so uptight, dude..."

And then about 100 lines later the reader is lost in a morass of
statements referencing a dozen or so one- or two-character variable
names, and has no clue what is going on.

> At the same time, I find it quite reasonable to add a suffix of _Type
> in cases which are less familiar and where it helps the reader. For
> my view of the dividing line look at the GNAT sources. So for example,
> universal integers, which are so pervasive, are called Uint, but
> on the other hand, we use Line_Number_Type. I do not see for a moment
> that changing Uint to Universal_Integer_Type throughout the GNAT sources
> would achieve anything except to make the sources a bit harder to read,
> and to increase the size of the tar file!

I do not object at all to a project choosing a set of abbreviations as
an internal convention, as long as they document them and are
consistent.  But what is consistency?  Remember my notion of "semantic
economy".  I would have said, if "Uint" makes a good label for the
concept of "universal integer", why resort to another, less informative
label (perhaps "U" for a variable name) for the same concept?  Why not
use that label in every context refering to "universal integers",
including both the type name and a representative object name:

	Uint : Uint_Type;

Now would that _really_ have made the tar file all that much bigger? And
is the tar file size really such an overriding concern?  If so, then why
bother with such a long name as "Line_Number_Type"?  Why not just
"Line_Type" or even "LN_Type" (of course, with documentation somewhere
stating that "LN" is your project abbreviation for "Line_Number").  That
way, instead of having:

    Line_Number : Line_Number_Type; -- good, but maybe too verbose

or

    L : Line_Number_Type; -- bad, information loss, semantically
uneconomical

you could have:

    Line : Line_Type; --good

or even:

    LN : LN_Type; -- okay, but only with prominent documentation

Although I have tried to show how some aspects of the name selection
process can be rendered mechanical, nevertheless there is still room for
it to be something of an art form.

> In its blind use-it-all-the-time mode suggested above, I find the _Type
> suffix rule to be similar to the horrible encoding rules that some C
> coders use.

I'm surprised you didn't raise the old canard, "A foolish consistency is
the hobgoblin of small minds."  (This is sometimes misunderstood to mean
that all consistency is foolish, or that any uncompromising consistency
is foolish. This is clearly not true: My heart has been beating
consistently for almost 36 years, and I am quite glad it has not chosen
to compromise on that at _any_ point! :-)

But really, taking the scheme I described and comparing it to certain C
conventions (I assume you must be referring to Hungarian Notation) is
quite unfair. You might have noticed that I have been arguing in favor
of _minimal_ encoding -- just what is needed to distinguish identifiers
to make the compiler happy, without forcing the programmer to think up
multiple words (or resort to _arbitrary_ abbreviations) for the same
concept (in short, "semantic economy.")  I certainly don't subscribe to
the notion that a type or object name must encode _all_ implementation
details, like what size integer it is or whether its signed or unsigned,
and so forth. (Certainly not given Ada's type model.)

> P.S. The issue of how much to worry about classification of names like
> this quite depends on availabilty of tools. If you have a tool (like
> GNAT running under EMACS using GNATF to provide xref information) that
> allows you to instantantly locate the defining occurrence of a given
> identifier (useful Algol-68 term :-) then the balance shifts in favor
> of less encoding.
>
> The trouble is that in choosing a name, we are trying to satisfy two needs
> at the same time.
> 
>   o  Give maximum help to someone looking at the sources for the first
>         time who does not know their way around.
> 
>   o  Don't generate too much unnecessary noise for someone who *does* know
>         their way around the sources.
> 
> Obviously familiarity plays a big role. Every Ada programmer knows the
> type name Integer, and therefore changing it to Integer_Type would badly
> damage the second objective without helping the first objective.

Of course I was not seriously suggesting changing something like
"Integer", not at this stage. The only way to change such a massive
convention would be to go back and change history itself, but
unfortunately the last time the Enterprise bounced back to the 20th
century, they neglected to leave behind any temporal-anomaly generators.
:-)

> On the other hand, a less familiar type name may suggest giving more weight
> to the first objective.

Hmm. "Familiarity" is such a subjective criterion, kind of hard to pin
it down as a simple set of rules for a naming convention.  One man's
second nature can be another man's alien jargon.  De gustabus non
disputandum est.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Robert Dewar]

John suggests

<<        Uint : Uint_Type;>>

UGH! No, I don't like that at all. Why choose a name for an object that
emphasizes the type of the object. I choose my object names to emphasize
the use of the variable at a higher level of abstraction.

Suppose I have a universal integer value that is the size of operand 1.
Then I would never write the above line, instead I would write:

    Opnd1_Size : Uint;


Similarly, I cannot imagine calling a variable Integer, so where you
suggest

    Integer : Integer_Type;

I would far prefer to write:

    Number_Of_Attempts : Integer;

I have *never* wanted to call a variable Integer, and that is why in this
case Integer is the right name for the type.

On the other hand, there are cases where there is little separation between
the abstraction levels of the type and its use, e.g. when you have an
enumeration type where there is only one instance of the type, as in

   type System_Status_Type is (Going, Stopped, Terminating, Starting);
   System_Status : System_Status_Type;

in this case, a standard suffix is appropriate, and I favor using _Type
as the suffix in a case like this.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert Dewar wrote:
> 
> John suggests
> 
> <<        Uint : Uint_Type;>>
> 
> UGH! No, I don't like that at all. Why choose a name for an object that
> emphasizes the type of the object. I choose my object names to emphasize
> the use of the variable at a higher level of abstraction.
>
> Suppose I have a universal integer value that is the size of operand 1.
> Then I would never write the above line, instead I would write:
> 
>     Opnd1_Size : Uint;

I see the misunderstanding now.  I thought you were talking about the
case where you were dealing with "universal integer" as the syntactic
element currently being compiled, similar to "statement", "expression",
etc.  If that were the case, then in fact "universal integer" would _be_
the abstraction, and my suggestion would be appropriate.

But here it seems you are just dealing with a data component of some
other abstraction, and that component happened to be implemented using
your internal representation for a universal integer.

In that case, I wonder why expose the particular implementation of that
value?  It could be that a later design change results in that value
being implemented differently.  How about:

    Operand_1_Size : Operand_Size_Type;

or better:

    type Operand_Type is ...
      record
        ...
        Size : Operand_Size_Type;
        ...
      end record;
    ...
    Operand_1 : Operand_Type; -- now can reference Operand_1.Size


Operand_Size_Type might be derived from Uint, or it might just be a
subtype of Uint, or it might (long shot) be a private type that hides a
Uint, or... ah, but I see this opens up a whole other can of worms. 
It's the old apples and oranges question, and what's an apple versus an
orange, and when do you really need distinct types?  I won't try to
argue the exact design decision you made here...

Yes, if you decide to give one implementation type such broad usage
without distinguishing different usages as distinct types/subtypes, then
of course the variable names should not reflect the implementation.

> Similarly, I cannot imagine calling a variable Integer, so where you
> suggest
> 
>     Integer : Integer_Type;
> 
> I would far prefer to write:
> 
>     Number_Of_Attempts : Integer;

Isn't it bad form to over-use the standard integer types?  Again, the
apples and oranges question.  In this case, I might have done:

   type Try_Count_Type is range 0 .. Try_Limit;
   -- Try_Limit might change, changing the implementation needed.
   -- Also, want to distinguish this from e.g. Error_Ident_Type.

   Try_Count : Try_Count_Type;

> I have *never* wanted to call a variable Integer, and that is why in this
> case Integer is the right name for the type.

The cases I had in mind where you might want to do this are in defining
the abstraction for "integer" itself, e.g.:

    function "-" (Integer : in Integer_Type) return Integer_Type;

    function Integer_Type'Succ (Integer : in Integer_Type)
      return Integer_Type;

similarly:

    function "not" (Boolean : in Boolean_Type) return Boolean_Type;

    function Float_Type'Ceiling (Float : in Float_Type)
      return Float_Type;

I can see this is a bit of a stretch: Is the real abstraction here the
type being manipulated, or the functions themselves? I.e., is it more
important in this case to emphasize which data abstraction the parameter
implements, or is it more important to emphasize the role the parameter
plays within the function, actually re-using the same role names across
all the overloadings of the function?  E.g., our current situation:

  function "<" (Left, Right : Integer) return Boolean;
  function "<" (Left, Right : Float)   return Boolean;
  function "<" (Left, Right : String)  return Boolean;
  ...

versus the hypothetical:

  function "<" (Integer, Than_Integer : Integer_Type) return Boolean;
  function "<" (Float,   Than_Float   : Float_Type)   return Boolean;
  function "<" (String,  Than_String  : String_Type)  return Boolean;

The fundamental question here is, when we deal with the built-in types
and their operations, are we dealing with purely functional
abstractions, or can we view these types as data abstractions comparable
to typical abstract data types (Set, List, Queue, etc.)?

If the latter, my naming convention can be made to fit them. If the
former, my scheme is inapplicable.

> On the other hand, there are cases where there is little separation between
> the abstraction levels of the type and its use, e.g. when you have an
> enumeration type where there is only one instance of the type, as in
> 
>    type System_Status_Type is (Going, Stopped, Terminating, Starting);
>    System_Status : System_Status_Type;
> 
> in this case, a standard suffix is appropriate, and I favor using _Type
> as the suffix in a case like this.

Glad to see you agree... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[W. Wesley Groleau (Wes)]

> ....  So you wind up with abominations like:
> 
>    T : Target;
> 
> The usual argument is: "Hey, c'mon, it's not so bad, you and I both 
> know that T is a target.  It's just like what they did in the RM, so 
> it must be cool.  Look at the standard packages, man. How come they 
> just use "E" for an exception identity?  ...."

This (and a recent post about AQ&S not following its own guidelines)
illustrates a principle of documentation:  People follow examples,
not guidelines.  In other words, "Do as I say, not as I do" almost
never works!

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[W. Wesley Groleau (Wes)]

Robert Dewar wrote:
> The trouble is that in choosing a name, we are trying to satisfy two 
> needs at the same time.
> 
>   o  Give maximum help to someone looking at the sources for the 
>      first time who does not know their way around.
> 
>   o  Don't generate too much unnecessary noise for someone who *does* 
>      know their way around the sources.

The trouble with "letting rules substitute for judgment" is that you
end up generating unnecessary noise for _both_ groups but not giving
much help to either! 

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Robert Dewar wrote:
> The trouble is that in choosing a name, we are trying to satisfy two
> needs at the same time.
>
>   o  Give maximum help to someone looking at the sources for the
>      first time who does not know their way around.
>
>   o  Don't generate too much unnecessary noise for someone who *does*
>      know their way around the sources.

There is also:

    o  Give the original author a semantic framework that he can hang
       his concepts on, clear the cobwebs out of his own thinking,
       and actually write the code he intends to write without losing
       track of what he's doing with what...

W. Wesley Groleau (Wes) wrote:
> 
> The trouble with "letting rules substitute for judgment" is that you
> end up generating unnecessary noise for _both_ groups but not giving
> much help to either!

This is misguided.  There should be no need to waste energy on
"judgment" regarding aspects of software development that ought to be
_purely mechanical_. For example, once a software designer has
identified the concepts (object classes) that make up an application,
generating names for the program elements that implement those concepts
should be automatic, and not require any "judgement."  The engineer's
"judging" faculties are better spent on more important issues, such as
actually implementing the data structures and algorithms that are to be
affixed to these names.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Doug Smith]

In article <3373666A.31DFF4F5@spam.innocon.com>, Jeff Carter <carter@spam.innocon.com> wrote:
[snip]
> Now, allow me to indoctrinate you into the one true religion. Like you,
> I want to preserve the meaningful name (List, Queue, What_Ever) for use
> by objects and parameters. Unlike you, I insist that suffixes add at
> least some information. So I want my suffix to indicate what kind of
> type we're dealing with, as well as differentiating the type name. I use
> many; here are a few:
> 
> Numeric types: _Value, _Count, _Range
> Enumeration types: _Id, _Name
> Array types: _Set, _List
> Record types: _Group, _Data, _Info
> Task types: _Agent, _Controller
> Private types: _Handle
> 
> I'm also creative in my use of parameter names, using Into, Before,
> After, From, To, and so on to avoid as much of this as I can:
> 
> procedure Insert (Into : in out String; Before : in Positive; Value : in
> String);
> procedure Append (Onto : in out List_Handle; After : in Position; Item :
> in Element);
[snip]
> -- 
> Jeff Carter  PGP:1024/440FBE21

Several years ago, I found an excellent article on user interface design
in Smithsonian magazine (no that is not a typo!) Two of the three
principles were: 1) Make usage obvious, and 2) Use conventions. Other
posters have applied these principles, but I like Jeff's usage of the
suffix much better.

Let me go a little further. We have not addressed the semantics issue
very well. I think Jeff's reference to private type handles alludes to
object semantics. If a naming convention grows out of certain common
semantics, then usage will be more obvious. For example, I might
expect certain operations and associated semantics with any type which
has the _Set suffix. By convention, I would expect the union and
intersection operations and the the default value of Null, etc.

This naming convention may apply also to package names, as Booch
used in his reusable components (although I found the architecture
cumbersome). Then, as Jeff suggests, the suffix can distinguish
between types, especially related types used in the same package such
as _Info and _Handle. In fact, I have seen and used the suffix alone:
Object, Class, or Handle.

It is unlikely we will agree on any community-wide convention, but
at least each reusable library should have some "foolish" consistency.

Now to argue the other side, when there are no conventions which
describe a type's semantics, then don't use a suffix: use a descriptive,
general name.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Tom Moran]

> So why not use
> the shortest possible suffix, 2 characters: _T?
  The plural, commonly just the letter "S", is even shorter.
Doodad, Gewgaw, Thingamajig : Widgets;

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Wayne Magor]

Jeff Carter <carter@spam.innocon.com> writes:
>Jay Martin wrote:
>> 
>> "John G. Volan" <johnvolan@sprintmail.com> writes:
>> ...
>> >I only wish the original designers of Ada83 had clued into this style
>> >from the start.  I find myself wishing Ada95 looked more like this:
>> 
>> >    Integer   : Integer_Type;
>> >    Natural   : Natural_Type;
>> >    Float     : Float_Type;
>> >    Boolean   : Boolean_Type;
>> >    Character : Character_Type;
>> >    String    : String_Type;
>> >    Duration  : Duration_Type;
>
>But it wastes fewer characters than the equally ugly _Type.


Using _Type *is* ugly, but we use it fairly often anyway.  Requiring it in
coding standards is a very bad idea.  Sure, it is mechanical, but it does
not allow the very natural Units package we typically use.  Example:

     Altitude : Units.Feet;
     Latitude : Units.Radians;
     Rate     : Units.Hertz;

It's pretty important to know that Altitude is in feet and not nautical miles
or meters.  It's also pretty important to know what is in Degrees and what
is in Radians.  This is the most straightforward and elegant solution, IMHO.


>Numeric types: _Value, _Count, _Range
>Enumeration types: _Id, _Name
>Array types: _Set, _List
>Record types: _Group, _Data, _Info
>Task types: _Agent, _Controller
>Private types: _Handle


These are fairly natural, I can find many examples of those exact uses in
our software, however, as I stated above, requiring type names with those
suffixes is not wise.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

Wayne Magor wrote:
> 
>      Altitude : Units.Feet;
>      Latitude : Units.Radians;
>      Rate     : Units.Hertz;
> 
> It's pretty important to know that Altitude is in feet and not nautical miles
> or meters.  It's also pretty important to know what is in Degrees and what
> is in Radians.  This is the most straightforward and elegant solution, IMHO.

I'll say it again: If something is important enough to say in the type,
then it's just as important to say it in the object names, too:

   Altitude_Feet    : Units.Feet;
   Altitude_Meters  : Units.Meters;

   Latitude_Radians : Units.Radians;
   Latitude_Degrees : Units.Degrees;

   Rate_Hertz       : Units.Hertz;
   Rate_Megahertz   : Units.Megahertz;

If you're using many different units for the same kinds of quantity, all
in the same program, then it's important to keep them all straight.

But this pattern is basically just Booch style:

   <specific_modifier>_<general_noun> : <general_noun>;

(For example "Altitude" can be seen as the specific modifier attached to
the general noun "Feet".)

Now, if you can guarantee me that you'll always be attaching some
modifier or other, then this approach is workable.  (Just don't ask me
to try this sort of thing on my object-oriented abstractions... "The_"
is just noise.)

On the other hand, if your project intends to settle on _one_ standard
universal unit for each type of quantity (a good idea anyway), then
embedding the unit name in the objects, or the types, or both, is just
noise (i.e., Hungarianism).  Better to just say, a la Booch:

   The_Altitude : Altitude;
   The_Latitude : Latitude;
   The_Rate     : Rate;

or, a la Cohen: 

   Altitude : Altitude_Type;
   Latitude : Latitude_Type;
   Rate     : Rate_Type;

Sure, it'll take discipline to always keep to the project-standard
units. But (short of wrapping these up as private types) keeping to the
units would take discipline _anyway_. Just because the type name says
"Feet" doesn't guarantee programmers will always remember to treat them
as feet... but if you think the programmers need reminding, better
remind them with every object!

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Kevin Cline]

wemagor@sym1.cca.rockwell.com (Wayne Magor) wrote:

>It's pretty important to know that Altitude is in feet and not nautical miles
>or meters.  It's also pretty important to know what is in Degrees and what
>is in Radians.  This is the most straightforward and elegant solution, IMHO.

It's not important if direct conversion to or from a numeric type is
impossible.

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[Doug Smith]

In article <6650FD690224F234.CA8B0C59DCFC9927.43A53422559505C5@library-proxy.airnews.net>, clines@delete_this.airmail.net (Kevin Cline) wrote:

> wemagor@sym1.cca.rockwell.com (Wayne Magor) wrote:
> 
> >It's pretty important to know that Altitude is in feet and not nautical miles
> >or meters.  It's also pretty important to know what is in Degrees and what
> >is in Radians.  This is the most straightforward and elegant solution, IMHO.
> 
> It's not important if direct conversion to or from a numeric type is
> impossible.

I am not set on one approach or another. However, I do prefer something like:

with Linear_Measurement;
...
  type Altitude is private;
  function Feet  (Value : in Linear_Measurement.Feet) return Altitude;
  function Miles (Value : in Linear_Measurement.Miles) return Altitude;
  ...
  function Feet  (Value : in Altitude) return Linear_Measurement.Feet;
  function Miles (Value : in Altitude) return Linear_Measurement.Miles;
  ...

This suggests an architecture, but a fully detailed solution would include
some package hierarchy and/or abstract type for handling units without the
need to declare all conversions for all dimensions.

Doug
<mailto:dsmith@clark.net>

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[W. Wesley Groleau (Wes)]

> .... distinction between "general" 
> and "specific" nouns is quite ambiguous and subjective, depending on

True, when you have a spectrum from general to specific, people will
disagree on where the middle is.  That does not invalidate the 
guideline.  "Fido" is more specific than "Dog" which is more specific 
than "Quadruped".  But I wouldn't accuse you of violating the guideline
if you said 
   Fido : Dog;
instead of
   Dog : Quadruped;

> context and point of view. It may take a lot of effort and hours spent
> poring over Roget's Thesaurus hunting for synonyms, and then more

I can not remember ever in ten years of Ada work having to spend hours
poring over a thesaurus!  (But congratulations for knowing the
difference between "poring" and "pouring")

> agonized hours deciding  which synonym is more "general" ....

Nor have I ever done this.  See Quadruped .. Fido above

> "specific". And for what? A percentage of your readers would've made 
> the opposite decision you made, so where does that leave readability?

The fact that I would have chosen

    Fido : Dog;

does NOT mean I would have trouble comprehending

    Dog : Quadruped;

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

  w w g r o l  at  p s e u l t 0 1  dot  f w  dot  h a c  dot  c o m

     SPAM should be sent to   I.want.one@mailbombs.for.idiots.org
 If you don't want to pay $500 (see 47 USC 227), don't send it here.
----------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

W. Wesley Groleau (Wes) wrote:
> 
> > context and point of view. It may take a lot of effort and hours spent
> > poring over Roget's Thesaurus hunting for synonyms, and then more
> 
> I can not remember ever in ten years of Ada work having to spend hours
> poring over a thesaurus!  (But congratulations for knowing the
> difference between "poring" and "pouring")
> 
> > agonized hours deciding  which synonym is more "general" ....
> 
> Nor have I ever done this.

Hyperbole!  It's neat-o!  Amaze your friends!  :-) :-)

Seriously, though: I exaggerated for rhetorical effect, my bad. 
Actually, I only engaged in the Thesaurus exercise _once_, while a
student.  Got old _really_ fast, as you can imagine.  I latched onto the
very first alternative to the synonym scheme that I could find (I think
it was Booch's style).

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

[John G. Volan]

W. Wesley Groleau (Wes) wrote:
> 
> The fact that I would have chosen
> 
>     Fido : Dog;
> 
> does NOT mean I would have trouble comprehending
> 
>     Dog : Quadruped;

These toy examples are cute, but I fail to see how they scale up to a
practical scheme that works in real applications containing multiple
related abstractions that must be carefully disinguished to avoid reader
confusion (and sometimes author confusion).  (For a very small example,
see the Angle/Point/Rotation stuff I wrote in another followup to your
post.) 

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: assign help!!

[Simon Wright]

sampson@nosc.mil (Charles H. Sampson) writes:

>      This has nothing to do with the original poster's issue, but I 
> have to disagree with you on this naming convention.  I much prefer the 
> one advocated by Ada Quality and Style: Type names should be general 
> singular nouns and object names should be specific singular nouns, ex-
> cept for predicates as the names for boolean objects.  (I don't just 
> prefer it.  I had some influence on its being in AQ&S that way.)  The 
> reason is that your program will be more readable AS AN ENGLISH SEN-
> TENCE.  For example
> 
>                        Error_Count : Natural;
> 
> can be read as "Error_Count is a natural number".  It could even be read 
> as "Error_Count: Natural".  Notice also, as the rationale to the naming 
> section of AQ&S says, it's Integer, Boolean, and Character, not Inte-
> gers, Booleans, and Characters.

Must say I agree with you on this one! A pity that AQ&S isn't
consistent, though: see eg Message_Code_Type in 5.4.6, Element_Type in
8.3.3, and many others ..

One point on derived (tagged) types; following someone else's posting
on various types of Track, I find it helps to use the plural form in
the package name and the undecorated singular for the type, eg

package Tracks is
  type Track is abstract tagged private;
..

package Friendly_Tracks is
  type Track is new Tracks.Track with private;
..

package Enemy_Tracks is
  type Track is new Tracks.Track with private;
..

Just my 2p.

Re: assign help!!

[Nick Roberts]

Simon Wright <simon@pogner.demon.co.uk> wrote in article
<x7vyb9n6cn1.fsf@pogner.demon.co.uk>...
> One point on derived (tagged) types; following someone else's posting
> on various types of Track, I find it helps to use the plural form in
> the package name and the undecorated singular for the type, eg
> 
> package Tracks is
>   type Track is abstract tagged private;
> ..
> 
> package Friendly_Tracks is
>   type Track is new Tracks.Track with private;
> ..
> 
> package Enemy_Tracks is
>   type Track is new Tracks.Track with private;
> ..


I find "ing" and "tion" handy:

package Tracking is ...

package Friendly_Tracking is ...

package Enemy_Tracking is ...

package Stacking is ...

package Queuing is ...

package Text_Compression is ...

package Packet_Encoding is ...

and so on.

Nick.