Two simple language questions

Two simple language questions

[Chip Richards]

I hope.

First: It says in the Intro to Ada 9X, in Chapter 2, "General access types can
also be used to program static ragged arrays as for example a table of
messages of different lengths."  Now, I know this has been asked before, some
time ago, but I cannot seem to locate the text of the exchange.  What I want
to know is, exactly what is the syntax for doing this?  I've so far used
allocators, i.e.:

   strs:  StringArr :=
   (
       new string'("Line 1"),
       new string'("Line 2"),
       ...
       new string'("Line the Last")
   );

Which works great, but isn't exactly the "static" ragged arrays mentioned in
the intro.  What I want is something like "Line 1"'access, but of course that
doesn't work, nor have any of the sixteen-umpty variations that I've tried.
The RM just said that in X'access, X must be an aliased view of an object.
Well, hmph.  Hep me, hep me, please.

Second, a bit more of a philosophy question, I think.  I've had a couple of
occasions where I've created Ada95 child packages, and in those packages, I've
wanted to extend enumeration types defined by the parent.  As an example:

   type Colors is ( Red, Green, Blue );

And in the child, I'd like to be able to say

   type More_Colors is new Colors with ( Yellow, Purple );

Except, of course, that isn't Ada.  So, what's considered the best approach to
this sort of thing?  Just re-list the constants of the parent type, and add
the new constants into the list?  Seems a bit repetetive and error-prone to
me, and I was just wondering if I'd missed someone proposing a more elegant
solution.  Or am I really off the rails and missing something totally obvious?

Thanks for your time!

-- 
Chip

Re: Two simple language questions

[Tucker Taft]

Chip Richards (chipr@niestu.com) wrote:

: I hope.

: First: It says in the Intro to Ada 9X, in Chapter 2, "General access types can
: also be used to program static ragged arrays as for example a table of
: messages of different lengths."  Now, I know this has been asked before, some
: time ago, but I cannot seem to locate the text of the exchange.  What I want
: to know is, exactly what is the syntax for doing this?  I've so far used
: allocators, i.e.:

:    strs:  StringArr :=
:    (
:        new string'("Line 1"),
:        new string'("Line 2"),
:        ...
:        new string'("Line the Last")
:    );

: Which works great, but isn't exactly the "static" ragged arrays mentioned in
: the intro.  

Actually, this should work as desired if StringArr is defined
as an array of access-to-constant String.  E.g.:

   type String_Constant_Ptr is access constant String;
   type StringArr is array(Positive range <>) of String_Constant_Ptr;

The implementation advice in the RM (13.11(24)) suggesting that 
access-to-constant types need not support deallocation is meant
to encourage implementations to implement allocators for 
access-to-constant types statically (presuming the initializing
value is compile-time known).  In other words, new String'("Line 1")
should allocate and initialize the space at link-time, and at run-time 
deliver the address of this link-time allocated and initialized 
space.  This is essentially identical to the implementation of string
literals in C/C++.

For what it is worth, the Ada 95 compilers based on our AdaMagic
front end (i.e. Aonix ObjectAda 7.* and Green Hills AdaMulti 95)
follow this implementation model.  I'm not sure about GNAT, OCSystems,
Rational, etc.

: ...
: Chip

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Two simple language questions

[Robert Dewar]

Chip asks

<<First: It says in the Intro to Ada 9X, in Chapter 2, "General access types can
also be used to program static ragged arrays as for example a table of
messages of different lengths."  Now, I know this has been asked before, some
time ago, but I cannot seem to locate the text of the exchange.  What I want
to know is, exactly what is the syntax for doing this?  I've so far used
allocators, i.e.:

   strs:  StringArr :=
   (
       new string'("Line 1"),
       new string'("Line 2"),
       ...
       new string'("Line the Last")
   );

Which works great, but isn't exactly the "static" ragged arrays mentioned in
the intro.  What I want is something like "Line 1"'access, but of course that
doesn't work, nor have any of the sixteen-umpty variations that I've tried.
The RM just said that in X'access, X must be an aliased view of an object.
Well, hmph.  Hep me, hep me, please.
>>

I expect others will answer with the obvious use of 'Access on objects so
I won't repeat that here. I will note that you can find a nice example of
this use in the gnatcmd utility in the GNAT sources. In general I think
those who like learning from examples :-) may find it useful to browse the
GNAT sources for useful stuff. The stand alone utilities like gnatcmd are
quite accessible, as are many of the runtime library routines. Even the
main compiler code is reasonable to get into.

Second, the form with allocators, if used at the outer level in a library
package, does not seem particularly more or less static than the form with
the use of 'Access.

Here I am using static in an informal sense to mean no elaboration code at
runtime, which is not quite what static means in Ada, and is also, a bit
surprisingly, not quite what Preelaborate means.

A compiler might or might not generate code for the use quoted above of
allocators, it is certainly quite reasonable that it should not. 

A compiler might or might not generate code for the use of 'Access in an
aggregate, it is certainly quite reasonable that it should not.

So don't jump to conclusions too fast :-)

Re: Two simple language questions

[Matthew Heaney]

In article <68uq34$7tk@tomquartz.niestu.com>, chipr@niestu.com (Chip
Richards) wrote:

>I hope.
>
>First: It says in the Intro to Ada 9X, in Chapter 2, "General access types can
>also be used to program static ragged arrays as for example a table of
>messages of different lengths."  Now, I know this has been asked before, some
>time ago, but I cannot seem to locate the text of the exchange.  What I want
>to know is, exactly what is the syntax for doing this?  I've so far used
>allocators, i.e.:
>
>   strs:  StringArr :=
>   (
>       new string'("Line 1"),
>       new string'("Line 2"),
>       ...
>       new string'("Line the Last")
>   );
>
>Which works great, but isn't exactly the "static" ragged arrays mentioned in
>the intro.  What I want is something like "Line 1"'access, but of course that
>doesn't work, nor have any of the sixteen-umpty variations that I've tried.
>The RM just said that in X'access, X must be an aliased view of an object.
>Well, hmph.  Hep me, hep me, please.

I think an example is in John Barnes' book, but here's a solution:

