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

[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

[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

[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