declare
   Line_1 : aliased constant String := "this is line 1";

   Line_2 : aliased constant String := "this is the text of line 2";

   ...

   Line_Last : aliased constant String := "last";

   type String_Access_Constant is 
      access constant String;

   type String_Array is
      array (Positive range <>) of String_Access_Constant;

   The_Lines : constant String_Array :=
      (Line_1'Access, Line_2'Access, ..., Line_Last'Access);
begin
...
end;


>
>Second, a bit more of a philosophy question, I think.  I've had a couple of
>occasions where I've created Ada95 child packages, and in those packages, I've
>wanted to extend enumeration types defined by the parent.  As an example:
>
>   type Colors is ( Red, Green, Blue );
>
>And in the child, I'd like to be able to say
>
>   type More_Colors is new Colors with ( Yellow, Purple );
>
>Except, of course, that isn't Ada.  So, what's considered the best approach to
>this sort of thing?  Just re-list the constants of the parent type, and add
>the new constants into the list?  Seems a bit repetetive and error-prone to
>me, and I was just wondering if I'd missed someone proposing a more elegant
>solution.  Or am I really off the rails and missing something totally obvious?

No, you can't extend an enumeration type.  You can't extend the range of
any scalar type, not just enumeration types.  

You can get at the base range of the type by using T'Base.  However, for
enumeration types, the first named subtype is the base type (by
definition), so T'Base wouldn't buy you anything anyway.

If you want to "extend" a scalar type, then just used constant objects an
integer type, not an enumeration type:

type Color_Base is new Natural;

subtype Color is Color_Base range 0 .. 2;

Red : constant Color := 0;
Green : constant Color := 1;
Blue : constant Color := 2;

subtype Extended_Color is Color_Base range 0 .. 4;

Yellow : constant Extended_Color := 3;
Purple : constant Extended_Color := 4;

Declare objects and parameters of type Color_Base when you want to accept
any kind of color, extended or not.  Use the subtype when you want to
restrict the range (ie Color or Extended_Color).

BTW: as a point of Ada style, do NOT name scalar types as a plural noun. 
Do not say

   type Colors is...

say

   type Color is ...

The reason is that the object of the type holds only a single value, for example

   The_Color : Colors;  

doesn't make any sense.  The proper way is

   The_Color : Color;

Reserve plural names for objects of a composite type, for example

   type Color_Array is array (Positive range <>) of Color;

   Colors : Color_Array  := (...);

The plural name makes sense here, because Colors is an object that contains
multiple values.

Hope that helps,
Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Two simple language questions (plural types)

[Michael F Brenner]

This thread contains a recommendation that I disagree with. It said to
NOT name scalar types plurals. The reason given was so that it would
read better when you create an array. The example given was 
    type color_array is array (positive range <>) of color;

While there can be different opinions as to how to name the array, 
the array type, the range type, and the element type, there can be
not doubt that, in English, this is an array of COLORS (plural). 

Almost every type reads better when declared to be plural. Those things
that are singletons are declared in a manner where the OBJECT is SINGULAR,
and the TYPE is PLURAL, such as:
     color: colors; -- to be read as: color is of type colors

This is particularly critical for the array index range type, since
none of the array sentences will read as in English if those types
are singular (as in POSITIVE above). 

My recommendation, in order for all Ada declarative and imperative
sentences to read as in English (or any other Indo-European 
language, French, German, Dutch, Italian, Greek, Russian, etc.),
is that almost all objects be singular, all array objects be singular,
and all types be plural. This recommendation obviously does not 
apply to Semitic, Hamitic, Japanese, or Chinese languages, where
the concept of plurals is not like the concept in Indo-European 
languages; in those languages plurals are often not even expressed.

Mike Brenner


is to 

Re: Two simple language questions (plural types)

[Robert Dewar]

Michael said

<<Almost every type reads better when declared to be plural. Those things
that are singletons are declared in a manner where the OBJECT is SINGULAR,
and the TYPE is PLURAL, such as:
     color: colors; -- to be read as: color is of type colors
>>

This is of course purely a matter of taste despite Michael's apparent
intention to put the argument on objective grounds.

For my tastes, I find the use of plurals to be highly (almost deliberately)
confusing.

Here the variable color is said to be something to do with colors, which
to me strongly implies that it is a set of colors or somesuch.

Yes, I see how people could get used to the (to me rather odd) convention
that the intention was always to understand that 

  x : nodes;

means that x takes on one of many possible values of nodes, but I still
don't like it, and it is certainly a convention that we neither encourage
not even permit in the GNAT project. A plural there always means that
there is some kind of collective structure.

  x : node;

one node

  x : nodes;

some kind of collection of nodes

Re: Two simple language questions (plural types)

[Matthew Heaney]

In article <dewar.884450142@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>For my tastes, I find the use of plurals to be highly (almost deliberately)
>confusing.
>
>Here the variable color is said to be something to do with colors, which
>to me strongly implies that it is a set of colors or somesuch.

Hallelujah!  Robert, once again you bring order to chaos.   I completely
agree that plural names should be used to denote, well, plural objects -
aggregates of some kind.  For example, if I have a color object that stores
the value of a single color, then of course the singular declaration

The_Color : Color; 

is preferred.  If I see

The_Color : Colors;

well then my instinct is to assume that The_Color is an aggregate of some
kind, and I would expect to see references like

   ... The_Color (1) ...

(assumes it's an array).

I generally do this sort of thing:

type Color is ...

type Color_Array is array (Positive range <>) of Color;

type Color_Stack is ...

type Color_Set is ...

I usually name array objects with a plural name, because, well, it's a
plural object:

Colors : Color_Array;

I don't buy the argument that we should compare Ada text to English text. 
The text of a computer program has its own idioms (including the one
described above), so a comparison to natural languge is not appropriate.

Do not use a plural name for a singular type.  If you're not convinced,
read the RM:

Integer is not called Integers.

Float is not called Floats.

Address is not called Addresses.

File_Type is not called File_Types.

File_Mode is not called File_Modes.

In fact, I'd like someone to point out anywhere in the RM where a plural
name is used for a singular object.  Why don't Ada programmers use the
idioms in the Ada RM?  It's VERY CONFUSING when you don't.

Please, do not use a plural name for a type whose instances denote a single
value.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Two simple language questions (plural types)

[Robert Dewar]

Matthew said

<<Integer is not called Integers.

Float is not called Floats.

Address is not called Addresses.

File_Type is not called File_Types.

File_Mode is not called File_Modes.
>>

Actually that's the most powerful argument here, because it means that
the issue is not one of taste but one of consistency. Since the 
declarations in the RM are a given, it seems a bad idea to choose a
convention that is inconsistent with the RM style!

Re: Two simple language questions (plural types)

[Anonymous]

<68uq34$7tk@tomquartz.niestu.com>
<mheaney-ya023680000701980209270001@news.ni.net>
<697p89$b5j@top.mitre.org> <dewar.884450142@merv>

On Sat, 10 Jan 1998 11:10:50 -0800, mheaney@ni.net (Matthew Heaney)
wrote:

> In article <dewar.884450142@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> 
> 
> >...
> 
> Hallelujah!  Robert, once again you bring order to chaos.   I completely
> agree that plural names should be used to denote, well, plural objects -
> aggregates of some kind.  For example, if I have a color object that stores
> the value of a single color, then of course the singular declaration
> 
> The_Color : Color; 
> 

There are some hard and fast rules about using plurals for type and
variable names:

1. There are no hard and fast rules.

2. Plurals should never be used for type or variable names.

3. This is all opinion; consistency is more important than anything
else.

However, this is a lot of objective evidence that shows that common
prefixes are bad. The first few characters of names are the most
important in telling names apart; if all variable names in a program
start with a common prefix ("The_"), then it is harder to tell the
variables apart. This is not opinion; it is fact.

The origin of "The_" for all parameters seems to come from books by
someone who could not come up with good type names, and so used the
preferred form for the parameter name for the type name, leaving nothing
good for the parameter name. (I don't have any of the books available,
so I can't be sure about variable names.) Those who advocate plurals for
type names are generally also unable to create good type names, but they
at least want to keep the best form for parameters/variables.

I also object to the use of suffixes that add no information to the name
("_Type", "_T"); this is just another kludge by those who cannot create
good type names.

I prefer a collection of kludges that do add information, but this is a
rehash of a previous posting, so I'll say no more.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"We burst our pimples at you."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Two simple language questions (plural types)

[Brian Rogoff]

On Mon, 12 Jan 1998, Anonymous wrote:
> However, this is a lot of objective evidence that shows that common
> prefixes are bad. The first few characters of names are the most
> important in telling names apart; if all variable names in a program
> start with a common prefix ("The_"), then it is harder to tell the
> variables apart. This is not opinion; it is fact.

You saying it doesn't make it so. At least provide a reference for this 
assertion.

> The origin of "The_" for all parameters seems to come from books by
> someone who could not come up with good type names, and so used the
> preferred form for the parameter name for the type name, leaving nothing
> good for the parameter name. (I don't have any of the books available,
> so I can't be sure about variable names.) Those who advocate plurals for
> type names are generally also unable to create good type names, but they
> at least want to keep the best form for parameters/variables.
> 
> I also object to the use of suffixes that add no information to the name
> ("_Type", "_T"); this is just another kludge by those who cannot create
> good type names.

I find it amazing that you can divine someone's competence in coming up 
with type names based on whether or not they use the same style you do!

You are also obviously wrong, the _Type adds the information that the 
lexical entity is a type. "Integer" or "List" could just as easily be a
variable name as a type name (well, Integer is taken...) so adding some 
bit of information to distinguish them doesn't seem that bad to me. Some 
languages (Dylan, EuLisp) use lexical conventions to distinguish type
names, so Integer and Tree would be <integer> and <tree>. FWIW, I think
Norman Cohen's book uses and _<blah> convention frequently in its
examples.

-- Brian

Re: Two simple language questions (plural types)

[Matthew Heaney]

In article <199801121523.QAA06527@basement.replay.com>, nobody@REPLAY.COM
(Anonymous) wrote:


>> Hallelujah!  Robert, once again you bring order to chaos.   I completely
>> agree that plural names should be used to denote, well, plural objects -
>> aggregates of some kind.  For example, if I have a color object that stores
>> the value of a single color, then of course the singular declaration
>> 
>> The_Color : Color; 
>> 

>However, this is a lot of objective evidence that shows that common
>prefixes are bad. The first few characters of names are the most
>important in telling names apart; if all variable names in a program
>start with a common prefix ("The_"), then it is harder to tell the
>variables apart. This is not opinion; it is fact.
>
>The origin of "The_" for all parameters seems to come from books by
>someone who could not come up with good type names, and so used the
>preferred form for the parameter name for the type name, leaving nothing
>good for the parameter name. (I don't have any of the books available,
>so I can't be sure about variable names.) Those who advocate plurals for
>type names are generally also unable to create good type names, but they
>at least want to keep the best form for parameters/variables.
>
>I also object to the use of suffixes that add no information to the name
>("_Type", "_T"); this is just another kludge by those who cannot create
>good type names.

Perhaps I chose a bad example.  I occasionally use a definate article on
object names, I mostly do not.

I agree also that one does not require the "_Type" suffix on type names. 
The designator _Type doesn't add any more value to the name, since it
appears on the right-hand side of a declaration, and therefore I already
know it's a type.  But you have to solve the problem of giving objects a
different name than the type, because they share the same namespace (this
is not an issue in Eiffel).

So I usually name types using a two-part phrase comprising a noun and
adjective, and then name the object just using the noun part.  For example,
in Text_IO we have

type File_Mode is ...

It's not called Mode_Type, it's called File_Mode.  So now your selector can read

function Mode (File : File_Type) return File_Mode;

Object declarations can now read

Mode : File_Mode;

and so no prefix is required, and All The People Were Happy.

In fact, I think the reason the _Type convention is a debate in the Ada
community is because the file type declared in Text_IO was named

type File_Type is limited private;

To me, this is the one thing the designers got wrong, because they're not
consistant with other declarations in the RM.  The file types should have
been named

type Text_File is

type Sequential_File is 

type Direct_File is

and so once again we could declare a file object as

File : Text_File;

It is not clear to me why the original language designers chose this
convention for the predefined file types.  After all, 

File_Mode isn't called Mode_Type

Integer isn't called Integer_Type

Float isn't called Float_Type

String isn't called String_Type

so why is 

Text_File called File_Type?

For general, non-specific types, a one-word name is OK, because you're
going to name the selector and the object using a different, more specific
name, ie

function Name (File : File_Type) return String;

Name : String;

But what about color?  I would have used the two-part technique, and
qualified that name by the abstraction for which it is an attribute, ie

type Car_Color is ...

so that I could write

Color : Car_Color;

No prefix is therefore required.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Two simple language questions (plural types)

[Brian Rogoff]

On Mon, 12 Jan 1998, Matthew Heaney wrote:
> Perhaps I chose a bad example.  I occasionally use a definate article on
> object names, I mostly do not.
> 
> I agree also that one does not require the "_Type" suffix on type names. 
> The designator _Type doesn't add any more value to the name, since it
> appears on the right-hand side of a declaration, and therefore I already
> know it's a type.  But you have to solve the problem of giving objects a
> different name than the type, because they share the same namespace (this
> is not an issue in Eiffel).

If you have a type Color_Type, you can name the variable Color. While you 
can claim that distinguishing types is redundant due to their position, it
is IMO a helpful redundancy. Just remember, to an ML programmer, almost 
all of the type declarations in Ada are redundant :-).

I think separating the namespaces and allowing 

	Color : Color; 

is a bit too much for me, but I suppose Eiffel programmers get used to it 
and so could I. All of this is preference; just remember a few months ago
that people were flaming Michael Feldman for his use of all caps keywords 
in his (otherwise excellent :-) books. 

> In fact, I think the reason the _Type convention is a debate in the Ada
> community is because the file type declared in Text_IO was named
> 
> type File_Type is limited private;
> 
> To me, this is the one thing the designers got wrong, because they're not
> consistant with other declarations in the RM.  The file types should have
> been named

I guess I think all of the type names should have been lexically
distinguished from non-type names, so I think this is an even bigger 
mistake by far than you! While I don't like your naming conventions, I
have to say I admire your approach in trying to come up with a simple set
of rules that retains consistency with the names of the predefined types. 
I definitely prefer your approach to the use of plurals to distinguish
types, but I doubt that a uniform naming convention will be adopted by 
Ada programmers anytime soon.

-- Brian

Re: Two simple language questions (plural types)

[Robert Dewar]

Brian said

<<I guess I think all of the type names should have been lexically
distinguished from non-type names, so I think this is an even bigger
>>

Note that not doing so was a very concious decision, since Algol-68, which
was well known to the designers of Ada, and provided the inspiration for
a number of important features in Ada, does this (mode names as they
are called in Algol-68 are "stropped", i.e. distinguished in some way
in the source.

Part of the antipathy to this is that there is really no very comfortable
way of doing such lexical distinction, even today.

Distinguishing type names from other identifiers

[Nick Roberts]

The technique I generally use for inventing a type identifier distinct from
identifiers I might use for objects and parameters of that type is to make
the type identifier one step more specific (and thus, usually, longer).

The justification for using a longer identifier for the type, rather than
for the objects and parameters, is that type identifiers are generally used
less often in practical source text.

For example:

   type Hour_Of_Day is range 0..23;
   type Minute_Of_Hour is range 0..59;
   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;

   function To_Seconds_Past_Midnight
                   (Hour:    Hour_Of_Day;
                    Minute:  Minute_Of_Day;
                    Seconds: Seconds_Past_Minute) return Day_Duration;

This example illustrates (I hope ;-) that the use of a plural or singular
form for an identifier is not naturally to do with whether it denotes a
type, an object, a parameter, a subprogram, or whatever, but rather with
whatever concept it describes.  The choice of Seconds_Past_Minute is
perhaps a little clumsy.  I think this is the reason for many scientists'
habit of using the singular form in formal language (as well as other
archaic forms) where in common language the plural would be used; e.g. "...
if Train A be travelling at twelve metre per second ...".

On the subject of the standard Calendar package, I would probably have
chosen the identifier Day_Of_Month rather than Day_Number, and
Month_Of_Year rather than Month_Number.  However, either way, the
identifiers Day and Month can be conveniently used for identifiers of
objects and parameters of these types.

Adding _Type can be a useful way to distinguish a type, as a last resort I
would suggest.  I've always felt the 'size_t' introduced by ANSI C to be a
relatively happy compromise between size and explicitness (NPI again!).  So
I reckon adding _T is not such a sin.  But is it really worth saving the
three -- count them, THREE -- extra letters?

Come what may, I do quite strongly feel that a good programmer will strive
to achieve a maximum of clarity, and a minimum of ambiguity, when choosing
identifiers, and will not allow worries about typing sully this ideal.  It
is surely a fact that, in a few rare cases, choosing short (even terse)
notation will have advantages which outweigh other considerations.  But
these cases are RARE, so say I.

Finally, I think the declaration of the fixed-point type
Seconds_Past_Minute in the example raises another interesting question. 
Should I have used 59.999 for the upper bound, or 60.000?  Is it a bad
omission that Ada does not provide for both open and closed bounds?

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
Roberts" <Nick.Roberts@dial.pipex.com> wrote:

>
>For example:
>
>   type Hour_Of_Day is range 0..23;
>   type Minute_Of_Hour is range 0..59;
>   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;

>Finally, I think the declaration of the fixed-point type
>Seconds_Past_Minute in the example raises another interesting question. 
>Should I have used 59.999 for the upper bound, or 60.000?  Is it a bad
>omission that Ada does not provide for both open and closed bounds?

Do this if you really don't want 60.0 in the range:

type Seconds_Past_Midnight_Base is 
   delta 0.001 range 0.0 .. 60.0;

subtype Seconds_Past_Midnight is
   Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);

The idea is let the compiler figure out what the largest value is, by using
T'Succ.  Declaring a subtype of a first named subtype is a technique few
programmers take advantage of.

This is similar to the issue shops have declaring a heading type that
doesn't have the value 360.0 in the range.  Do this for a floating point
type, if you really insist on not having 360.0 as a value:

type Ownship_Heading_Base is digits 5; -- whatever the precision req'd

subtype Ownship_Heading is 
   Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Distinguishing type names from other identifiers

[Stephen Leake]

Matthew Heaney wrote:
> 
> In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
> Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> 
> >
> >For example:
> >
> >   type Hour_Of_Day is range 0..23;
> >   type Minute_Of_Hour is range 0..59;
> >   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
> 
> 
> Do this if you really don't want 60.0 in the range:
> 
> type Seconds_Past_Midnight_Base is
>    delta 0.001 range 0.0 .. 60.0;
> 
> subtype Seconds_Past_Midnight is
>    Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);
> 
> The idea is let the compiler figure out what the largest value is, by using
> T'Succ.  Declaring a subtype of a first named subtype is a technique few
> programmers take advantage of.

Surely, if you mean to _exclude_ 60.0, you should use 'Pred?


-- 
- Stephe

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <34BD097C.3E9B@gsfc.nasa.gov>, Stephen.Leake@gsfc.nasa.gov wrote:

>Matthew Heaney wrote:
>> 
>> In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
>> Roberts" <Nick.Roberts@dial.pipex.com> wrote:
>> 
>> >
>> >For example:
>> >
>> >   type Hour_Of_Day is range 0..23;
>> >   type Minute_Of_Hour is range 0..59;
>> >   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
>> 
>> 
>> Do this if you really don't want 60.0 in the range:
>> 
>> type Seconds_Past_Midnight_Base is
>>    delta 0.001 range 0.0 .. 60.0;
>> 
>> subtype Seconds_Past_Midnight is
>>    Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);
>> 
>> The idea is let the compiler figure out what the largest value is, by using
>> T'Succ.  Declaring a subtype of a first named subtype is a technique few
>> programmers take advantage of.
>
>Surely, if you mean to _exclude_ 60.0, you should use 'Pred?

Yes, I did mean T'Pred.  Sorry for any confusion.

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Distinguishing type names from other identifiers

[Anonymous]

<mheaney-ya023680001001981110500001@news.ni.net>
<199801121523.QAA06527@basement.replay.com>
<mheaney-ya023680001201981007080001@news.ni.net>
<Pine.BSF.3.96.980112140520.25032A-100000@shell5.ba.best.com>
<dewar.884697067@merv> <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>

On Tue, 13 Jan 1998 18:34:46 -0800, mheaney@ni.net (Matthew Heaney)
wrote:

> In article <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com>, "Nick
> Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> 
> >
> >For example:
> >
> >   type Hour_Of_Day is range 0..23;
> >   type Minute_Of_Hour is range 0..59;
> >   type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
> 
> >Finally, I think the declaration of the fixed-point type
> >Seconds_Past_Minute in the example raises another interesting question. 
> >Should I have used 59.999 for the upper bound, or 60.000?  Is it a bad
> >omission that Ada does not provide for both open and closed bounds?
> 
> Do this if you really don't want 60.0 in the range:
> 
> type Seconds_Past_Midnight_Base is 
>    delta 0.001 range 0.0 .. 60.0;
> 
> subtype Seconds_Past_Midnight is
>    Seconds_Past_Midnight range 0.0 .. Seconds_past_Midnight_Base'Succ (60.0);
> 
> The idea is let the compiler figure out what the largest value is, by using
> T'Succ.  Declaring a subtype of a first named subtype is a technique few
> programmers take advantage of.
> 
> This is similar to the issue shops have declaring a heading type that
> doesn't have the value 360.0 in the range.  Do this for a floating point
> type, if you really insist on not having 360.0 as a value:
> 
> type Ownship_Heading_Base is digits 5; -- whatever the precision req'd
> 
> subtype Ownship_Heading is 
>    Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);
> 

Surely you mean 'Pred, not 'Succ?

OK, I'll stop calling you Shirley :)

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <199801151530.QAA21301@basement.replay.com>, nobody@REPLAY.COM
(Anonymous) wrote:

>> This is similar to the issue shops have declaring a heading type that
>> doesn't have the value 360.0 in the range.  Do this for a floating point
>> type, if you really insist on not having 360.0 as a value:
>> 
>> type Ownship_Heading_Base is digits 5; -- whatever the precision req'd
>> 
>> subtype Ownship_Heading is 
>>    Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);
>> 
>
>Surely you mean 'Pred, not 'Succ?

Yup.  I should have written 

   Ownship_Heading_Base'Pred (360.0)

Thanks for the correction, and sorry for any confusion.

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <mheaney-ya023680002401981019450001@news.ni.net>, Matthew
Heaney <mheaney@ni.net> writes
>In article <199801151530.QAA21301@basement.replay.com>, nobody@REPLAY.COM
>(Anonymous) wrote:

Oops, I see you're talking Ada95 - that last one was for Ada83...

-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <mheaney-ya023680002401981019450001@news.ni.net>, Matthew
Heaney <mheaney@ni.net> writes
>In article <199801151530.QAA21301@basement.replay.com>, nobody@REPLAY.COM
>(Anonymous) wrote:
>
>>> This is similar to the issue shops have declaring a heading type that
>>> doesn't have the value 360.0 in the range.  Do this for a floating point
>>> type, if you really insist on not having 360.0 as a value:
>>> 
>>> type Ownship_Heading_Base is digits 5; -- whatever the precision req'd
>>> 
>>> subtype Ownship_Heading is 
>>>    Ownship_Heading_Base range 0.0 .. Ownship_Heading_Base'Succ (360.0);
>>> 
>>
>>Surely you mean 'Pred, not 'Succ?
>
>Yup.  I should have written 
>
>   Ownship_Heading_Base'Pred (360.0)
>
>Thanks for the correction, and sorry for any confusion.
>
>Matt
>
>--------------------------------------------------------------------
>Matthew Heaney
>Software Development Consultant
><mailto:matthew_heaney@acm.org>
>(818) 985-1271

'Pred on a float? shurely shome mishtake...

how about something like -

subtype A_Heading is Ownship_Heading_Base range 0.0 .. 360.0;

subtype Ownship_Heading is A_Heading
  range A_Heading'first .. A_Heading'Last - A_Heading'Small;
-- 
Martin M Dowie

Pred

[Nick Roberts]

In Ada 83 Pred could only be applied to discrete types, but in Ada 95 it
can be applied to all scalar types.  For fixed-point types, it denotes a
function which returns the value one machine number smaller than the
argument.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***


Martin M Dowie <martin@dowie-cs.demon.co.uk> wrote in article
<JRNnTAAOCmy0EwYL@dowie-cs.demon.co.uk>...
> 'Pred on a float? shurely shome mishtake...
> 
> how about something like -
> 
> subtype A_Heading is Ownship_Heading_Base range 0.0 .. 360.0;
> 
> subtype Ownship_Heading is A_Heading
>   range A_Heading'first .. A_Heading'Last - A_Heading'Small;

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <JRNnTAAOCmy0EwYL@dowie-cs.demon.co.uk>, Martin M Dowie
<martin@dowie-cs.demon.co.uk> wrote:

>'Pred on a float? shurely shome mishtake...
>
>how about something like -
>
>subtype A_Heading is Ownship_Heading_Base range 0.0 .. 360.0;
>
>subtype Ownship_Heading is A_Heading
>  range A_Heading'first .. A_Heading'Last - A_Heading'Small;

No mistake.  These attributes were added to Ada 95 for precisely this reason.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Distinguishing type names from other identifiers

[Aaro Koskinen]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> Adding _Type can be a useful way to distinguish a type, as a last resort I
> would suggest.  I've always felt the 'size_t' introduced by ANSI C to be a
> relatively happy compromise between size and explicitness (NPI again!).  So
> I reckon adding _T is not such a sin.  But is it really worth saving the
> three -- count them, THREE -- extra letters?

How about consistency with other suffixes, e.g. for constants? Do you
use _Constant? That would be way too long, because if you take a quick
look you won't even notice there's a suffix. I prefer _T and _C
because they are distinct from other words in the indentifier.
-- 
Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <pdx3eiq648m.fsf@vesuri.Helsinki.FI>, Aaro Koskinen
<aaro@iki.fi> writes
>How about consistency with other suffixes, e.g. for constants? Do you
>use _Constant? That would be way too long, because if you take a quick
>look you won't even notice there's a suffix. I prefer _T and _C
>because they are distinct from other words in the indentifier.

just testing the water...

...how do people feel about prefixing types with 'A_' or 'An_'? the
theory is that should you wish a function to return something of this
type you just 'A_/An_'. It also reads a little more english-like than
'_type'/'_t', although i've never really thought that 'for this_index in
a_something loop' etc. was particularly like any english i've ever
heard...

it kind of ties in with an OO-mentality too, as (talking Ada83 here) we
are using types to build classes, and data objects for
objects/instances. having a general name for a type helps get this over.

-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk>, Martin M Dowie
<martin@dowie-cs.demon.co.uk> writes
>In article <pdx3eiq648m.fsf@vesuri.Helsinki.FI>, Aaro Koskinen
><aaro@iki.fi> writes
>>How about consistency with other suffixes, e.g. for constants? Do you
>>use _Constant? That would be way too long, because if you take a quick
>>look you won't even notice there's a suffix. I prefer _T and _C
>>because they are distinct from other words in the indentifier.
>
>just testing the water...
>
>...how do people feel about prefixing types with 'A_' or 'An_'? the
>theory is that should you wish a function to return something of this
>type you just 'A_/An_'. It also reads a little more english-like than
>'_type'/'_t', although i've never really thought that 'for this_index in
>a_something loop' etc. was particularly like any english i've ever
>heard...
>
>it kind of ties in with an OO-mentality too, as (talking Ada83 here) we
>are using types to build classes, and data objects for
>objects/instances. having a general name for a type helps get this over.
>

insert the word 'remove' between the words 'just' and 'A_/An_' for this
to make some sort of sense... ;-)

-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk>, Martin M Dowie
<martin@dowie-cs.demon.co.uk> wrote:

>...how do people feel about prefixing types with 'A_' or 'An_'? the
>theory is that should you wish a function to return something of this
>type you just 'A_/An_'. It also reads a little more english-like than
>'_type'/'_t', although i've never really thought that 'for this_index in
>a_something loop' etc. was particularly like any english i've ever
>heard...
>
>it kind of ties in with an OO-mentality too, as (talking Ada83 here) we
>are using types to build classes, and data objects for
>objects/instances. having a general name for a type helps get this over.

Be consistant with the style used in the RM.  If you ever have a question
about how to name something, then flip through the RM (or ask me :-) to see
how the RM does it, and name it that way.  Don't make up a convention
because you think it's more "oo-like."

So the answer is: No, do not use the indefinate article to name types or
objects.  That convention does not appear in the RM, so its use in your
code would be inconsistant with the RM.

The reason we Ada programmers even have this debate about the _Type
convention, is because the file type in Text_IO was named File_Type.  Had
the designers named it Text_File, which is how the abstraction is described
in the Rationale (see Text Files, Section 16.5; see also Indexed and
Sequential Files, section 16.4), we wouldn't be having this debate at all,
and very likely it wouldn't have even occurred to anyone to use _Type for
type names.

This is the argument against _Type as a suffix.  Because it's a noise word,
it doesn't add any new information.  If you have to type something, then
you might as well type something that adds meaning.  I would have prefered
that the I/O types been named

Text_File instead of Text_IO.File_Type

Indexed_File instead of Direct_IO.File_Type 

Sequential_File instead of Sequential_IO.File_Type

This convention exactly corresponds to the description in the Rationale.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Sun, 25 Jan 1998, Matthew Heaney wrote:
> 
> Be consistant with the style used in the RM.  If you ever have a question
> about how to name something, then flip through the RM (or ask me :-) to see
> how the RM does it, and name it that way.  Don't make up a convention
> because you think it's more "oo-like."

I disagree. Slavish consistency with the RM naming conventions is not in
and of itself a virtue, nor a vice. I agree that being "more OO" is an odd
criteria for a naming convention, much worse than RM consistency, but that
doesn't mean that the RM is our only guide. As Jean Pierre Rosen pointed
out, in another thread, we'll almost always end up designing our own types 
anyways, so some convention which makes it clear that we aren'r using 
"built-in" Ada types has some (arguably e, of course) merits.
> 
> So the answer is: No, do not use the indefinate article to name types or
> objects.  That convention does not appear in the RM, so its use in your
> code would be inconsistant with the RM.
> 
> The reason we Ada programmers even have this debate about the _Type
> convention, is because the file type in Text_IO was named File_Type.  Had
> the designers named it Text_File, which is how the abstraction is described
> in the Rationale (see Text Files, Section 16.5; see also Indexed and
> Sequential Files, section 16.4), we wouldn't be having this debate at all,
> and very likely it wouldn't have even occurred to anyone to use _Type for
> type names.

I've seen similar conventions used in other languages, and I've liked
them. I've seen this convention used in some Ada textbooks, notably 
Cohen's , which, BTW, is still my favorite.

> This is the argument against _Type as a suffix.  Because it's a noise word,
> it doesn't add any new information.

Redundancy is not in and of itself bad. Especially if it makes the code
clearer to the reader. As I pointed out before, explicit types are
mostly redundant too..

-- Brian

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Mon, 26 Jan 1998, Martin M Dowie wrote:
> In article <mheaney-ya023680002501980906220001@news.ni.net>, Matthew
> Heaney <mheaney@ni.net> writes
> >
> >Be consistant with the style used in the RM.  If you ever have a question
> >about how to name something, then flip through the RM (or ask me :-) to see
> >how the RM does it, and name it that way.  Don't make up a convention
> >because you think it's more "oo-like."
> 
> I'm not making it up - this is the standard at the company i'm currently
> working for... i prefer not to see '_type' myself - if it made any sense
> we'd haev '_procedure', '_function' etc...

Where it would make sense is with an access to a function/procedure, so
I might declare

	type Callback_Function is access function( ... yadda yadda ... ) 
	                                 return Return_Type;

which looks fine to me, though I might use _Func instead, so my
declarations would be 

	Foo_Callback, Bar_Callback : Callback_Func;

or just 

	Callback : Callback_Func;

> not sure about that - i know _lots_ of engineers who would add a '_type'
> no matter what language they are using "'coz we've always done it that
> way" - i'm sure we've all heard such reasoned arguement in our time...

Old straw man raises his ugly head. I might not add "_Type" in a language
that didn't (usually) have type declarations for variables , whether or
not it was statically typed (Lisp or ML, for example). Its a fine 
convention, IMO of course, in Ada.

I believe I understand the arguments against suffixes on types, but it
seems you don't understand the arguments in favor of them. It has nothing
to do with a misguided notion of OO-ness or inertia. 

-- Brian

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

In article <Pine.BSF.3.96.980126142622.22503A-
100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes
>I believe I understand the arguments against suffixes on types, but it
>seems you don't understand the arguments in favor of them. It has nothing
>to do with a misguided notion of OO-ness or inertia. 
>
>-- Brian
Yup, i'll hold my hand up for that one - i was marked down for tautology
in my (british) english exams at school and i've yet to see any reason
why repeating that something is a type in its declaration should have
any more merit when writing programs ;-) (i just remembered that the
very first project i worked on, spent a week just after i joined
removing '_p' and '_f' from procedure and function names - glad i wasn't
paying the bill for all the effort!!).

it does help emphasis the distinsion between a class and an
instance/object (e.g. type A_Bank_Account v's
My_Deeply_Overdrawn_Account) but i misguided you in indicating that that
was *why* this convention was choosen (although it is mentioned in the
coding standards as an example of how the distinctions between objects
and classes can be emphasised) - i suspect the consultant who wrote the
division's CoP had just read the same book you had.

as i said, this is simply the standard at my current contract - just
fishing for opionions.
-- 
Martin M Dowie

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Tue, 27 Jan 1998, Martin M Dowie wrote:
> In article <Pine.BSF.3.96.980126142622.22503A-
> 100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes
> >I believe I understand the arguments against suffixes on types, but it
> >seems you don't understand the arguments in favor of them. It has nothing
> >to do with a misguided notion of OO-ness or inertia. 
> >
> >-- Brian

> Yup, i'll hold my hand up for that one - i was marked down for tautology
> in my (british) english exams at school and i've yet to see any reason
> why repeating that something is a type in its declaration should have
> any more merit when writing programs ;-)

Use of the type suffix makes it fairly easy to choose consistent names, 
especially for the common case where there is only one variable of the
type. So where someone might write

	The_Object : Object;

I would write something like

	Object : Object_Type;

and I never have collisions between type and variable names. In generic 
code, choosing specific names (as Matthew Heaney suggested, I think)
becomes much harder, the code is generic after all. This convention also
makes it easy to write source analysis tools which get type names by 
simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
redundant, but then so are comments, readable names, the distinction in
Ada between functions and procedures ;-), ...

> (i just remembered that the
> very first project i worked on, spent a week just after i joined
> removing '_p' and '_f' from procedure and function names - glad i wasn't
> paying the bill for all the effort!!).

This convention would only make sense to me if Ada had first-class
procedures and functions. Ada doesn't, so that convention is not even
comparable to the one I am defending. Do you see why? And do you see 
why I mentioned that it might make sense (to me) in the context of
procedure and function pointers?

I hope that it was your assigned task to clean up that code, otherwise you
would be guilty of the same maverick behavior being discussed in a branch
of this thread. I don't like the "_Proc" on a procedure name either, but 
I think its important to observe the existing coding conventions on
projects I join. If I worked on a project that used Matthew's naming
style, I would adopt it even if I didn't like it. 

> it does help emphasis the distinsion between a class and an 
> instance/object (e.g. type A_Bank_Account v's
> My_Deeply_Overdrawn_Account) but i misguided you in indicating that that
> was *why* this convention was choosen (although it is mentioned in the
> coding standards as an example of how the distinctions between objects
> and classes can be emphasised) - i suspect the consultant who wrote the
> division's CoP had just read the same book you had.

I'd prefer "the distinction between *types* and *values*"; I'm annoyed by
all of this OO bullshit that is the rage nowadays. It's not helpful to
cast everything in vague OO-speak.

> as i said, this is simply the standard at my current contract - just
> fishing for opionions.

You got mine. 

-- Brian

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <Pine.BSF.3.96.980127125056.10823A-100000@shell5.ba.best.com>,
Brian Rogoff <bpr@shell5.ba.best.com> wrote:

>Use of the type suffix makes it fairly easy to choose consistent names, 
>especially for the common case where there is only one variable of the
>type. So where someone might write
>
>        The_Object : Object;
>
>I would write something like
>
>        Object : Object_Type;
>
>and I never have collisions between type and variable names. In generic 
>code, choosing specific names (as Matthew Heaney suggested, I think)
>becomes much harder, the code is generic after all. This convention also
>makes it easy to write source analysis tools which get type names by 
>simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
>redundant, but then so are comments, readable names, the distinction in
>Ada between functions and procedures ;-), ...

In practice, names for generic types aren't any harder either.  The
convention I use is something like 

generic
   type Stack_Item is private;
   with function "=" (L, R : Stack_Item) return Boolean is <>;
package Stacks is 

   type Root_Stack is abstract tagged null record;

   function Top (Stack : Root_Stack) return Stack_Item;
...
end Stacks;


I have seen people use _Type for the generic formal type, ie

generic
   type Item_Type  is private;
 ...
package Stacks is ...;

Here's one case where I'd concede that the _Type convention makes sense,
because you want to emphasize the inchoate character of the formal type. 
But I pretty much use the adjective+noun convention for formal types too,
for consistency.

Another example is importing an active iterator as a generic formal type:

generic
   Max_Depth : in Positive;
package Stacks.Bounded is

   type Bounded_Stack is new Root_Stack with private;
...
   generic
      type Source_Stack is new Root_Stack with private;

      type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
         new Root_Stack_Iterator with private;

   procedure Generic_Copy
      (From : access Source_Stack'Class;
        To      : in out Bounded_Stack);

end Stacks.Bounded;

Boy oh boy, I really, really wish we had access constant parameters and
discriminants.  Oh well.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Tue, 27 Jan 1998, Matthew Heaney wrote:
> In article <Pine.BSF.3.96.980127125056.10823A-100000@shell5.ba.best.com>,
> Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> >and I never have collisions between type and variable names. In generic 
> >code, choosing specific names (as Matthew Heaney suggested, I think)
> >becomes much harder, the code is generic after all. This convention also
> >makes it easy to write source analysis tools which get type names by 
> >simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
> >redundant, but then so are comments, readable names, the distinction in
> >Ada between functions and procedures ;-), ...
> 
> In practice, names for generic types aren't any harder either.  The
> convention I use is something like 
> 
> generic
>    type Stack_Item is private;
>    with function "=" (L, R : Stack_Item) return Boolean is <>;
> package Stacks is 
> 
>    type Root_Stack is abstract tagged null record;
> 
>    function Top (Stack : Root_Stack) return Stack_Item;
> ...
> end Stacks;

That's a very nice convention, but as you acknowledge below, its really no 
different from _Type, since you add a redundant qualifier "Stack_" to the 
name. 

> Here's one case where I'd concede that the _Type convention makes sense,
> because you want to emphasize the inchoate character of the formal type. 
> But I pretty much use the adjective+noun convention for formal types too,
> for consistency.

That seems reasonable to me. I'd have no problem adopting this, even if I
prefer "_Type" ;-). I would also use _Func, _Proc, for access to function 
and procedure, and _Class (for classwide types); I think that's about it.
In Beidler's Scranton data structure suite a far more elaborate naming
scheme is used, but its too much for my tastes. GNAT code is more like
yours, except less verbose, i.e., more abbreviations. I can live with
that, though obviously I prefer the style I'm describing.

> Another example is importing an active iterator as a generic formal type:
> 
> generic
>    Max_Depth : in Positive;
> package Stacks.Bounded is
> 
>    type Bounded_Stack is new Root_Stack with private;
> ...
>    generic
>       type Source_Stack is new Root_Stack with private;
> 
>       type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
>          new Root_Stack_Iterator with private;
> 
>    procedure Generic_Copy
>       (From : access Source_Stack'Class;
>         To      : in out Bounded_Stack);
> 
> end Stacks.Bounded;

This is also OK, but I still don't see why you find the redundant _Type 
to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like 
_Stack worse, since qualified package names already have that information. 
What's your thinking on this? 

> Boy oh boy, I really, really wish we had access constant parameters and
> discriminants.  Oh well.

Yeah well. I wish hard for out mode function params, but it ain't gonna 
happen. Its really nice to have a language thats not changing all the
time too! When the next Ada 200X thread starts, we'll all have a chance. 


-- Brian 

Re: Distinguishing type names from other identifiers

[Matthew Heaney]

In article <Pine.BSF.3.96.980128085901.28109A-100000@shell5.ba.best.com>,
Brian Rogoff <bpr@shell5.ba.best.com> wrote:

>> Another example is importing an active iterator as a generic formal type:
>> 
>> generic
>>    Max_Depth : in Positive;
>> package Stacks.Bounded is
>> 
>>    type Bounded_Stack is new Root_Stack with private;
>> ...
>>    generic
>>       type Source_Stack is new Root_Stack with private;
>> 
>>       type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
>>          new Root_Stack_Iterator with private;
>> 
>>    procedure Generic_Copy
>>       (From : access Source_Stack'Class;
>>         To      : in out Bounded_Stack);
>> 
>> end Stacks.Bounded;
>
>This is also OK, but I still don't see why you find the redundant _Type 
>to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like 
>_Stack worse, since qualified package names already have that information. 
>What's your thinking on this? 

I always use adjective+noun.  A tagged type hierarchy always has this
convention: each derivation has a different adjective, but the noun is the
same.  I never use package qualification to get the "real" name, because
the real name is always the name of the type.  A package is just a
namespace - it is not a type.

The Root_<type> convention comes out the RM, and I have adopted it for
consistency with that document.  The adjective+noun style also comes out of
the RM: it's what is used for types Bounded_String and Unbounded_String.

So you'd have something like

type Root_Stack is abstract tagged null record;

type Bounded_Stack is new Root_Stack with private;

type Unbounded_Stack is new Root_Stack with private;

type AVL_Set is new Root_Set with private;

type Prioritized_Queue is new Root_Queue with private;


In my generic example, I chose Source_Stack as the name because some stack
type named <something>_Stack that inherits from Root_Stack is the source of
the data for the copy.

I suppose you could argue that _Stack is redundant, but 1) I always use
adjective+noun consistently, and 2) the type name stands alone, and doesn't
require package name qualification.

Consider another example:

package Bank_Accounts is

   type Bank_Account is abstract tagged null record;
...
end Bank_Accounts;

package Bank_Accounts.Checking is

   type Checking_Account is new Bank_Account with private;
...
end Bank_Accounts.Checking;

package Bank_Accounts.Savings is

   type Savings_Account is new Bank_Account with private;
...
end Bank_Accounts.Savings;


You get the idea.  Some guys name their abstract data type "Object" or
"Instance," but this is a horrible convention because it confuses the
concepts of type and module.  Some Ada programmers actually think that a
class in C++ or Eiffel maps to an Ada package!  A sure sign of confusion. 
A class in C++ is the equivalent of an Ada tagged type.  Yes, I know that
in other languages a class does double-duty as a module and type, but in
Ada they are orthogonal language features.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Wed, 28 Jan 1998, Matthew Heaney wrote:
> In article <Pine.BSF.3.96.980128085901.28109A-100000@shell5.ba.best.com>,
> Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>
> >> ... quoting Matthew Heaney here ... 
> >> Another example is importing an active iterator as a generic formal type:
> >> 
> >> generic
> >>    Max_Depth : in Positive;
> >> package Stacks.Bounded is
> >> 
> >>    type Bounded_Stack is new Root_Stack with private;
> >> ...
> >>    generic
> >>       type Source_Stack is new Root_Stack with private;
> >> 
> >>       type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
> >>          new Root_Stack_Iterator with private;
> >> 
> >>    procedure Generic_Copy
> >>       (From : access Source_Stack'Class;
> >>         To      : in out Bounded_Stack);
> >> 
> >> end Stacks.Bounded;
> >
> >This is also OK, but I still don't see why you find the redundant _Type 
> >to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like 
> >_Stack worse, since qualified package names already have that information. 
> >What's your thinking on this? 
> 
> I always use adjective+noun.  A tagged type hierarchy always has this
> convention: each derivation has a different adjective, but the noun is the
> same.  I never use package qualification to get the "real" name, because
> the real name is always the name of the type.  A package is just a
> namespace - it is not a type.

Right, I mistyped, and meant why Stack_Iterator rather than just Iterator
or Iterator_Type ;-), since its obvious from the package scope that its a 
Stack_Iterator, and if you had Iterators over different collections you
could use the qualified names. I certainly never confuse packages and
types, and find Ada's separation of the two one of its most positive
features. I'm not a big Eiffel fan, my favorite "other language" is ML.

> The Root_<type> convention comes out the RM, and I have adopted it for
> consistency with that document.  The adjective+noun style also comes out of
> the RM: it's what is used for types Bounded_String and Unbounded_String.

Yes, I acknowledge that this is a reasonable basis for a style, though I 
prefer the _Type suffixes, and I combine the two all the time

> You get the idea.  Some guys name their abstract data type "Object" or
> "Instance," but this is a horrible convention because it confuses the
> concepts of type and module.

Agreed. I may use _Class if the type is classwide, to distinguish between 
a classwide and non-classwide type, but I haven't yet. 

>  Some Ada programmers actually think that a
> class in C++ or Eiffel maps to an Ada package!

I've seen this in an Ada 95 book. Once again, I agree that it is horrible.

> A class in C++ is the equivalent of an Ada tagged type.  Yes, I know that
> in other languages a class does double-duty as a module and type, but in
> Ada they are orthogonal language features.

Even in C++, the namespace feature was eventually added, and many language
designers now acknowledge that module and type should be separate
features.

I think in some ways the addition of OO features to Ada was simply
brilliant, and some decisions that are criticized, like the function
syntax instead of the dot syntax, will be well received in the future. 
It leaves the door open for the addition of (possibly restricted) multiple 
dispatch in the future. 

-- Brian

Re: Distinguishing type names from other identifiers

[Mats Weber]

Modula-3 has adopted the convention (it's really a convention, not part of the
language) of using T as the name of the type (usually the single type) that is
defined in an interface (package spec). I think that convention works pretty
well. Here is a small example:

    INTERFACE Stack;
      TYPE T <: REFANY;
      PROCEDURE Create(): T;
      PROCEDURE Push(VAR s: T; x: REAL);
      PROCEDURE Pop(VAR s: T): REAL;
    END Stack.

    MODULE Stack;
      REVEAL T = BRANDED OBJECT item: REAL; link: T END;
      PROCEDURE Create(): T = BEGIN RETURN NIL END Create;

      PROCEDURE Push(VAR s: T; x: REAL) =
        BEGIN 
          s := NEW(T, item := x, link := s)
        END Push;

      PROCEDURE Pop(VAR s: T): REAL =
        VAR res: REAL;
        BEGIN 
          res := s.item; s := s.link; RETURN res
        END Pop;

    BEGIN
    END Stack.

Re: Distinguishing type names from other identifiers

[Martin M Dowie]

>Use of the type suffix makes it fairly easy to choose consistent names, 
>especially for the common case where there is only one variable of the
>type. So where someone might write
>
>       The_Object : Object;
>
>I would write something like
>
>       Object : Object_Type;
>
>and I never have collisions between type and variable names. In generic 
>code, choosing specific names (as Matthew Heaney suggested, I think)
>becomes much harder, the code is generic after all. This convention also
>makes it easy to write source analysis tools which get type names by 
>simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
>redundant, but then so are comments, readable names, the distinction in
>Ada between functions and procedures ;-), ...

the 'a_' prefix also avoids type and vairable name collisions, but
having neither sometimes leads to some 'strange' sounding function
names, though as you point out they could be avoided by using a better
named procedure with a single 'out' mode parameter.

>
>> (i just remembered that the
>> very first project i worked on, spent a week just after i joined
>> removing '_p' and '_f' from procedure and function names - glad i wasn't
>> paying the bill for all the effort!!).
>
>This convention would only make sense to me if Ada had first-class
>procedures and functions. Ada doesn't, so that convention is not even
>comparable to the one I am defending. Do you see why? And do you see 
>why I mentioned that it might make sense (to me) in the context of
>procedure and function pointers?

i see the point of the extensions for pointer to data objects - but in
this instance it is not tautological in nature.

its ok that wasn't an ada project - and thankfully i was spared that bit
of hole filling as i'd just joined and was far too busy reading manuals
on the project and the language they were using. from what i remember it
was a case of a 'new broom' updating the company CoP. hey - and it just
occurred to me that as a tax payer i was paying for all the naugatory
effect! :-o

>
>I hope that it was your assigned task to clean up that code, otherwise you
>would be guilty of the same maverick behavior being discussed in a branch
>of this thread. I don't like the "_Proc" on a procedure name either, but 
>I think its important to observe the existing coding conventions on
>projects I join. If I worked on a project that used Matthew's naming
>style, I would adopt it even if I didn't like it. 

absolutely! just i am doing now with all this 'a_'stuff.

>I'd prefer "the distinction between *types* and *values*"; I'm annoyed by
>all of this OO bullshit that is the rage nowadays. It's not helpful to
>cast everything in vague OO-speak.
>
>You got mine. 
>
>-- Brian
and thanks for 'em - so long as the naming convention on a given project
is consistant i don't have too much against any of them - and i've never
actually come across a CoP that states to add '_type' etc... that will
be my next contract!!

-- 
Martin M Dowie

Re: Two simple language questions (plural types)

[Brian Rogoff]

On 10 Jan 1998, Michael F Brenner wrote:
> My recommendation, in order for all Ada declarative and imperative
> sentences to read as in English (or any other Indo-European 
> language, French, German, Dutch, Italian, Greek, Russian, etc.),
> is that almost all objects be singular, all array objects be singular,
> and all types be plural. 

Well, that's your opinion, and I don't share it. I really don't think I'd 
use that convention at all, and I don't find it intuitive. For types, I 
use either an "_Type" or "_T" suffix, and if I have an access type "_PT". 
This is obviously a matter of taste, GNAT code does not use suffixes to 
distinguish types (though I've seen "_Ptr" in there), so I doubt that 
specious analogies with natural language are helpful.

> This recommendation obviously does not apply to Semitic, Hamitic,
> Japanese, or Chinese languages, where the concept of plurals is not like 
> the concept in Indo-European languages; in those languages plurals are 
> often not even expressed.

OK, I'll bite. My Hebrew is quite rusty, but I'm pretty sure that plurals 
are often expressed, and the concept is the same as in English (e.g. 
cherub, cherubim). I'm also pretty sure Arabic is similar, though it 
has a "dual" form when the number of objects is two. So what are you 
talking about? 

-- Brian

Re: Two simple language questions

[Dale Stanbrough]

In article <68uq34$7tk@tomquartz.niestu.com> Chip Richards,
chipr@niestu.com writes:
>   strs:  StringArr :=
>   (
>       new string'("Line 1"),
>       new string'("Line 2"),
>       ...
>       new string'("Line the Last")
>   );


re ragged arrays..

not as easy as in C . The solution is to simulate what the C compiler
does.
A snippet from an ada95 update i did to the anna  toolkit  prolog
interpreter.

   type Acc_String is access constant String;



   Var_Space_Str      : aliased constant String := "out of variable name
space";
   Wierd_Ch_Str       : aliased constant String := "illegal character in
input";
   Fault_Str          : aliased constant String := "internal error";
   In_File_Depth_Str  : aliased constant String := "nesting-level of 
'see'  is to deep";
   Out_File_Depth_Str : aliased constant String := "nesting-level of
'tell' is to deep";
   File_Name_Str      : aliased constant String := "file-name error";
   File_Status_Str    : aliased constant String := "status error";
   Init_Str           : aliased constant String := "error during
initialization";

   Err_Array : array (Error_Type) of Acc_String := (
                Arity_Error          => Arity_Str'Access,
                Assert_Error         => Assert_Str'Access,
                Atom_Space_Error     => Atom_Space_Str'Access,
                Bad_Cdd_Error        => Bad_Cdd_Str'Access,
                Bad_Char_Error       => Bad_Char_Str'Access,
                Bad_Delim_Error      => Bad_Delim_Str'Access,
                Bad_Exp_Error        => Bad_Exp_Str'Access,
                Call_Error           => Call_Str'Access,
                Clause_Error         => Clause_Str'Access,
                Comment_Error        => Comment_Str'Access,


Dale

Re: Distinguishing type names from other identifiers

[Adam Beneschan]

Nick Roberts wrote:

> The technique I generally use for inventing a type identifier distinct from
> identifiers I might use for objects and parameters of that type is to make
> the type identifier one step more specific (and thus, usually, longer).
>
> The justification for using a longer identifier for the type, rather than
> for the objects and parameters, is that type identifiers are generally used
> less often in practical source text.
>
> For example:
>
>    type Hour_Of_Day is range 0..23;
>    type Minute_Of_Hour is range 0..59;
>    type Seconds_Past_Minute is delta 0.001 range 0.000 .. 59.999;
>
>    function To_Seconds_Past_Midnight
>                    (Hour:    Hour_Of_Day;
>                     Minute:  Minute_Of_Day;
>                     Seconds: Seconds_Past_Minute) return Day_Duration;
>
> This example illustrates (I hope ;-) that the use of a plural or singular
> form for an identifier is not naturally to do with whether it denotes a
> type, an object, a parameter, a subprogram, or whatever, but rather with
> whatever concept it describes.  The choice of Seconds_Past_Minute is
> perhaps a little clumsy. . . .

After following this thread, and looking at this example, I really
wonder what the objection is to using _Type suffixes.  Several people
have objected to "_Type" on the ground that it doesn't add any
informational value to the name.  But do the extra words in the above
example add any value to the name, either?  I'm not convinced that
calling the type Hour_Of_Day is any more helpful to a programmer than
just calling it Hour or Hour_Type.

Of course, I could have picked a bad example to complain about, since
there could be a use for both "Minute_Of_Hour" and "Minute_Of_Day" or
"Minute_Of_Year" or "Minutes_Elapsed" types, or something like that.
But it seems to me that in many, many cases, there just isn't any
extra value to add to the name.  So *anything* you add, whether it's a
boring suffix like _Type or a boring prefix like The_, or something
less boring that appears to contain additional information as in the
above example, is still just "noise"---in essence, a kludge to keep
the compiler happy.

So if I'm right and anything you add is just noise, I think it may be
best to use a boring suffix like _Type.  The small advantage to this
is that it may make your names easier to remember.  If you use _Type
consistently, at least you have less information to carry around in
your head, instead of trying to remember something different for each
type: "Now, let's see, did I call this one _Number, or _Of_Day, or
_Of_Hour, or what?" leading to potential errors such as the one Nick
included in his above example.

                                -- Adam

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On Tue, 13 Jan 1998, Adam Beneschan wrote:
> After following this thread, and looking at this example, I really
> wonder what the objection is to using _Type suffixes.  Several people
> have objected to "_Type" on the ground that it doesn't add any
> informational value to the name.  But do the extra words in the above
> example add any value to the name, either?  I'm not convinced that
> calling the type Hour_Of_Day is any more helpful to a programmer than
> just calling it Hour or Hour_Type.

I am in complete agreement.

> So if I'm right and anything you add is just noise, I think it may be
> best to use a boring suffix like _Type.  The small advantage to this
> is that it may make your names easier to remember.  If you use _Type
> consistently, at least you have less information to carry around in
> your head, instead of trying to remember something different for each
> type: "Now, let's see, did I call this one _Number, or _Of_Day, or
> _Of_Hour, or what?" leading to potential errors such as the one Nick
> included in his above example.

Also, in generic code (meaning, Ada generics) it isn't always appropriate
to use specificity to distinguish, since the entities are, well, generic.
If one is going to use a suffix, another question that comes up is what to
do with access types when you want them distinguished from the non-access 
version. In C (sorry, I am a C programmer too) I use capitalized intercap 
for type names, so a I might have names like CircListT, CircListPT. Ada 
programmers seem to dislike abbreviations, but I really don't like type
names like Circular_List_Access_Type. _Ptr might work, but I usually use 
that for variable names. What do people who use suffixes generally do?

-- Brian

Re: Distinguishing type names from other identifiers

[Michael F Brenner]

No, the main objection to hour_type is not redundant information,
but ugliness. The secondary objection is the lack of plurals, so
that it does not read like an English sentence. The redundancy, if
it were redundant instead of vacuous, would not be so very objectionable.

However, when stuff like _TYPE is added at the end of each type by
FIAT of a quality standard, you not only have changed the meaning
of quality from something that works well and is easily fixed to 
something that is regimented, but you also have lost the reliability,
lost the maintainability, and lost the desire to read that code.
It is no longer cool code.

Nothing affects maintainability more than a lack of desire to maintain it.

Re: Distinguishing type names from other identifiers

[Nick Roberts]

So the answer is ... interleave jokes in comments with your code! 
Programmers will love maintaining the code; and they'll have fun thinking
up more jokes to put in.  Interesting concept.

Something like

   for T in Fuel_Tank_Count'Range loop
      -- Did you hear the one about the Scotsman, the Englishman, and the
Irishman?
      Initialize_Fuel_Tank_Sensor(T);
   end loop;
   -- Well, there was a Scotsman, an Englishman, and an Irishman,
   -- and they were walking along a Dublin street one night, ...

and so on.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Eats three shredded spams every morning for breakfast ***


Michael F Brenner <mfb@mbunix.mitre.org> wrote in article
<69lael$90o@top.mitre.org>...
> 
> No, the main objection to hour_type is not redundant information,
> but ugliness. The secondary objection is the lack of plurals, so
> that it does not read like an English sentence. The redundancy, if
> it were redundant instead of vacuous, would not be so very objectionable.
> 
> However, when stuff like _TYPE is added at the end of each type by
> FIAT of a quality standard, you not only have changed the meaning
> of quality from something that works well and is easily fixed to 
> something that is regimented, but you also have lost the reliability,
> lost the maintainability, and lost the desire to read that code.
> It is no longer cool code.
> 
> Nothing affects maintainability more than a lack of desire to maintain
it.
> 

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Michael says

<<> However, when stuff like _TYPE is added at the end of each type by
> FIAT of a quality standard, you not only have changed the meaning
> of quality from something that works well and is easily fixed to
> something that is regimented, but you also have lost the reliability,
> lost the maintainability, and lost the desire to read that code.
> It is no longer cool code.
>>

Now here I disagree. If you have programmers (I don't care whether they
are maintaining code or building it), and their orientation is that they
react to quality standards by deciding that it means they cannot write
cool code, and they want to do their own thing, then the one and only
preferable solution is to get rid of these programmers. What you refer
to as regimentation is something that quality workers in all fields
must learn to accept. Yes, I realize that the programming field tends
to be full of mavericks who insist on writing neat cool code, but this
is a signal weakness of the field, not a strength.

In practice I find one of the advantages of Ada is that Ada tends to
encourage what you would like to call "regimented" environments, and 
thus to scare off the "cool neat code" crowd. 

Whether the rule of adding _Type at the end of type names is a good one
is one that should be debated on its merits, but Michael's contribution
quoted above seems to suggest that it should be rejected solely on the
basis that it is a rule. That is not a legitimate argument. Some quality
standards can indeed be absolute. Everyone agrees, or should agree that
consistency of code style is an important requirement in any project,
and some aspects of coding style can and should be absolute rules (for
a look at the absolute rules enforced by the GNAT project, look at the
style.adb unit, which is activated by the internal GNAT-project-only
switch -gnatg. We require the use of -gnatg in all GNAT code.

This switch enforces a number of rules ranging from the trivial (no use
of tab characters or trailing blanks in code) to more significant (all
subprograms except main programs at the program library level must have
separate specifications).

Note that I agree that enjoyment plays an important part in any work, and
that "desire to read that code" is important. But competent programmers
find that following "regimentation" makes code more uniform, and therefore
much pleasanter to read. 

Robert Dewar

Re: Distinguishing type names from other identifiers

[Michael F Brenner]

   > ... everyone should agree ...

Dr. Dewar, it is obvious that EVERYONE does not agree with you that
indendation rules have ANYTHING to do with quality. Let me make it 
perfectly clear, that something like indentation which tools can 
change at anyone's whim with zero effort cannot be something that
reduces the cost of software maintenance or the reliability of a
development effort. Nor does the addition of competent mavericks to
a team hurt that team, unless the politics of the team is aimed
somewhere other than in the direction of getting the bugs out of the
product. 

It is okay to espouse your beliefs, but it would be better to permit
the existence of other beliefs to co-exist with yours, and not be
so absolute as in the above quote phrase. 

There is a certain level of project where it becomes essential to 
stop measuring regimentation and volume, and instead measure the
things that make software maintenance more expensive. That is,
those things that cause the maintainer to spend more time analyzing
the impact of changes. 

As proof that gnat has evolved past the level where regimentation
can make it maintainable, we have the decision of ACT that is too
expensive to upgrade the current version of gnat for DOS, gnat 3.07, 
to a later version. Specifically, rather than becoming cheaper and
cheaper 
gnat is becoming more expensive to maintain. 

It would be worth addressing the fact that, despite using Ada,
gnat is becoming more expensive to maintain.

Possibly, the only way to make an Ada-95 program more expensive to
maintain is to DEFINE quality to be regimentation, and measure
that
regimentation rather than measuring things that decohese the
design and couple the code. 

How much of the increase in the maintenance expense of gnat is 
attributable to the philosophy of regimentation of SYNTAX,
rather than measuring the semantic problems?

This question is worth thinking out seriously, rather than 
politically. The answer might support your view or other views.
But there are many projects that would like to ensure they
are measuring the right thing.

Certainly, enforcing syntax rules is trivial with the right tools.
But reducing the number of references to global variables, making
more types limited private, making more variables local, and
making more packages pure might take away more bugs in the gnat
code than continuing to enforce those syntax rules. It is worth
an experiment or two.

Mike Brenner

Re: Distinguishing type names from other identifiers

[Robert Dewar]

<<It is okay to espouse your beliefs, but it would be better to permit
  the existence of other beliefs to co-exist with yours, and not be
  so absolute as in the above quote phrase.

  There is a certain level of project where it becomes essential to
  stop measuring regimentation and volume, and instead measure the
  things that make software maintenance more expensive. That is,
  those things that cause the maintainer to spend more time analyzing
  the impact of changes.>>

Well I disagree, and as I say, as a software manager, I simply would
not tolerate anyone who had this kind of attitude. I find this kind
of chafing under rules to be very damaging to group productivity.
But I am just telling you what my experience is. You certainly will
not persuade me to change my views. At the same time, I am not saying
everyone else has to share these views. There are obviously a lot of
people around who prefer the let-me-hack-away-using-my-own-style
school of thought. All I am saying is that I don't want such people
around my projects.

For example, if someone chafed at using the standard indentation prescribed
by a project, and used there own standard, grudgingly using some tool to
change to the standard rules, I would regard this as evidence of EXACTLY
the kind of attitude that I would want to weed out right away. Avoiding
the evils of code ownership and idiosyncratic styles is for me a key
part of software management

<<As proof that gnat has evolved past the level where regimentation
  can make it maintainable, we have the decision of ACT that is too
  expensive to upgrade the current version of gnat for DOS, gnat 3.07,
  to a later version. Specifically, rather than becoming cheaper and
  cheaper gnat is becoming more expensive to maintain.>>

Chuckle, chuckle, Michael manages to climb on his DOS hobby horse in
very surprising ways :-)

The claim of course is complete nonsense. gnat has not become unmaintainable.
The reason there is no new update of the DOS versoin is that we have invested
zero effort in producting a new version. I am afraid that we have not been
able to manage to make GNAT so maintainable that it maintains itself. As I
have many times pointed out, updating GNAT to current sources is not a big
task, but we have no interest in spending any time at all doing it, since
we see no customer interest in DOS at all. Michael sounding off on CLA
does not generate revenue :-)

<<How much of the increase in the maintenance expense of gnat is
  attributable to the philosophy of regimentation of SYNTAX,
  rather than measuring the semantic problems?>>

There is no such increase, and it is absolutely clear to us that what
worries you as "regimentation of syntax" is one of the reasons that we
are able to be as productive as we are in the continued development
and maintenance of GNAT.

<<Certainly, enforcing syntax rules is trivial with the right tools.
  But reducing the number of references to global variables, making
  more types limited private, making more variables local, and
  making more packages pure might take away more bugs in the gnat
  code than continuing to enforce those syntax rules. It is worth
  an experiment or two.>>

This is apples and oranges. Of course everyone agrees that code should
be written in a clear manner avoiding nasty things etc etc, but you cannot
legislate good code by automatic rules.

On the other hand, uniformity of syntax is NOT about reducing bugs. It is
about creating a code base that everyone in the group feels comfortable
with, so that you avoid the phenomenon, all too common I am afraid in many
large projects, of individuals "owning" pieces of the code and (a) not
wanting anyone else to mess with their parts and (b) not being willing to
mess with other peoples code.

The bottom line here is that of course opinions differ. I find Michael's
contributions on this issue constructive because they form a nice example
of *exactly* the attitudes that I think are important to avoid!

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Note as an interesting postscript to this discussion of enforced coding
styles, that a very common request for enhancement of GNAT is an official
feature similar to -gnatg.

Indeed, quite a few of our customers are using -gnatg even though we advise
against it (we advise against it, becuase (a) it makes the compiler 
non-standard, e.g. allowing compilation of new children of Ada and (b) we
feel free to change this at any time, typically by adding new requirementsw
which you might or might not like)).

We definitely plan some limited capability of this type for style enforcement
available as a user capability in the future.

Note that you can also use external tools, such as AdaAssured to do this
kind of style checking.

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 16 Jan 1998, Robert Dewar wrote:
> This is apples and oranges. Of course everyone agrees that code should
> be written in a clear manner avoiding nasty things etc etc, but you cannot
> legislate good code by automatic rules.
> 
> On the other hand, uniformity of syntax is NOT about reducing bugs. It is
> about creating a code base that everyone in the group feels comfortable
> with, so that you avoid the phenomenon, all too common I am afraid in many
> large projects, of individuals "owning" pieces of the code and (a) not
> wanting anyone else to mess with their parts and (b) not being willing to
> mess with other peoples code.

It is this attitude, apparently very common amongst Ada programmers, and
espoused regularly on this newsgroup, that makes me like the Ada community 
more than any other. While I haven't been around as long as Robert Dewar, 
and disagree with him on the "_T" as noise assessment :-), his
characterization of the way many software projects mismanaged is eerily
familiar to me, and his prescription for solving some of these problems
by firing the losers who have to do things their way seems eminently
reasonable. It is also, unfortunately, contrary to the way most projects
I've worked in are run. 

It's this kind of post that will turn me into an Ada fanatic :-)

-- Brian

Re: Distinguishing type names from other identifiers

[nabbasi]

>
>On 16 Jan 1998, Robert Dewar wrote:
>> 
>> On the other hand, uniformity of syntax is NOT about reducing bugs. It is
>> about creating a code base that everyone in the group feels comfortable
>> with, so that you avoid the phenomenon, all too common I am afraid in many
>> large projects, of individuals "owning" pieces of the code and (a) not
>> wanting anyone else to mess with their parts and (b) not being willing to
>> mess with other peoples code.

I view the idea of a programmer owning a particulare part of the 
software (say a subsystem, or a number of packages or a number of clases etc..)
as more of having personal responsibility for what they are working on, NOT
as being not wanting others to touch their code or they not wanting to 
touch someone else code.

This is why I don't agree that each programmer should not "own" what they
are working on. again, owning here means to me that they are "responsible" 
for that they are working on, it is a positive thing, not a negative one.

Otherwise, it becomes programming by committe, no one is responsible for
any thing going wrong, becuase no one owns the code. If one part of the 
software is not working, one can't hold any person responsible, this seems
to me to allow lazy and bad programmers to ride on the shoulder of better
programmers.

The best situation is where programmers are held responsible for what they
write, to be held responsible for what you write must imply ownsership
of the code, but at the same time, having the code such that any one 
can easily read each other's code or even modify each other code if the need
arises. I beleive in having common style and common standards, but at the
same time, owning what you write.
 
just my 1.88 cents offcourse. 

thanks,
Nasser

Re: Distinguishing type names from other identifiers

[Robert Dewar]

Nasser says

<<Otherwise, it becomes programming by committe, no one is responsible for
any thing going wrong, becuase no one owns the code. If one part of the
software is not working, one can't hold any person responsible, this seems
to me to allow lazy and bad programmers to ride on the shoulder of better
programmers.
>>


The trouble is that if your view is that one particular person is
*the* person responsible for fixing a bug if it occurs in unit X, then
what if that person is on vacation, or suddenly leaves the company.
Inevitably this kind of ownership discourages others from learning
that code, or fixing it, and, as you note, taking responsibility for it.

My ideal of a project is that everyone takes responsibility for everything,
and that every part of the system has more than one person knowing it 
well enough to fix or modify things. Ideally testing procedures should
be set up to minimize the problem of introducing bugs into a system
but if someone *does* introduce a bug, then what should happen is that
they feel a strong sense of responsibility to the little community that
is the project they are involved in, and rush to fix the problem.

Furthermore, everyone needs to work together, so that if someone does
make a mistake, other people's reaction is to work to help sort it out,
rather than sit around being annoyed.

Creating a sense of community that achieves this ideal is not easy, but
it is definitely possible. Agreeing to a standard set of coding conventions
is just one element in acheiving this.

A good test for me is how the "owner" of unit A reacts if someone else
fixes a problem or makes a modification in unit A. All to often the
reaction is a defensive one ("what's this guy doing messing with my code?").
What you are aiming at is that the reaction is more like "great, thanks,
now I don't have to fix that bug myself".

Robert Dewar

Re: Distinguishing type names from other identifiers

[Philip Brashear]

In article <69nt40$q7n@top.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>   > ... everyone should agree ...
>
>Dr. Dewar, it is obvious that EVERYONE does not agree with you that

Ahem!  Actually "EVERYONE does not agree with [Robert Dewar]" is a
false statement, since there are people who do agree with him.
Perhaps Michael meant "NOT everyone agrees with [Robert Dewar]".

One might take this as an example of attention to readability,
I suppose.

(:-)

Phil Brashear

Re: Distinguishing type names from other identifiers

[Benoit Jauvin-Girard]

On 16 Jan 1998, Robert Dewar wrote:
[SNIP - In reply to Michael] 
> Now here I disagree. If you have programmers (I don't care whether they
> are maintaining code or building it), and their orientation is that they
> react to quality standards by deciding that it means they cannot write
> cool code, and they want to do their own thing, then the one and only
> preferable solution is to get rid of these programmers. What you refer
> to as regimentation is something that quality workers in all fields
> must learn to accept. Yes, I realize that the programming field tends
> to be full of mavericks who insist on writing neat cool code, but this
> is a signal weakness of the field, not a strength.
> 
> In practice I find one of the advantages of Ada is that Ada tends to
> encourage what you would like to call "regimented" environments, and 
> thus to scare off the "cool neat code" crowd. 

A small interjection: while I cannot truly disagree with the main idea
above (nobody likes indecipherable "Joe code", especially after Joe has
left the company), I find it worrysome that you'd call something that
scares programmers away from Ada an 'advantage'.  Isn't one more
programmer choosing to work in Ada a good thing for the community?

..And I can only hope you don't mean that Ada makes it impossible to write
neat, cool code!  (Since it's patently untrue.)

--
... Benoit Jauvin-Girard (jhove@cam.org)

Re: Distinguishing type names from other identifiers

[Robert Dewar]

BJG says

<<A small interjection: while I cannot truly disagree with the main idea
above (nobody likes indecipherable "Joe code", especially after Joe has
left the company), I find it worrysome that you'd call something that
scares programmers away from Ada an 'advantage'.  Isn't one more
programmer choosing to work in Ada a good thing for the community?

..And I can only hope you don't mean that Ada makes it impossible to write
neat, cool code!  (Since it's patently untrue.)
>>

Well of course it is possible to display the neat/cool phenomenon in any
language. Unfortunately we don't know how to design languages that only
permit straightforward easy to understand code. I said discourage and
not prohibit :-)

As for scaring away undisciplined programmers -- if that happens, and I
think in fact it does, then no aplogies, this is a GOOD THING :-)

Re: Distinguishing type names from other identifiers

[tmoran]

In <884736089.2104295427@dejanews.com> Adam Beneschan said:
> best to use a boring suffix like _Type.  The small advantage to this
> is that it may make your names easier to remember.  If you use _Type
> ...
> type: "Now, let's see, did I call this one _Number, or _Of_Day, or
> _Of_Hour, or what?" leading to potential errors such as the one Nick

Not a "small" advantage at all!  Maintenance programmers should be
able to read the code fast and without being led into
misunderstanding.  A consistent pattern like "_Type" or "_T" or
plural or whatever aids this (though the example of English shows
that the human brain can deal with a limited amount of irregularity
and pure memorization, like "Integer" as a type name).  Then he
should be able to write new code quickly and correctly, without have
to look up hard-to-remember spellings and with a very low
probability that he guessed wrong.

Re: Distinguishing type names from other identifiers

[Robert Dewar]

tmoran says

<<Not a "small" advantage at all!  Maintenance programmers should be
able to read the code fast and without being led into
misunderstanding.  A consistent pattern like "_Type" or "_T" or
plural or whatever aids this (though the example of English shows
that the human brain can deal with a limited amount of irregularity
and pure memorization, like "Integer" as a type name).  Then he
should be able to write new code quickly and correctly, without have
to look up hard-to-remember spellings and with a very low
probability that he guessed wrong.
>>


THis is one of those arguments which goes like this

I support the idea of doing X

This is because X promotes readability

Readability is good because (long string of mother and applie pie
stuff, constituting the bulk of the argument).

Yes, yes, we all agree with step 3, but however much we agree with step
3 does not encourage us to accept your belief in step 2 without arguments.
Your argument boils down to

I think that using _Type makes things more readable for a maintenance
programmer.

But many others (including most certainly me) think that using useless
noise suffixes like this *compromises* readability, and can be a detriment
to maintenance programmers.

Experience shows again and again that the GNAT code is very easy for a
new programmer to learn. We have lots of experiences now of people plunging
into this code and very quickly getting to the point where they can make
subtle changes successfully.

The GNAT code does not use this kind of suffixing routinely, though it 
uses it occasionally where it seems useful. Once again, there is a real
danger in either mandating such usage all the time or in forbidding it.

This does not prove that it is a good idea not to use the suffix all the
time, but it is one data point (I am sure other readers can supply lots
of others) that shows that the claim that if you *don't* do this, your
code will be unreadable and unmaintainable is bogus!

So without more facts, this comes down to a matter of taste, about which it
is a bit of a waste of time to argue!

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 14 Jan 1998, Robert Dewar wrote:
> ... about _Type and similar suffixes ...
> 
> But many others (including most certainly me) think that using useless
> noise suffixes like this *compromises* readability, and can be a detriment
> to maintenance programmers.

Any evidence for this, even anecdotal, or is this just opinion? 

> The GNAT code does not use this kind of suffixing routinely, though it 
> uses it occasionally where it seems useful. Once again, there is a real
> danger in either mandating such usage all the time or in forbidding it.
> 
> This does not prove that it is a good idea not to use the suffix all the
> time, but it is one data point (I am sure other readers can supply lots
> of others) that shows that the claim that if you *don't* do this, your
> code will be unreadable and unmaintainable is bogus!

Surely no one has claimed this. Suffixes on types are *way* down on my
list of things to do to make code more readable, but every little thing 
helps. FWIW, I find the GNAT code I've read quite readable, but I like
those "useless noise" suffixes. 

> So without more facts, this comes down to a matter of taste, about which it
> is a bit of a waste of time to argue!

I agree that it is a matter of taste, but it isn't a waste of time trying
to come to an agreement on common coding conventions. Some progress has
been made already; as no one suggested TIME_TYPE or TimeType. 

-- Brian

Re: Distinguishing type names from other identifiers

[nabbasi]

In POSIX threads, types are named with a trailing "_t", as in

                pthread_mutex_t

I found this to be clear and I like it, a little "_t" at the end is not much
extra overhead on the eye. 

I have been programming more in Java lately and since Java is case sensitive,
the convention in Java is to have the class name to start with an Upper 
case, while variables start with lower case.

so, I can write 

    Car car;

and it will clear, and no need to have any post, or prefix stuff added to 
the name of the type to make it clear. I think this is one advantage 
of case sensetive languages, offcourse in Java this convention 
(Upper case for class name, lower case for variables) is strongly 
enforced, even though offcourse there is nothing in the language 
itself that forces anyone to follow this.

my final 2 cents is that a trailing "_t" in Ada would be a good choice 
for a type name, I think "_type" is an overkill, and too much extra typing,
but I prefer to see "_type" than nothing at all in the type name.

Other conventions I use in my C++/Java programming is to use "m_" as the
start of a variable name that is local to a class, this I find helps me
when I am reading code to get a better feeling where things live without
having to go look for them in the code. 

my 1.88 cents.

thanks,
Nasser

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 14 Jan 1998 nabbasi@earthlink.net wrote:
> In POSIX threads, types are named with a trailing "_t", as in
> 
>                 pthread_mutex_t
> 
> I found this to be clear and I like it, a little "_t" at the end is not much
> extra overhead on the eye. 

I share your opinion, though I don't find "_Type" too bad either. 

The most important rule I follow is the "grandfather clause", and that is
that if the code I am maintaining/modifying/whatever (how many of times do 
you get to start at the very beginning?) uses some set of conventions, I
strive to be consistent with them, even if I find them personally
repugnant (like the plurals for types convention), so that the code has 
the appearance of being written by one person adhering to a single set 
of conventions. 
  
> my final 2 cents is that a trailing "_t" in Ada would be a good choice 
> for a type name, I think "_type" is an overkill, and too much extra typing,
> but I prefer to see "_type" than nothing at all in the type name.

As you can see from all of the postings on this, there are quite a few
diverging opinions. It reminds me of the intense arguments over brace
placement in C. As long as only one convention is used throughout a
project, I don't have too many problems switching over.
 
> Other conventions I use in my C++/Java programming is to use "m_" as the
> start of a variable name that is local to a class, this I find helps me
> when I am reading code to get a better feeling where things live without
> having to go look for them in the code. 

Doug Lea has a pretty decent Java coding standard available at his home
page, which addresses issues like these. 

-- Brian

Re: Distinguishing type names from other identifiers

[tmoran]

>This is the argument against _Type as a suffix.  Because it's a noise word,
>it doesn't add any new information.
  Don't think of it as the word "type", but rather as a suffix, analogous
to "s" or "ed" or "ing" in English.  Thought of that way, it's quite
arbitrary what the character string is as long as the reading community
understands what's meant.  "s" or "_t" or "_Type" are English-ish as the
multiple prefixes in "Windows Hungarian" are Bantu Kivunjo-ish.
  It's somewhat odd, actually, that most computer languages use only word
order (counting punctuation symbols as words) for parsing and don't
use spelling/prefix/suffix changes to the words themselves as grammatical
indicators.  I wonder if that will still be the case in 50 years?

Re: Distinguishing type names from other identifiers

[Brian Rogoff]

On 25 Jan 1998 tmoran@bix.com wrote:

>   It's somewhat odd, actually, that most computer languages use only word
> order (counting punctuation symbols as words) for parsing and don't
> use spelling/prefix/suffix changes to the words themselves as grammatical
> indicators.  I wonder if that will still be the case in 50 years?

(Early) Fortran is one. The Scheme community uses a convention of "!" as a
suffix for side-effecting functions, and "?" for queries. Some other Lisps
adopt a <Typename> convention to distinguish types. OCaml also has some
capitalization rules for various entities.

I think that not enforcing a convention is OK, but I doubt we'll ever
achieve community wide consensus on this issue. Just be glad that the 
capitalization rule of underscore separated intercap seems to be widely 
followed. There will probably be about half a dozen styles for dealing
with the typename issue. 

-- Brian

Re: Distinguishing type names from other identifiers

[Nick Roberts]

Original BASIC (remember Kemeny and Kurtz?) used the $ sign to distinguish
a string identifier from a numeric one.  Microsoft (et al) BASIC added %
for integers, ! for single-precision floating-point, and # for
double-precision.

I should imagine that in 50 years' time, computers will mostly be
programmed in (spoken) natural language, using heuristic artificial
intelligence techiniques to 'home in' on the required functionality. 
'Computers' by then will, I would guess, either be as small as a
credit-card, and worn in the top-pocket (where they can speak and be spoken
to by the wearer), or large and walking around.

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***


Brian Rogoff <bpr@shell5.ba.best.com> wrote in article
<Pine.BSF.3.96.980125151733.15507A-100000@shell5.ba.best.com>...
> On 25 Jan 1998 tmoran@bix.com wrote:
> 
> >   It's somewhat odd, actually, that most computer languages use only
word
> > order (counting punctuation symbols as words) for parsing and don't
> > use spelling/prefix/suffix changes to the words themselves as
grammatical
> > indicators.  I wonder if that will still be the case in 50 years?
> 
> (Early) Fortran is one. The Scheme community uses a convention of "!" as
a
> suffix for side-effecting functions, and "?" for queries. Some other
Lisps
> adopt a <Typename> convention to distinguish types. OCaml also has some
> capitalization rules for various entities.
[...]