Beginners question: Compound types, how-to?

Beginners question: Compound types, how-to?

[Mart van de Wege]

Hi,

I've been playing around with Ada for a bit, and like it. To teach it to
myself, I am rewriting some Perl code I wrote for hobby purposes, yet I
can't seem to get my head around how to use compound types.

I have the following code (yes, I'm an RPG geek, sorry):

games-rpg-dnd.ads:
--with Games.RPG;
-- Ignore parent package for now, we don't need the
-- utility functions yet.
package Games.RPG.DnD is
   type Ability_Type is (Str, Dex, Con, Int, Wis, Cha);
   type Ability is
      record
	 Score : Natural;
	 Modifier : Integer;
      end record;
   type Ability_Array is array (Ability_Type) of Ability;
   type Character is 
      record
	 Abilities : Ability_Array;
      end record;
end Games.RPG.DnD;

test-game.adb:
with Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;
use Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;

procedure Test_Game is
   C : Character;
begin
   C.Abilities(Str) := (Score => 10, Modifier => -1);
   Put (C.Abilities(Str).Score);
   put (C.Abilities(Str).Modifier);
end Test_Game;

When I do it like this:

with Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;
use Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;

procedure Test_Game is
   A : Ability_Array;
begin
   A(Str) := (Score => 10, Modifier => -1);
   Put (A(Str).Score);
   put (A(Str).Modifier);
end Test_Game;

It works, when I use the former code, it bombs with 'Invalid prefix in
selected component "C"';

What am I doing wrong? I am misunderstanding something, but what? C
should be a record containing an Ability_Array as its first field, so I
should be able to index into it using an Ability_Type subscript. How do
I do this?

Mart
-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Beginners question: Compound types, how-to?

[Vinzent Hoefler]

On Sun, 31 Oct 2010 23:00:52 +0100, Mart van de Wege <mvdwege@mail.com> wrote:

> procedure Test_Game is
>    C : Character;

Try "C : Games.RPG.Dnd.Character" here.

> begin
>    C.Abilities(Str) := (Score => 10, Modifier => -1);
>    Put (C.Abilities(Str).Score);
>    put (C.Abilities(Str).Modifier);
> end Test_Game;

I suspect you're clashing with the predefined "Character" type here.


Vinzent.

-- 
There is no signature.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Sun, 31 Oct 2010 23:36:29 +0100, Vinzent Hoefler  
<nntp-2010-10@t-domaingrabbing.de> a écrit:
>> procedure Test_Game is
>>    C : Character;
>
> Try "C : Games.RPG.Dnd.Character" here.
>
>> begin
>>    C.Abilities(Str) := (Score => 10, Modifier => -1);
>>    Put (C.Abilities(Str).Score);
>>    put (C.Abilities(Str).Modifier);
>> end Test_Game;
>
> I suspect you're clashing with the predefined "Character" type here.
This recall me a similar thing I get a little long time ago. I wanted to  
define a String type which I expected to hide the one of Standard, but  
always failed. I asked about it on a forum after I've checked the  
reference manual that time. I was thinking visibility rules was so that I  
was allowed to hide something from Standard, did not found anything  
stating the opposite, and finally never get an answer to this old question.

I suppose the compiler here is GNAT, like near to every time, but would be  
nice to confirm. Would be interesting to know if this is GNAT specific or  
not (or else if indeed the reference manual has something saying one  
cannot hide a declaration of package Standard).

Would be an answer to an old question.

Another variant to test also :

    procedure Test_Game is
       subtype Character is Games.RPG.Dnd.Character;
       C : Character;
       ...

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 10/31/2010 03:00 PM, Mart van de Wege wrote:
>
> games-rpg-dnd.ads:
> --with Games.RPG;
> -- Ignore parent package for now, we don't need the
> -- utility functions yet.

Children always have visibility into the specs of their ancestors, so you never 
need to "with" said ancestors.

> with Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;
> use Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;
>
> procedure Test_Game is
>     C : Character;

You have 2 things named Character at this point: Standard.Character, an 
enumeration type, and Standard.Games.RPG.DND.Character, a record type. 
Standard.Character is directly visible, and the other is "use visible", visible 
due to a use clause. The rule is that something that is use visible cannot hide 
something that is directly visible. Since both can't be referenced by the simple 
name Character, this must refer to the one that is directly visible, 
Standard.Character.

Things are different for subprograms, which can be overloaded; then both may be 
visible and referred to by the simple name.

But it's usually a good idea for a beginner to avoid use clauses.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

Re: Beginners question: Compound types, how-to?

[Mart van de Wege]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 10/31/2010 03:00 PM, Mart van de Wege wrote:
>>
>> games-rpg-dnd.ads:
>> --with Games.RPG;
>> -- Ignore parent package for now, we don't need the
>> -- utility functions yet.
>
> Children always have visibility into the specs of their ancestors, so
> you never need to "with" said ancestors.
>
Cool. I missed this tidbit in the texts I read. I suppose this *is*
spelled out in the Reference Manual?

>> with Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;
>> use Games.RPG.DnD, Ada.Text_IO, Ada.Integer_Text_IO;
>>
>> procedure Test_Game is
>>     C : Character;
>
> You have 2 things named Character at this point: Standard.Character,
> an enumeration type, and Standard.Games.RPG.DND.Character, a record
> type. 

Thanks to Jeffrey and the others. Yes, this was an elementary mistake,
and I kept overlooking it because I also have C experience, so I kept
reading Character as a perfectly fine identifier and dismissing Char
because I thought it was a reserved word.

I should have realised sooner that Ada uses full words, not
abbreviations, whenever possible.

I recompiled with Char as the type name; it looks ugly, but I think I
know a way around that, but that involves inheritance, and I am not
touching that just yet. 

My test code works fine now. I am relieved at least to know that my
logic was sound, even if the code wasn't particularly.

Mart
-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Beginners question: Compound types, how-to?

[Mart van de Wege]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Sun, 31 Oct 2010 23:36:29 +0100, Vinzent Hoefler
> <nntp-2010-10@t-domaingrabbing.de> a écrit:
>>> procedure Test_Game is
>>>    C : Character;
>>
>> Try "C : Games.RPG.Dnd.Character" here.
>>
>>> begin
>>>    C.Abilities(Str) := (Score => 10, Modifier => -1);
>>>    Put (C.Abilities(Str).Score);
>>>    put (C.Abilities(Str).Modifier);
>>> end Test_Game;
>>
> I suspect you're clashing with the predefined "Character" type here.
>
Yes, I was. Silly C experience led me to believe 'Character' was a
perfectly fine identifier.

> I suppose the compiler here is GNAT, like near to every time, but
> would be nice to confirm. Would be interesting to know if this is GNAT
> specific or  not (or else if indeed the reference manual has something
> saying one  cannot hide a declaration of package Standard).
>
Yup, this was GNAT, as currently packaged in Debian unstable.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Beginners question: Compound types, how-to?

[(see below)]

On 01/11/2010 04:55, in article iale5p$2f6$1@tornado.tornevall.net, "Jeffrey
Carter" <spam.jrcarter.not@spam.not.acm.org> wrote:
 
> Children always have visibility into the specs of their ancestors, so you
> never need to "with" said ancestors.

While the first claim is true, the second does not follow, as I am given to
understand it.

If you need:

  pragma Elaborate_All(<ancestor>);

Then you also need:

  with <ancestor>;

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Beginners question: Compound types, how-to?

[Brian Drummond]

On Sun, 31 Oct 2010 23:00:52 +0100, Mart van de Wege <mvdwege@mail.com> wrote:

>Hi,
>
>I've been playing around with Ada for a bit, and like it. To teach it to
>myself, I am rewriting some Perl code I wrote for hobby purposes, yet I
>can't seem to get my head around how to use compound types.
>
>I have the following code (yes, I'm an RPG geek, sorry):

>   type Ability_Type is (Str, Dex, Con, Int, Wis, Cha);

>   type Character is 
>      record

>What am I doing wrong? I am misunderstanding something, but what? C
>should be a record containing an Ability_Array as its first field, so I
>should be able to index into it using an Ability_Type subscript. How do
>I do this?

Others have pointed out the syntactic problem here, and the way to resolve it by
name qualification.

I would suggest that perhaps "Player" would be a better name than "Character"
(or perhaps "Actor" if a game player can control several actors). When you read
the code in six months and see "Character" you are likely to think "A,B,C" etc.
The extra effort to overcome that is unnecessary, and detracts from the work.

Likewise Str ... String? Strength? Strangeness? Write them in full; you'll thank
yourself later. If you don't like typing long words, either find an editor with
an autocomplete function,  or learn to use "renames".

-- this can be shortened if you have "use"d the package
Dex : Games.RPG.DnD.Ability_Type renames Games.RPG.DnD.Dextrose; 
-- or was it Dexterity?

now you can use Dex in a context where there will be no confusion; and refer to
the "renames" clause if you get confused anyway...

- Brian

Re: Beginners question: Compound types, how-to?

[Florian Weimer]

* Brian Drummond:

> Likewise Str ... String? Strength? Strangeness? Write them in full;
> you'll thank yourself later.

I suspect these a technical terms familiar to domain experts, similar
to Ada's "abs", "mod" and "rem" operators. (I'm not into RPGs, though.)

Re: Beginners question: Compound types, how-to?

[Mart van de Wege]

Brian Drummond <brian_drummond@btconnect.com> writes:

> On Sun, 31 Oct 2010 23:00:52 +0100, Mart van de Wege <mvdwege@mail.com> wrote:
>
>>Hi,
>>
>>I've been playing around with Ada for a bit, and like it. To teach it to
>>myself, I am rewriting some Perl code I wrote for hobby purposes, yet I
>>can't seem to get my head around how to use compound types.
>>
>>I have the following code (yes, I'm an RPG geek, sorry):
>
>>   type Ability_Type is (Str, Dex, Con, Int, Wis, Cha);
>
>>   type Character is 
>>      record
>
>>What am I doing wrong? I am misunderstanding something, but what? C
>>should be a record containing an Ability_Array as its first field, so I
>>should be able to index into it using an Ability_Type subscript. How do
>>I do this?
>
> Others have pointed out the syntactic problem here, and the way to
> resolve it by name qualification.
>
> I would suggest that perhaps "Player" would be a better name than
> "Character" (or perhaps "Actor" if a game player can control several
> actors).

In fact, this particular problem domain calls for inheritance, with a
generic Creature type defining the basic attributes and operations, and
Player_Character, Non_Player_Character and a Monster derived types.

Which is why I said that I am going to refactor that sooner or later anyway.

> Likewise Str ... String? Strength? Strangeness? Write them in full;
> you'll thank yourself later. If you don't like typing long words,
> either find an editor with an autocomplete function, or learn to use
> "renames".
>
Str = Strength.

As Florian said, those are domain-specific abbreviations. Anyone who
plays role-playing games will know what they mean, anyone who doesnt
doesn't have any use for my code anyway. 

In fact, I suspect once I'm done I'm the only one to have any use for
it, but hobby projects like these are always fun to learn a language
with; my previous implementation (which works), was done in Perl/Moose,
to learn that particular framework.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Beginners question: Compound types, how-to?

[Shark8]

On Nov 1, 1:12 am, Mart van de Wege <mvdw...@mail.com> wrote:
> Jeffrey Carter <spam.jrcarter....@spam.not.acm.org> writes:
>
> Thanks to Jeffrey and the others. Yes, this was an elementary mistake,
> and I kept overlooking it because I also have C experience, so I kept
> reading Character as a perfectly fine identifier and dismissing Char
> because I thought it was a reserved word.
>
> I should have realised sooner that Ada uses full words, not
> abbreviations, whenever possible.
>
> I recompiled with Char as the type name; it looks ugly, but I think I
> know a way around that, but that involves inheritance, and I am not
> touching that just yet.
>
> My test code works fine now. I am relieved at least to know that my
> logic was sound, even if the code wasn't particularly.
>
> Mart
> --
> "We will need a longer wall when the revolution comes."
>     --- AJS, quoting an uncertain source.

You could have appended "_Type" to the type declaration giving
"Character_Type."
This gives the added advantage of allowing your parameters to be
highly descriptive, especially if you use named-association when
calling the parameters.

Ex:
Procedure Do_Damage( Character : In Out Character_Type; Amount : In
Positive ); -- the spec for a procedure

-- using the procedure
declare
   Dave  :  Character_Type:= Randomize_Stats;                --
Initialize a character
begin
 ...
   -- Dave was hit in a bar-fight for 3 damage
   Do_Damage( Amount => 3, Character => Dave );              -- Note
that with named association you may put the parameters in arbitrary
order
 ...
end;

Re: Beginners question: Compound types, how-to?

[Mart van de Wege]

Shark8 <onewingedshark@gmail.com> writes:

> On Nov 1, 1:12 am, Mart van de Wege <mvdw...@mail.com> wrote:
>> Jeffrey Carter <spam.jrcarter....@spam.not.acm.org> writes:
>>
>> Thanks to Jeffrey and the others. Yes, this was an elementary mistake,
>> and I kept overlooking it because I also have C experience, so I kept
>> reading Character as a perfectly fine identifier and dismissing Char
>> because I thought it was a reserved word.
>>
>> I should have realised sooner that Ada uses full words, not
>> abbreviations, whenever possible.
>>
>> I recompiled with Char as the type name; it looks ugly, but I think I
>> know a way around that, but that involves inheritance, and I am not
>> touching that just yet.
>>
>> My test code works fine now. I am relieved at least to know that my
>> logic was sound, even if the code wasn't particularly.
>>
>> Mart
>> --
>> "We will need a longer wall when the revolution comes."
>>     --- AJS, quoting an uncertain source.
>
> You could have appended "_Type" to the type declaration giving
> "Character_Type."
> This gives the added advantage of allowing your parameters to be
> highly descriptive, especially if you use named-association when
> calling the parameters.
>
That's another way around it. Nice. Thanks.

> Ex:
> Procedure Do_Damage( Character : In Out Character_Type; Amount : In
> Positive ); -- the spec for a procedure
>
> -- using the procedure
> declare
>    Dave  :  Character_Type:= Randomize_Stats;                --
> Initialize a character
> begin
>  ...
>    -- Dave was hit in a bar-fight for 3 damage
>    Do_Damage( Amount => 3, Character => Dave );              -- Note
> that with named association you may put the parameters in arbitrary
> order
>  ...
> end;

<grin>

I wasn't planning on going that far. I am aiming on implementing just
enough of the rules to spare me the horrid paperwork in planning and
running games.

After all, that's what computers are for.

And so far, my first impression of Ada is that it's a nice
language. It's finicky, but not as bad as people make it out to be on
that front.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 12:50:50 +0100, (see below)  
<yaldnif.w@blueyonder.co.uk> a écrit:
>> Children always have visibility into the specs of their ancestors, so  
>> you
>> never need to "with" said ancestors.
>
> While the first claim is true, the second does not follow, as I am given  
> to
> understand it.
>
> If you need:
>
>   pragma Elaborate_All(<ancestor>);
>
> Then you also need:
>
>   with <ancestor>;
I've just checked it with GNAT, it did not return an error. <ancestor> is  
implicitly withed even with Elaborate_All. No special case with this  
pragma.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 08:12:49 +0100, Mart van de Wege <mvdwege@mail.com> a  
écrit:
>> Children always have visibility into the specs of their ancestors, so
>> you never need to "with" said ancestors.
>>
> Cool. I missed this tidbit in the texts I read. I suppose this *is*
> spelled out in the Reference Manual?

Yes, and it is spelled that way ;)

    ARM 2005 “Declarative Region” 8.1(16)

    NOTES
    The children of a parent library unit are inside the
    parent's declarative region, even though they do not
    occur inside the parent's declaration or body. This
    implies that one can use (for example) "P.Q" to refer
    to a child of P whose defining name is Q, and that
    after "use P;" Q can refer (directly) to that child.


I was also surprised the first time I meet this, and though I would have  
prefer an explicit With to be mandatory (I do not enjoy implicit a lot).

By the way, this make me think about a question : when a child package  
does not formally requires a view on its parent, is it to be considered a  
design error ? This may occurs.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/1/10 6:16 PM, Yannick Duchêne (Hibou57) wrote:
> Le Mon, 01 Nov 2010 12:50:50 +0100, (see below) <yaldnif.w@blueyonder.co.uk> a écrit:
>>> Children always have visibility into the specs of their ancestors, so you
>>> never need to "with" said ancestors.
>>
>> While the first claim is true, the second does not follow, as I am given to
>> understand it.
>>
>> If you need:
>>
>> pragma Elaborate_All(<ancestor>);
>>
>> Then you also need:
>>
>> with <ancestor>;
> I've just checked it with GNAT, it did not return an error. <ancestor> is implicitly withed even with Elaborate_All. No special case with this pragma.
>
>

Which GNAT is this?  I get

$ gnatmake -gnatl -gnatf ancestor-child.ads
gcc -c -gnatl -gnatf ancestor-child.ads

GNAT GPL 2010 (20100603)
Copyright 1992-2010, Free Software Foundation, Inc.


Compiling: ancestor-child.ads (source file time stamp: 2010-11-01 17:26:24)

      1. pragma elaborate_all(ancestor);
                              |
         >>> argument of pragma "elaborate_all" is not withed unit

      2. package ancestor.child is
      3. end ancestor.child;

  3 lines: 1 error
gnatmake: "ancestor-child.ads" compilation error

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 18:06:19 +0100, Mart van de Wege <mvdwege@mail.com> a  
écrit:
>> You could have appended "_Type" to the type declaration giving
>> "Character_Type."
>> This gives the added advantage of allowing your parameters to be
>> highly descriptive, especially if you use named-association when
>> calling the parameters.
>>
> That's another way around it. Nice. Thanks.

This is required because there is no dedicated name-space for types in Ada.

But this is not the only reason, as you may also use postfix to express  
overall semantic traits. As an example, if you've designed a type Foo  
which has Reference Semantic (as opposed to Value Semantic), you may name  
it Foo_Access (note: a type may have Reference Semantic even if it is not  
actually an access type). So that when you see a declaration like  
“My_Entity : Foo_Access;”, you immediately see My_Entity has Reference  
Semantic… and that may help to understand the source, as you may  
understand a copy of My_Entity to My_Entity_Copy will not have the usual  
effect.

Another common convention, is to use the suffix “_Kind” on enumerations.  
As an example, you have an enumeration type declared like this :

    type Chocolate_Tablet_Kind is (Big, Medium, Small);

This convention appears as an example in the ASIS library (which you may  
discover later).

There are others, while just a few (there must not be too much). I  
personally use “_Class” and some others also use “_Array”.

Similar applies with some project conventions which requires the use of  
“_Generic” or “_G” for generic packages.

But all of this, is still a debatable subject ;)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 18:27:56 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
>> I've just checked it with GNAT, it did not return an error. <ancestor>  
>> is implicitly withed even with Elaborate_All. No special case with this  
>> pragma.
>>
>>
>
> Which GNAT is this?  I get
The GNAT which come with MinGW and GCC 4.5

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 18:41:14 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Le Mon, 01 Nov 2010 18:27:56 +0100, Georg Bauhaus  
> <rm-host.bauhaus@maps.futureapps.de> a écrit:
>>> I've just checked it with GNAT, it did not return an error. <ancestor>  
>>> is implicitly withed even with Elaborate_All. No special case with  
>>> this pragma.
>>>
>>>
>>
>> Which GNAT is this?  I get
> The GNAT which come with MinGW and GCC 4.5
Sorry, I've made an error, I did it on a file which had a with clause  
before (did not see). I checked it again, and there is indeed an error  
“Argument of pragma "Elaborate_All" is not a withed unit.”


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Mart van de Wege]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Mon, 01 Nov 2010 18:06:19 +0100, Mart van de Wege
> <mvdwege@mail.com> a écrit:
>>> You could have appended "_Type" to the type declaration giving
>>> "Character_Type."
>>> This gives the added advantage of allowing your parameters to be
>>> highly descriptive, especially if you use named-association when
>>> calling the parameters.
>>>
>> That's another way around it. Nice. Thanks.
>
> This is required because there is no dedicated name-space for types in Ada.
>
Yes, I've seen that before.

<snip explanation>

Thanks.

> Another common convention, is to use the suffix “_Kind” on
> enumerations. As an example, you have an enumeration type declared
> like this :
>
>    type Chocolate_Tablet_Kind is (Big, Medium, Small);
>
> This convention appears as an example in the ASIS library (which you
> may discover later).
>
> There are others, while just a few (there must not be too much). I
> personally use “_Class” and some others also use “_Array”.
>
Heh. The _Array suffix came rather naturally, as the domain-specific
term actually is 'Ability Array'. 'Class' however will clash rather
badly, as that is another domain-specific term (hmmm. Class_Class. That
would be funny).

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Beginners question: Compound types, how-to?

[Adam Beneschan]

On Nov 1, 10:16 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Mon, 01 Nov 2010 12:50:50 +0100, (see below)  
> <yaldni...@blueyonder.co.uk> a écrit:>> Children always have visibility into the specs of their ancestors, so  
> >> you
> >> never need to "with" said ancestors.
>
> > While the first claim is true, the second does not follow, as I am given  
> > to
> > understand it.
>
> > If you need:
>
> >   pragma Elaborate_All(<ancestor>);
>
> > Then you also need:
>
> >   with <ancestor>;
>
> I've just checked it with GNAT, it did not return an error.  <ancestor> is  
> implicitly withed even with Elaborate_All. No special case with this  
> pragma.

Then this version of GNAT is wrong.

The visibility rules for context clauses (the WITH and USE clauses and
pragmas appearing before the top-level PACKAGE, PROCEDURE, FUNCTION,
etc.) are different from the normal visibility rules.  See 10.1.6 and
especially paragraph 3.  Jeff was correct except with respect to
context clauses (an easy thing to forget).

Please don't rely on GNAT, or any other compiler, to determine whether
something is legal Ada or not.  None of them is perfect at getting the
language rules correct.

                                            -- Adam

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/01/2010 12:12 AM, Mart van de Wege wrote:
> Jeffrey Carter<spam.jrcarter.not@spam.not.acm.org>  writes:
>>
>> Children always have visibility into the specs of their ancestors, so
>> you never need to "with" said ancestors.
>>
> Cool. I missed this tidbit in the texts I read. I suppose this *is*
> spelled out in the Reference Manual?

Everything is spelled out in the ARM, but it's not necessarily easy to find, 
read, or understand.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/01/2010 10:06 AM, Mart van de Wege wrote:
> Shark8<onewingedshark@gmail.com>  writes:
>
>> You could have appended "_Type" to the type declaration giving
>> "Character_Type."
>> This gives the added advantage of allowing your parameters to be
>> highly descriptive, especially if you use named-association when
>> calling the parameters.
>>
> That's another way around it. Nice. Thanks.

No, not nice. Terrible.

"_Type" is just noise; you could use "_Global_Nuclear_Warfare" just as well. You 
should never be adding unnecessary noise to your code.

S/W engineering involves putting in the effort to think of good names for 
everything in your code. "_Type" is a kludge to avoid doing that thinking.

In this case, the type defines the information for dealing with a Character, so 
I'd probably use Character_Info as the type name.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/01/2010 12:14 AM, Mart van de Wege wrote:
> Yes, I was. Silly C experience led me to believe 'Character' was a
> perfectly fine identifier.

Character /is/ a perfectly fine identifier. You just have to be aware of that 
it's also used in Standard, and thus visible everywhere.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/01/2010 04:50 AM, (see below) wrote:
> On 01/11/2010 04:55, in article iale5p$2f6$1@tornado.tornevall.net, "Jeffrey
> Carter"<spam.jrcarter.not@spam.not.acm.org>  wrote:
>
>> Children always have visibility into the specs of their ancestors, so you
>> never need to "with" said ancestors.
>
> While the first claim is true, the second does not follow, as I am given to
> understand it.
>
> If you need:
>
>    pragma Elaborate_All(<ancestor>);
>
> Then you also need:
>
>    with<ancestor>;

True. I don't expect a beginner to be dealing with elaboration issues, and so 
was referring only to visibility.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 20:19:51 +0100, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:
> No, not nice. Terrible.
>
> "_Type" is just noise; you could use "_Global_Nuclear_Warfare" just as  
> well. You should never be adding unnecessary noise to your code.

Actually, this convention appears in many places, like the ARM. Ex:

    subtype Buffer_Type is
       System.Storage_Elements.Storage_Array (1..Buffer_Size);

And to talk about good names, you may agree _Global_Nuclear_Warfare does  
not express the same at all as _Type does. This is even more clear if you  
have some _Access.

>
> S/W engineering involves putting in the effort to think of good names  
> for everything in your code. "_Type" is a kludge to avoid doing that  
> thinking.
Names, roles, behavior, traits, and so on. There are many place where the  
sole surrounding context is not enough.

> In this case, the type defines the information for dealing with a  
> Character, so I'd probably use Character_Info as the type name.
If the design is good, then Character already holds what identifies a  
Character. With OO design, this _Info is then implicit and every where  
(this one, is really noise ;) )


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Shark8]

On Nov 1, 1:19 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:
> On 11/01/2010 10:06 AM, Mart van de Wege wrote:
>
> > Shark8<onewingedsh...@gmail.com>  writes:
>
> >> You could have appended "_Type" to the type declaration giving
> >> "Character_Type."
> >> This gives the added advantage of allowing your parameters to be
> >> highly descriptive, especially if you use named-association when
> >> calling the parameters.
>
> > That's another way around it. Nice. Thanks.
>
> No, not nice. Terrible.
>
> "_Type" is just noise; you could use "_Global_Nuclear_Warfare" just as well. You
> should never be adding unnecessary noise to your code.

I like the "_Type" more than the prefix of "The_" used in parameters
within the Booch book on reusable Ada components (I don't like how the
resultant calls look using named association).

Push ( The_Stack => This_Stack, Item => Integer'(137) );
vs
Push( Stack => This_Stack, Item => Integer'(137) );

I'll quite agree that it is [mostly] a matter of preference/taste, but
to my thinking having the "_Type" appended for the type declaration is
a little bit of redundancy {which is not always bad, else why do you
carry a spare tire?}.

Most of the places you'll use the "_Type" suffix would be in
parameters [within the specification of a function/procedure] and in
variable declarations.
In the case of the specifications
Procedure Push ( The_Stack : in out Stack; Value : in Integer );
and
Procedure Push( Stack : in out Stack_Type; Value in Integer );
are not all that different; where the 'noise' comes in is the only
difference; in one it attaches to the parameter-type portion of the
declaration, in the other it attaches to the parameter-name portion.

To my thinking there will often be many more calls to the procedure
comparative to the number of times it is declared [perhaps twice, once
in the spec and once in the body]; this argument applies within the
procedure itself AND with regard to variable declaration/usage. Very
rarely will you declare a variable and not use it; opposed to the
common case of using a variable multiple times to its one declaration.

>
> S/W engineering involves putting in the effort to think of good names for
> everything in your code. "_Type" is a kludge to avoid doing that thinking.
>

True enough. However, there is the argument that the "_Type" 'kludge'
is a valid way of presenting a publicly-visible/usable spec to your
user in such a way as to reduce ambiguity; see above.

What we're seeing is the first-cousin of the "class of type" vs
"object of [class of] type" phenomena; the two are distinct ideas yet
intimately linked.

> In this case, the type defines the information for dealing with a Character, so
> I'd probably use Character_Info as the type name.

Perfectly valid choice.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 20:59:27 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:
> I'll quite agree that it is [mostly] a matter of preference/taste, but
> to my thinking having the "_Type" appended for the type declaration is
> a little bit of redundancy {which is not always bad, else why do you
> carry a spare tire?}.

The case of _Type is the most exposed one, while the more confusing one in  
the mean time, and that does not help.

To be clearer, in two parts and a short conclusion.

First there is a need due to the lack of a name-space for types. When one  
choose a word, this word is typically the same for both type and instance,  
as there is nothing like a type and instance in the natural language,  
where instead of types, there is are prototypes, a prototype which is  
something else than a special instance (which may be an idealization and  
may not really exist). So a Book type is something which define a book,  
any book anonymously. When instances all refers to particular instances of  
a books, like Ichbia's book, Rosen's book, there is no trouble, as you may  
have instances like Ichbia_Book, Rosen_Book. Except these kind of  
instances, will more stands for constants only. As typical instances of a  
Book type will be variables, they will be anonymous on their own (as-is).  
So, the Book type, which defines a book anonymously and an instance of  
that type, which is to be, by definition of what a type is, an instance of  
any book possibly defined by the Book type, will be as much anonymous, and  
will refer to the same things. Except if that anonymous instance has a  
particular role, which would make it distinct (thus, not so much  
anonymous), the only difference is : one is the definition the other is  
the instance. That is the sole difference, so it will have the same name,  
so there will be a name clash, so to mark the difference, we need  
something, either for the type name or the instance name. Instance appears  
more frequently used than type, so that it is less obfuscating to add  
_Type to type name, than to add The_, A_ or An_ to the instance names.

Then, _Type marks what a basic type is : value semantic, not class-wide.  
So at first sight, this seems un-useful, providing we forget about the  
above (because due to the above, solely, we need _Type). If there was  
nothing else and no Reference Semantic and no Class Wide, then indeed,  
_Type would be u-useful. But there are some! _Type, as it stands for the  
basic of a type, then makes more sense if one do not think about it  
solely, but also think its peers, like _Class, _Abstract, _Accees, and  
_Class_Access (I would like to have something in a single word meaning  
_Class_Access, but never found one). You would indeed not have any need to  
name colors if there were only one colors, but as there are many colors,  
you actually need to name these.

So there are two orthogonal reasons for _Type. The first is a kind of  
workaround, and for the second one, its usefulness only appears when you  
look wide enough.

This is the source of lacks of understanding, as well as the source of  
incomplete justifications to say _Type is un-useful (you may be able to  
justification _Type is not good, as long as you forget about the things  
explained above, but this actually exist).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/01/2010 12:41 PM, Yannick Duchêne (Hibou57) wrote:
>
> Actually, this convention appears in many places, like the ARM. Ex:
>
> subtype Buffer_Type is
> System.Storage_Elements.Storage_Array (1..Buffer_Size);

Yes, some parts of the ARM are badly designed.

> And to talk about good names, you may agree _Global_Nuclear_Warfare does
> not express the same at all as _Type does.

And I may not. _Global_Nuclear_Warfare expresses exactly the same thing as 
_Type: nothing.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/01/2010 12:59 PM, Shark8 wrote:
>
> I like the "_Type" more than the prefix of "The_" used in parameters
> within the Booch book on reusable Ada components (I don't like how the
> resultant calls look using named association).
>
> Push ( The_Stack =>  This_Stack, Item =>  Integer'(137) );
> vs
> Push( Stack =>  This_Stack, Item =>  Integer'(137) );

Yes, prefixes are bad.

Push (Onto => Operands, ...

Type names are not the only names for which a S/W engineer should make the 
effort to think of good names.

>> S/W engineering involves putting in the effort to think of good names for
>> everything in your code. "_Type" is a kludge to avoid doing that thinking.
>>
> True enough.

Well, if you're going to admit to not being a S/W engineer, then we can ignore 
anything you have to say :)

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 21:56:53 +0100, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:
> And I may not. _Global_Nuclear_Warfare expresses exactly the same thing  
> as _Type: nothing.
So you may enjoy to learn the ARM defines type and subtypes section 3.2 :p
http://www.adaic.org/standards/05rm/html/RM-3-2.html
(teasing)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> By the way, this make me think about a question : when a child package
> does not formally requires a view on its parent, is it to be
> considered a design error ? This may occurs.

Well, there needs to be _some_ reason! It's not uncommon to have a
top-level package with no functionality other than to provide a separate
namespace. For example,

   --  This is the parent package for a library of useful units provided
   --  with GNAT

   package GNAT is
      pragma Pure;
   end GNAT;

Re: Beginners question: Compound types, how-to?

[Shark8]

On Nov 1, 3:01 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:
>
> >> S/W engineering involves putting in the effort to think of good names for
> >> everything in your code. "_Type" is a kludge to avoid doing that thinking.
>
> > True enough.
>
> Well, if you're going to admit to not being a S/W engineer, then we can ignore
> anything you have to say :)

Well, that is completely ignoring the artistic portion of Computer
Science...
to say that "names must be meaningful" involves a subjective [and
arguably artistic] context
within which to judge the "meaningfulness" thereof.

For example the names [一番の作，　二番の作，　三番の作，四番の作]* likely mean nothing to
you; but to the Japanese
programmer (and quite probably the Chinese one) these are the quite
meaningful identifiers
'first work', 'second work'. 'third work' and 'fourth work' where
"work" is completely analogous to task and
[perhaps] the context is that of a scheduling-system which only needs/
allows for four arbitrary tasks.

Furthermore, as I explained [or tried to], in the case of a
specification which may be used by someone else
then the goal actually IS to be unambiguous and alleviate the
'thinking' required by someone reading/using the code.
We don't want the manager or the junior-programmer to spend five
minutes on trying to understand if it is an object
or a type which you are referring to. In natural language the
distinction doesn't really exist [to my knowledge] and it
is relied upon the context to [implicitly] determine what is meant.

Perhaps, as a way of example we could say that the following verbosity
could provide the proper distinction and allow for
the "proper" naming of both types and variables:

Push( Stack as Variable : in out Stack as Type; Item : in Integer );
which could be used as: Push( Stack => Forth.Data_Stack, Item => 23 );
in a hypothetical implementation/interface of/to a Forth interpreter.

Re: Beginners question: Compound types, how-to?

[Shark8]

On Nov 1, 2:43 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
>
> So there are two orthogonal reasons for _Type. The first is a kind of  
> workaround, and for the second one, its usefulness only appears when you  
> look wide enough.

You explain entirely what I was trying to say in these two sentences.

> This is the source of lacks of understanding, as well as the source of  
> incomplete justifications to say _Type is un-useful (you may be able to  
> justification _Type is not good, as long as you forget about the things  
> explained above, but this actually exist).
>
> --
> Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
> les chiens.

Thank you.

Re: Beginners question: Compound types, how-to?

[Brian Drummond]

On Mon, 01 Nov 2010 14:05:02 +0100, Mart van de Wege <mvdwege@mail.com> wrote:

>Brian Drummond <brian_drummond@btconnect.com> writes:

>> Likewise Str ... String? Strength? Strangeness? Write them in full;
>> you'll thank yourself later. If you don't like typing long words,
>> either find an editor with an autocomplete function, or learn to use
>> "renames".
>>
>Str = Strength.
>
>As Florian said, those are domain-specific abbreviations. Anyone who
>plays role-playing games will know what they mean, anyone who doesnt
>doesn't have any use for my code anyway. 

If they are as embedded in an rpg-programmer's mind as "abs and "rem" to a
numerical programmer, then that's fine. Otherwise...

One of the things I really like about Ada is the traceability of what's visible
and where it comes from. It really helps understanding, especially when the
author has found the right balance of "use pkg_name;" and fully qualifying names
"pkg_name.type_name" so you are led directly to the source of "typename" etc.

Some people insist on never using "use" clauses, always qualifying names. I can
see their point but feel that's going a bit too far...

- Brian

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Mon, 01 Nov 2010 23:45:36 +0100, Brian Drummond  
<brian_drummond@btconnect.com> a écrit:
> Some people insist on never using "use" clauses, always qualifying  
> names. I can
> see their point but feel that's going a bit too far...
I understand the point. However, to have “package IO renames Ada.Text_IO;”  
and do some “IO.New_Line;” is not a nightmare too. There is also  
subprogram renaming, which allow to move frequently used subprograms to be  
referred to without any prefix. These are two alternatives to Use, not so  
bad. To got further, you may add renaming at the top of a package, and you  
may, as an example, only add renaming for output subprograms. This show  
you what Ada.Text_IO is used for exactly. Tell there is a dependency to a  
package is nice, tell why (and what) is even more succulent.

Some languages which also have packages, like Oberon and Modula-2, has  
another pleasant way : you can selectively import without the need of  
renaming. If you have a unit (the Pascal-heir's name for package) named  
Foo you can import Foo.Bar, Foo.That. I am not sure about the syntax, I  
forget too much, and I do not know if the compiler is required to return  
an error if ever Bar is overloaded in Foo. The difference with Ada, is  
that you do not have to rewrite all the signature. This is a not so bad  
idea, as anyway, when you Use, the signatures are not recalled anywhere  
neither, so this is not more obscure than an import Foo.Bar. This has the  
advantage of being more lightweight, and thus may appeal to use it more  
oftenly.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Adam Beneschan]

On Nov 1, 12:19 pm, Jeffrey Carter
<spam.jrcarter....@spam.not.acm.org> wrote:
> On 11/01/2010 10:06 AM, Mart van de Wege wrote:
>
> > Shark8<onewingedsh...@gmail.com>  writes:
>
> >> You could have appended "_Type" to the type declaration giving
> >> "Character_Type."
> >> This gives the added advantage of allowing your parameters to be
> >> highly descriptive, especially if you use named-association when
> >> calling the parameters.
>
> > That's another way around it. Nice. Thanks.
>
> No, not nice. Terrible.
>
> "_Type" is just noise; you could use "_Global_Nuclear_Warfare" just as well. You
> should never be adding unnecessary noise to your code.
>
> S/W engineering involves putting in the effort to think of good names for
> everything in your code. "_Type" is a kludge to avoid doing that thinking.
>
> In this case, the type defines the information for dealing with a Character, so
> I'd probably use Character_Info as the type name.

I kind of like the idea of coming up with a synonym instead.  The word
"Character" is just used *too* commonly in programming, regardless of
the programming language, to refer to a small piece of data that
usually represents a single letter in some language, digit,
punctuation mark, or other special symbol.  Using this name, or any
variant of it (like Character_Type or Character_Info), for some other
meaning (like a character in a play) is IMHO just going to confuse
things for other programmers trying to read your code.

Of course, if you're the only one who's ever going to read your code,
you can call it any bloody thing you like, like Ch or CXRQS or
Global_Nuclear_Warfare (although the last would be appropriate only if
your Character is played by Matthew Broderick....)

                              -- Adam

Re: Beginners question: Compound types, how-to?

[Stephen Leake]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 11/01/2010 10:06 AM, Mart van de Wege wrote:
>> Shark8<onewingedshark@gmail.com>  writes:
>>
>>> You could have appended "_Type" to the type declaration giving
>>> "Character_Type."
>>> This gives the added advantage of allowing your parameters to be
>>> highly descriptive, especially if you use named-association when
>>> calling the parameters.
>>>
>> That's another way around it. Nice. Thanks.
>
> No, not nice. Terrible.

_Type vs "waste time thinking up other names" is a religious argument
(guess which side I'm on?); it has never been settled before, and won't
be settled this time.

Just for the record, there is a third way; use the full names
Parent.Character, Standard.Character.

-- 
-- Stephe

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Tue, 02 Nov 2010 09:17:29 +0100, Stephen Leake  
<stephen_leake@stephe-leake.org> a écrit:
> _Type vs "waste time thinking up other names" is a religious argument
This one is not an argument ;)
Tell more please.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Dmitry A. Kazakov]

On Tue, 02 Nov 2010 00:17:53 +0100, Yannick Duch�ne (Hibou57) wrote:

> The difference with Ada, is  
> that you do not have to rewrite all the signature.

Ada supports overloading that is the reason why the ultimate name of a
subprogram in effect includes its arguments/result profile, additionally to
the call name. This is somewhat in breach with the idea of nominal matching
of things, so the inconvenience people feel about it. But it is not very
clear how to fix that. Nobody cares too, because subprograms are not first
class citizens. If Ada wished to become more "functional" (not that I
wanted its evolution in this direction), then it would have to resolve this
issue.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Beginners question: Compound types, how-to?

[Dmitry A. Kazakov]

On Tue, 02 Nov 2010 09:29:55 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Tue, 02 Nov 2010 09:17:29 +0100, Stephen Leake  
> <stephen_leake@stephe-leake.org> a �crit:
>> _Type vs "waste time thinking up other names" is a religious argument
> This one is not an argument ;)

It is. The question where between the implementation and the application
domains to search for names is religious. "xxx_Type" is the implementation
[language] side. "Character" is in the middle [general CS/programming]. The
domain's end could be "Zodiac_Sign" [Astronomy]. There are good arguments
against both ends, and the silent majority sticks to the middle leaning to
either end.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Beginners question: Compound types, how-to?

[J-P. Rosen]

Le 01/11/2010 00:27, Yannick Duchêne (Hibou57) a écrit :
> This recall me a similar thing I get a little long time ago. I wanted to
> define a String type which I expected to hide the one of Standard, but
> always failed. I asked about it on a forum after I've checked the
> reference manual that time. I was thinking visibility rules was so that
> I was allowed to hide something from Standard, did not found anything
> stating the opposite, and finally never get an answer to this old question.
Standard is just the parent package of every compilation unit, and there
is no problem in *hiding* things declared in Standard with locally
declared in identifiers, regular visibility rules apply.

However, what confuses people is that use clauses are weaker than direct
visibility. Therefore, if your "string" type is defined in package P and
you "use P;", the String you get is Standard.String (directly visible),
not P.String (use-visible).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a déménagé / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/02/2010 01:17 AM, Stephen Leake wrote:
>
> _Type vs "waste time thinking up other names" is a religious argument
> (guess which side I'm on?); it has never been settled before, and won't
> be settled this time.

Those who think the essential S/W-engineering activity of choosing good names is 
a waste of time are clearly not S/W engineers.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Tue, 02 Nov 2010 20:02:25 +0100, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:

> On 11/02/2010 01:17 AM, Stephen Leake wrote:
>>
>> _Type vs "waste time thinking up other names" is a religious argument
>> (guess which side I'm on?); it has never been settled before, and won't
>> be settled this time.
>
> Those who think the essential S/W-engineering activity of choosing good  
> names is a waste of time are clearly not S/W engineers.
What is the choice of _Type (or _Xyz) if not a choice about names ? (a  
consistent choice by the way)


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Tue, 02 Nov 2010 20:02:25 +0100, Jeffrey Carter
> <spam.jrcarter.not@spam.not.acm.org> a écrit:
>
>> On 11/02/2010 01:17 AM, Stephen Leake wrote:
>>>
>>> _Type vs "waste time thinking up other names" is a religious
>>> argument (guess which side I'm on?); it has never been settled
>>> before, and won't be settled this time.
>>
>> Those who think the essential S/W-engineering activity of choosing
>> good names is a waste of time are clearly not S/W engineers.

> What is the choice of _Type (or _Xyz) if not a choice about names ? (a
> consistent choice by the way)

Consistent with what? You can't quote File_Type, Buffer_Type from the
ARM without explaining Integer, Float etc (I think these different
styles must have come from different authors).

I _think_ that Jeffrey's point is that, given weapons such as
broadsword, catapult, torpedo you might write C like

   typedef enum {BROADSWORD, CATAPULT, TORPEDO} Weapon;
   void attackUsing(Weapon weapon);

and rather than write this in Ada

   type Weapon_Type is (Broadsword, Catapult, Torpedo);
   procedure Attack_Using (Weapon : Weapon_Type);

it would be better to say

   type Weapon is (Broadsword, Catapult, Torpedo);
   procedure Attack (Using : Weapon);

Anyway, that's what my project style guide says. 

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/02/2010 12:22 PM, Yannick Duchêne (Hibou57) wrote:
>>
>> Those who think the essential S/W-engineering activity of choosing
>> good names is a waste of time are clearly not S/W engineers.
> What is the choice of _Type (or _Xyz) if not a choice about names ? (a
> consistent choice by the way)

You forgot the important word: "good".

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: Beginners question: Compound types, how-to?

[Britt Snodgrass]

On Nov 2, 2:02 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:
> On 11/02/2010 01:17 AM, Stephen Leake wrote:
>
> > _Type vs "waste time thinking up other names" is a religious argument
> > (guess which side I'm on?); it has never been settled before, and won't
> > be settled this time.
>
> Those who think the essential S/W-engineering activity of choosing good names is
> a waste of time are clearly not S/W engineers.
>

Bah. Pick a good type name and then suffix it with "_Type". That makes
it an even better type name.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/2/10 9:59 PM, Britt Snodgrass wrote:
> On Nov 2, 2:02 pm, Jeffrey Carter<spam.jrcarter....@spam.not.acm.org>
> wrote:
>> On 11/02/2010 01:17 AM, Stephen Leake wrote:
>>
>>> _Type vs "waste time thinking up other names" is a religious argument
>>> (guess which side I'm on?); it has never been settled before, and won't
>>> be settled this time.
>>
>> Those who think the essential S/W-engineering activity of choosing good names is
>> a waste of time are clearly not S/W engineers.
>>
>
> Bah. Pick a good type name and then suffix it with "_Type". That makes
> it an even better type name.

Arguing from suitably chosen context about the suffix
being helpful (and thus implying that the language is not
sufficiently well equipped for this kind of help) one might
be tempted to write

   procedure Attack_Proc (Weapon_Parm_Name : Weapon_Type);

But consider how the body looks.
And then consider what calls must look like.

Sill, a different grammar(!) might lead to better visual
distinction. (Which words are types' names etc.)
A grammatical approach seems a lot better to me than
injecting a mechanical sublanguage into identifiers!!!

Please don't mistake this suggestion to be in favor
of separate namespaces for types and other things.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
> Sill, a different grammar(!) might lead to better visual
> distinction. (Which words are types' names etc.)
> A grammatical approach seems a lot better to me than
> injecting a mechanical sublanguage into identifiers!!!
There is exactly *no* grammatical approach to this. This is the core of  
the rationals I gave yesterday (or the day before).

If such an approach was there in natural languages, I would be glad to use  
it; I've never felt the need to reinvent the plural for computer languages  
(except when that plural is unluckily invariable, and when that occurs, I  
feel free to play a bit and do some dirty things with grammar, especially  
with English and its never-plural adjectives)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Dmitry A. Kazakov]

On Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus wrote:

> Sill, a different grammar(!) might lead to better visual
> distinction. (Which words are types' names etc.)
> A grammatical approach seems a lot better to me than
> injecting a mechanical sublanguage into identifiers!!!

Natural grammar use article and/or inflexion to separate instances and
groups. So:

   procedure Attack (A_Weapon : Weapon);

or

   procedure Attack (Weapon : Weapon_Type);

is more or less how natural languages handle this.

But in a programming language both approaches look somewhat bad.

And so far no multi-methods were considered. But if we did:

   procedure Parry (My_Weapon : Weapon; His_Weapon : Weapon);

Or, maybe, would you introduce grammatical cases? (:-))

   procedure Parry (
      (*instrumental case*) Weapon : Weapon;
      (*accusative case*) Weapon : Weapon );

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Searching for "_Type" discussions

[Stephen Leake]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Tue, 02 Nov 2010 09:17:29 +0100, Stephen Leake
> <stephen_leake@stephe-leake.org> a écrit:
>> _Type vs "waste time thinking up other names" is a religious argument
> This one is not an argument ;)
> Tell more please.

"search comp.lang.ada" for "_Type suffix"

-- 
-- Stephe

Re: Beginners question: Compound types, how-to?

[Stephen Leake]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 11/02/2010 01:17 AM, Stephen Leake wrote:
>>
>> _Type vs "waste time thinking up other names" is a religious argument
>> (guess which side I'm on?); it has never been settled before, and won't
>> be settled this time.
>
> Those who think the essential S/W-engineering activity of choosing
> good names is a waste of time are clearly not S/W engineers.

Ok, you seduced me into arguing again. After all, I have _some_ pride :).

Those who don't understand the purely syntactic role of the _Type suffix
are clearly not S/W engineers. 

I didn't say "don't choose good names". I said "don't waste time
choosing names when _Type will do perfectly".

I bear some blame; I should have presented the religious argument in a
more balanced way when trying to terminate it.

Sigh.

Can we get back to real issues now?

-- 
-- Stephe

Re: _Type vs no _Type

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> I _think_ that Jeffrey's point is that, given weapons such as
> broadsword, catapult, torpedo you might write C like
>
>    typedef enum {BROADSWORD, CATAPULT, TORPEDO} Weapon;
>    void attackUsing(Weapon weapon);
>
> and rather than write this in Ada
>
>    type Weapon_Type is (Broadsword, Catapult, Torpedo);
>    procedure Attack_Using (Weapon : Weapon_Type);
>
> it would be better to say\
>
>    type Weapon is (Broadsword, Catapult, Torpedo);
>    procedure Attack (Using : Weapon);
>

Yes, this summarizes the argument.

The core of the argument is about what metric to use for "better". Those
on the _Type side say the first choice is "better", because it requires
trivial thought both for writing and reading, and leads to different
programmers making the same choice for names.

Those on the "no _type" side say the second choice is better, because
better names are better, and _type is "just noise".

The third choice is:

package RPG is

   type Weapon is (Broadsword, Catapult, Torpedo);
   procedure Attack (Weapon : RPG.Weapon);

end RPG;

That was not introduced until after the two camps were firmly
established. I actually think this third choice is more in the spirit of
Ada than either of the other two. I've used it in a couple small
projects, but my main projects are firmly committed to the _Type
convention.

Consistent conventions are _far_ more important than any reasons
supporting _type vs no _type.

-- 
-- Stephe

Re: Beginners question: Compound types, how-to?

[Stephen Leake]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

> On 11/2/10 9:59 PM, Britt Snodgrass wrote:
>> On Nov 2, 2:02 pm, Jeffrey Carter<spam.jrcarter....@spam.not.acm.org>
>> wrote:
>>> On 11/02/2010 01:17 AM, Stephen Leake wrote:
>>>
>>>> _Type vs "waste time thinking up other names" is a religious argument
>>>> (guess which side I'm on?); it has never been settled before, and won't
>>>> be settled this time.
>>>
>>> Those who think the essential S/W-engineering activity of choosing good names is
>>> a waste of time are clearly not S/W engineers.
>>>
>>
>> Bah. Pick a good type name and then suffix it with "_Type". That makes
>> it an even better type name.
>
> Arguing from suitably chosen context about the suffix
> being helpful (and thus implying that the language is not
> sufficiently well equipped for this kind of help) one might
> be tempted to write
>
>   procedure Attack_Proc (Weapon_Parm_Name : Weapon_Type);

The reason we need different names for the parameter and the type is
because they are not in separate name spaces in Ada. So it is true that
"the language is not sufficiently well equipped for this kind of help".
That's something else the "no _Type" side does not want to admit.

Procedure names don't have that problem, since they can be overloaded. 

So the only place a "pure syntax noise" solution is needed in on type
names. 

One characteristic of religious arguments is putting up straw-man
arguments like this.

> Sill, a different grammar(!) might lead to better visual
> distinction. (Which words are types' names etc.)
> A grammatical approach seems a lot better to me than
> injecting a mechanical sublanguage into identifiers!!!

If we are designing a new language, yes.

We don't get to change the grammar of Ada.

-- 
-- Stephe

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 03.11.10 09:58, Dmitry A. Kazakov wrote:
> On Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus wrote:
> 
>> Sill, a different grammar(!) might lead to better visual
>> distinction. (Which words are types' names etc.)
>> A grammatical approach seems a lot better to me than
>> injecting a mechanical sublanguage into identifiers!!!
> 
> Natural grammar use article and/or inflexion to separate instances and
> groups. So:

Natural grammar, OK...

X drove a dagger into his leg.  -- accusative :-)
Y used the kitchen knife as weapon.  -- instrumental

  procedure Pick_for_Attack
    (Self : in out Person; Instrument : Weapon);

  procedure Fight  -- symmetric relation (now)
    (Self : in out Person: Other : in out Person);


>    procedure Attack (A_Weapon : Weapon);
> 
> or
> 
>    procedure Attack (Weapon : Weapon_Type);

There is no end to constructing contexts, very general
ones and very specific ones, and hardly ever complete.
Some will prefer one or the other. Others will present
an example with generality of wording reversed.  That's
not statistical evidence. I'll prefer convincing evidence
when deciding for or against a set of grammar rules.

But accusative and instrumental are good examples.
Consider verbs and adverbs in some programming languages.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 03.11.10 02:59, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus
> <rm-host.bauhaus@maps.futureapps.de> a écrit:
>> Sill, a different grammar(!) might lead to better visual
>> distinction. (Which words are types' names etc.)
>> A grammatical approach seems a lot better to me than
>> injecting a mechanical sublanguage into identifiers!!!
> There is exactly *no* grammatical approach to this. This is the core of the
> rationals I gave yesterday (or the day before).

(Recent NNTP agents seem to copy Outlook and make readers'
NNTP software present lengthy format=flowed plain text lines.
If, above the text view, one has tabular header views and
a subject listing with sender, date, etc. above, as is
usual, the text lines stretch across the entire window
unless one makes special efforts.  It'll be very kind of
you if you could tick the relevant box in Opera.)

Ada does have grammar to help readers sort
out the role of names in an Ada program.

For example, a word after a ':' (other than "in" etc,
other than a base_literal using obsolescent number sign
colon) is guaranteed to be a type's name. I don't think
this is "no support"?

Can a name placed before ':' be a type at all?
That's a good thing because it remove one decision.

Every "if" requiring context makes the number of
possible interpretations grow exponentially.
Reading effort is higher, which might be not so good.

() is syntactically overloaded. This may or may not be
what you want.

But '.', '=', '*', ... have very few syntactical meanings,
to be determined by context.  So there isn't exactly no
support for telling things apart.

I'll still like to have one name for one thing,
even if a grammar offers other ways to designate the
intended meaning of a name.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 03.11.10 13:18, Stephen Leake wrote:
> Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:
> 
>> On 11/2/10 9:59 PM, Britt Snodgrass wrote:
>>> On Nov 2, 2:02 pm, Jeffrey Carter<spam.jrcarter....@spam.not.acm.org>
>>> wrote:
>>>> On 11/02/2010 01:17 AM, Stephen Leake wrote:
>>>>
>>>>> _Type vs "waste time thinking up other names" is a religious argument
>>>>> (guess which side I'm on?); it has never been settled before, and won't
>>>>> be settled this time.
>>>>
>>>> Those who think the essential S/W-engineering activity of choosing good names is
>>>> a waste of time are clearly not S/W engineers.
>>>>
>>>
>>> Bah. Pick a good type name and then suffix it with "_Type". That makes
>>> it an even better type name.
>>
>> Arguing from suitably chosen context about the suffix
>> being helpful (and thus implying that the language is not
>> sufficiently well equipped for this kind of help) one might
>> be tempted to write
>>
>>   procedure Attack_Proc (Weapon_Parm_Name : Weapon_Type);
> 
> The reason we need different names for the parameter and the type is
> because they are not in separate name spaces in Ada. So it is true that
> "the language is not sufficiently well equipped for this kind of help".
> That's something else the "no _Type" side does not want to admit.
> 
> Procedure names don't have that problem, since they can be overloaded. 

Procedure names have the very same problem, because () is
overloaded (in the syntax, multiply, and with () pair dropping
allowed).  Should we therefore be in favor of an _Array suffix
style rule?  Or the other way around and suggest _Proc for when
() could be mistaken to mean array element?

> So the only place a "pure syntax noise" solution is needed in on type
> names. 

Given the above, I don't have to agree here.

> One characteristic of religious arguments is putting up straw-man
> arguments like this.

Not at all a straw-man argument, just not narrowing the case
to the favored issue. :-)

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 03.11.10 13:59, Georg Bauhaus wrote:

> Can a name placed before ':' be a type at all?
> That's a good thing because it remove one decision.
> 
> Every "if" requiring context makes the number of
> possible interpretations grow exponentially.
> Reading effort is higher, which might be not so good.

This was as clearly stated as the sky is, today.
Let me try again.

A name appearing before a ':' is not a type name.
Suppose a name appearing there is a homograph of a
type name.  In this case the reader will be
asking herself: "What kind of entity is this name
designating, a parameter, a type, something else?"
If such-and-such, it is a type name, if so-and-so,
it is a parameter name.  Or maybe even ...

So there are a number of ifs to be answered when you
want to decide what kind of entity is before you.

Ada grammar helps reducing the number of ifs
to be answered, but only to some extent.

For example,

procedure Increment (Integer : in out Integer) is
begin
   Integer := Integer'Succ(Integer);
end Increment;

This is decipherable both by compilers and by humans,
even when it is wrong (you couldn't otherwise say
that it is wrong.)

If you think that any of the following alternative
definitions look better, can you say why in each case?
And in which programming situations?

I don't think that the examples hinge only on programmers'
familiarity with type(!) name "Integer" (fixed in our
minds to be a type's name).  Trying another pair of names
shouldn't make a big difference.

1) Like Dmitry mentioned

procedure Increment (An_Integer : in out Integer) is
begin
   An_Integer := Integer'Succ(An_Integer);
end Increment;


2) IIRC, Bill Findlay uses this one (though not the name
"Integer" used for parameter names, I should think).
Apologies for dropping the name if not:

procedure Increment (Integer : in out An_Integer) is
begin
   Integer := An_Integer'Succ(Integer);
end Increment;


3) Stephen Leake's private rule:

procedure Increment (Integer : in out Standard.Integer) is
begin
   Integer := Standard.Integer'Succ(Integer);
end Increment;


4) The preference for _Type

procedure Increment (Integer : in out Integer_Type) is
begin
   Integer := Integer_Type'Succ(Integer);
end Increment;



5)  Combine (1) and (4) to get

procedure Increment (An_Integer : in out Integer_Type) is
begin
   An_Integer := Integer_Type'Succ(An_Integer);
end Increment;

But of course no one will be mixing styles. Never, right?

And the only confusion can ever arise from my weird
use of the name "Integer"?  OK, then, for example,

procedure Increment (T : in out T_Type) is
begin
   T := T_Type'Succ(T);
end Increment;

Try the other examples with different names, too.

Do you think that T always denotes a type?
Or only if used in this or that position?

All examples seem worthless;  the names are meaningful
only when program text is written to allude to language
defined things.  Such examples as use P for
packages, R for records, F for fields, and so on.

I expect that real programs leave much less difficulty
in choosing names that to *not* allude to Ada issues.
They will denote things from the problem domain, even
when the domain is a fairly abstract one.

Re: Beginners question: Compound types, how-to?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

=?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
news:op.vlibn4shule2fv@garhos: 

> Le Mon, 01 Nov 2010 20:19:51 +0100, Jeffrey Carter  
> <spam.jrcarter.not@spam.not.acm.org> a écrit:
>> No, not nice. Terrible.
>>
>> "_Type" is just noise; you could use "_Global_Nuclear_Warfare" just
>> as 
>   
>> well. You should never be adding unnecessary noise to your code.
> 
> Actually, this convention appears in many places, like the ARM. Ex:
> 
>     subtype Buffer_Type is
>        System.Storage_Elements.Storage_Array (1..Buffer_Size);
> 
> And to talk about good names, you may agree _Global_Nuclear_Warfare
> does  not express the same at all as _Type does. This is even more
> clear if you  have some _Access.
> 
>>
>> S/W engineering involves putting in the effort to think of good names
>  
>> for everything in your code. "_Type" is a kludge to avoid doing that 
>> thinking.

There is a good practical case for _Type, IMO. If Buffer_Type is defined 
simply as Buffer, then we develop an inconvenient name clash:

>     subtype Buffer is
>        System.Storage_Elements.Storage_Array (1..Buffer_Size);

In use now:

declare
   Buffer : Buffer;   -- hmmmm
begin
...

Buffer_Type avoids this difficulty:

declare
   Buffer : Buffer_Type;
begin
...

So while I'd agree that "_Type" is noisy, it is sometimes the right 
choice. If you can devise a better name for the type, like perhaps 
Storage_Buffer, then perhaps that is preferred.

Warren

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 03.11.10 17:56, Warren wrote:

> There is a good practical case for _Type, IMO. If Buffer_Type is defined 
> simply as Buffer, then we develop an inconvenient name clash:
> 
>>     subtype Buffer is
>>        System.Storage_Elements.Storage_Array (1..Buffer_Size);
> 
> In use now:
> 
> declare
>    Buffer : Buffer;   -- hmmmm
> begin

What role does the object named Buffer play?

It is a buffer, yes. Is it different from other buffers?
How?  What lives in it?  How does the program use it?

I believe answering these questions leads to a better name.

Re: Beginners question: Compound types, how-to?

[Vinzent Hoefler]

On Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:

> Please don't mistake this suggestion to be in favor
> of separate namespaces for types and other things.

Not that this would be a problem:

    Weapon_Procedures.Attack (Weapon : Weapon_Types.Weapon);


Vin"Just kidding"zent.

-- 
There is no signature.

Re: Beginners question: Compound types, how-to?

[Vinzent Hoefler]

On Wed, 03 Nov 2010 18:01:55 +0100, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:

> On 03.11.10 17:56, Warren wrote:
>
>> There is a good practical case for _Type, IMO. If Buffer_Type is defined
>> simply as Buffer, then we develop an inconvenient name clash:
>>
>>>     subtype Buffer is
>>>        System.Storage_Elements.Storage_Array (1..Buffer_Size);
>>
>> In use now:
>>
>> declare
>>    Buffer : Buffer;   -- hmmmm
>> begin
>
> What role does the object named Buffer play?
>
> It is a buffer, yes. Is it different from other buffers?

I now own it, thus it's "My_Buffer", of course. ;)

> How?  What lives in it?  How does the program use it?
>
> I believe answering these questions leads to a better name.

Yes, things like "Message_Buffer" are usually better here. Even a
generic name like "Read_Buffer" could help somewhat.


Vinzent.

-- 
There is no signature.

Re: Beginners question: Compound types, how-to?

[Warren]

Georg Bauhaus expounded in
news:4cd19583$0$6977$9b4e6d93@newsspool4.arcor-online.net: 

> On 03.11.10 17:56, Warren wrote:
> 
>> There is a good practical case for _Type, IMO. If Buffer_Type is
>> defined simply as Buffer, then we develop an inconvenient name clash:
>> 
>>>     subtype Buffer is
>>>        System.Storage_Elements.Storage_Array (1..Buffer_Size);
>> 
>> In use now:
>> 
>> declare
>>    Buffer : Buffer;   -- hmmmm
>> begin
> 
> What role does the object named Buffer play?
> 
> It is a buffer, yes. Is it different from other buffers?
> How?  What lives in it?  How does the program use it?
> 
> I believe answering these questions leads to a better name.

Ok, so the type is a Storage_Buffer. So is the instance
of the type.

Storage_Buffer : Storage_Buffer;

doesn't get us any closer to solving the problem. ;-)

Sometimes the number of instances is one -- matching the
type.  In cases like these you are still left with the 
task of making them different-- merely for the purpose
making them different.

Warren

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 18:01:55 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 03.11.10 17:56, Warren wrote:
>
>> There is a good practical case for _Type, IMO. If Buffer_Type is defined
>> simply as Buffer, then we develop an inconvenient name clash:
>>
>>>     subtype Buffer is
>>>        System.Storage_Elements.Storage_Array (1..Buffer_Size);
>>
>> In use now:
>>
>> declare
>>    Buffer : Buffer;   -- hmmmm
>> begin
>
> What role does the object named Buffer play?
>
> It is a buffer, yes. Is it different from other buffers?
> How?  What lives in it?  How does the program use it?
>
> I believe answering these questions leads to a better name.

Please, read all, up to the end (I am not totally contracting what I reply  
to, that is all about covering all cases).

It may be any Buffer : it is variable, not a constant (the buffer is not  
the better example here, but let go on with here)

Practical view : this buffer may (let imagine) be used consecutively for  
different things, and the analysis may say this is OK to have one buffer  
because of use always comes after the other (and the buffer may be big so  
we have to declare only one, to reach some specifications).

Abstract view : a Buffer_Type defines something. Right ? Now, what is a  
variable declared of type Buffer ? It is what is defined by the type  
Buffer, right ? (if this would be something different, then language or  
the compiler is really broken). Then, if you've named Buffer as Buffer,  
how will you name a variable of the same type without more (see later for  
the more) ? Use a different name ? But if you use a different name,  
doesn't that mean the name of the type could be different or is ambiguous  
? The good word to say what the type is, will be the same to say what the  
variable is (but there is one difference, see later).

First part of my agreement : I fully agree with the point “what is special  
with that buffer ?”. Ex. you have two buffers, one for input, one for  
output : “Input_Buffer : Buffer; Output_Buffer : Buffer;”. That sounds  
natural, OK. But some other times this is not feasible, because the entity  
declared of the type is simply fully generic (you can give it a tricky  
name, which will not sound natural, as the natural word is the one of the  
type, or else, the type does not hold the good name or holds an ambiguous  
name).

About the more : think about an inventory machine in a library, it has a  
method named Run_Inventory, and inside this, a loop and a book variable.  
This book has nothing special at all, as it is by definition, to hold any  
what book you may imagine. This variable, here, is, simply what the Book  
type, is. So your question is indeed very good : what is different ? The  
answer : one is a type, the other is an instance  So how do you name it ?  
With a name which expose the difference
  Either Book_Instance and Book or
else Book and Book_Type or even, if you like it Book_Instance and  
Book_Type. Book_Instance is the place for different name : A_Book,  
Any_Book, Current_Book, etc. What ever, you will add to the instance name,  
something which you reject for the type name (paradox ?).


Sometime it is possible to get ride of _Type, but sometime it is not  
always, and this is not predictable, and your design should cover the  
“always” otherwise it will hold a bug. If you decide it for the user, this  
is not good : premature decision. You cannot assert the user will never  
define very generic instance of that type (and there are common, see later  
[*]).

Now, how much or what is the average occurrence of generic use instance ?  
I would say, many (near to third or half, my experience says), at least  
with function and procedure parameters (especially when there is a single  
parameter of the same type, which is a common case), iterators, persistent  
storage, streams, intermediate expression, temporary variables, an so on;  
or else, simply the role is indicated by the outer scope and this is  
redundancy to add a mark for it to the variable. About the latter, what  
about “Inventored_Book” or “Current_Book” in the loop of the above  
inventory machine ? Is it worth to repeat it every where ? Does it really  
offers something to the reader ? (think of it in context)


You idea is good, but it does not cover all the range, and you are right,  
sometime, but not all the time. If an entity does not have enough thing  
special, you are not to invent it just to name it (this would not be to  
design anymore), you are to name it for what it is (that is design). And  
what if this has nothing special or else what is special with it, is  
already expressed in the direct outer context or what it is attached to  
(case of records or subprogram parameters) ?


Another alternative for people who do not like _Type and feels hurt with  
it, could be to serve each type declaration, with a name to be used for  
instances-without special identity.

    type Book is private; -- Typical instance name: Set_Of_Written_Sheets.
                          -- Sorry, I do not know a good English synonym.
                          -- Note: some API do something a bit similar, when
                          -- they define common abbreviations for variables
                          -- of a type.


[*] When I read sources which does not use the “_Type” convention (or  
something similar, there are multiple choice, and either on the variable  
or on the type), including some part of the ARM, there are tricky names  
(which are disturbing for the reader) or hard game to find synonyms, which  
makes me wonder what the next will be (funny game) or if the type was  
really given the good name. That is funny in literature to play with  
multiple synonymous of a word or close-meaning words; but although I enjoy  
the concept of Literate Programming, computer language source is not  
literature (the expression Literate Programming is only partly related to  
literature), it is not the same kind of entertainment. When a name does  
not sound natural and like to play the “guess what next” game with you,  
this is not good for readability (the reader has some other priorities).


P.S. For reader of this news-group: this only applies to languages which  
are case insensitive, as as-you know, there is a common convention in  
language with case sensitivity, to use a capital letter (like natural  
language when it needs to distinguish proper names) which plays the same  
role as _Type here.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 21:44:49 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Please, read all, up to the end (I am not totally contracting what I  
> reply to, that is all about covering all cases).
Read “contradicting” instead of “contracting”.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 21:38:19 +0100, Warren <ve3wwg@gmail.com> a écrit:
> In cases like these you are still left with the
> task of making them different-- merely for the purpose
> making them different.
Yes, that is exactly a perversion.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 13:14:56 +0100, Stephen Leake  
<stephen_leake@stephe-leake.org> a écrit:
> The third choice is:
>
> package RPG is
>
>    type Weapon is (Broadsword, Catapult, Torpedo);
>    procedure Attack (Weapon : RPG.Weapon);
>
> end RPG;
Which is the choice giving it a name-space ;) Exactly what we do not have.

But what is a name space it this is not a way separate names ? Foo in one  
name-space is not necessarily the same as Foo in another name-space. And  
what do C authors with C which does really have name-space ? They use  
prefixes and suffixes. Name space is precisely a way to manage it : the  
prefix may vary, may be omitted (from within the name-space or after  
renaming).

> That was not introduced until after the two camps were firmly
> established. I actually think this third choice is more in the spirit of
> Ada than either of the other two.
I agree, but think of the two other camps : the one Use and the one of  
no-Use. (lol, let's go to the funfair now)

> Consistent conventions are _far_ more important than any reasons
> supporting _type vs no _type.
Yes! And Yes again! That is precisely consistency. And you you have to use  
tricky names, there is no more consistency.

I like a lot your third way, but this is not a peace of cake of cake if  
the package name is long. Luckily, a package can rename itself (I know no  
objection for that in the RM and the compiler accept it).

So, the version could be :


    with Ada.Text_IO;

    -- Game: guess what is wrong with that program.

    procedure Test is

       package Any_Package is
          type Foo is private;
          procedure Play_The_Foo_With_Me
            (Foo : Any_Package.Foo);
       private
          Type Foo is new Integer;
       end Any_Package;

       package body Any_Package is

          package Output renames Ada.Text_IO;
          package Integer_Output is new
             Output.Integer_IO (Any_Package.Foo);

          procedure Play_The_Foo_With_Me
            (Foo : Any_Package.Foo)
          is
          begin
             Output.Put ("I've played the FooL ");
             Integer_Output.Put
               (Item  => Foo,
                Width => 0, -- Minimize width
                Base  => 10);
             Output.Put_Line (" times on you.");
          end;
       end Any_Package;

       Foo : Any_Package.Foo;

    begin
       Any_Package.Play_The_Foo_With_Me (Foo);
    end Test;


Now, using a renaming of Any_Package inside of itself :


    with Ada.Text_IO;

    -- Game: guess what is wrong with that program.

    procedure Test is

       package Any_Package is

          package Types renames Any_Package;

          type Foo is private;
          procedure Play_The_Foo_With_Me
            (Foo : Types.Foo);
       private
          Type Foo is new Integer;
       end Any_Package;

       package body Any_Package is

          package Output renames Ada.Text_IO;
          package Integer_Output is new
             Output.Integer_IO (Types.Foo);

          procedure Play_The_Foo_With_Me
            (Foo : Types.Foo)
          is
          begin
             Output.Put ("I've played the FooL ");
             Integer_Output.Put
               (Item  => Foo,
                Width => 0, -- Minimize width
                Base  => 10);
             Output.Put_Line (" times on you.");
          end;
       end Any_Package;

       Foo : Any_Package.Types.Foo;
       -- Or simply “Foo: Any_Package.Types.Foo;”

    begin
       Any_Package.Play_The_Foo_With_Me (Foo);
    end Test;


If the convention of using “package Types renames Any_Package;” is  
consistent enough, this may indeed be an option.

Lot of thanks for your Idea Stephen (will have it mind in the future).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Simon Wright]

"Vinzent Hoefler" <nntp-2010-10@t-domaingrabbing.de> writes:

> On Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:
>
>> Please don't mistake this suggestion to be in favor
>> of separate namespaces for types and other things.
>
> Not that this would be a problem:
>
>    Weapon_Procedures.Attack (Weapon : Weapon_Types.Weapon);

But why would you want to attack a weapon?

Well, to be fair, that's what point-defence anti-missile systems do, I
suppose; I definitely had the 'Using' use case in mind, though!

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 22:16:07 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Now, using a renaming of Any_Package inside of itself :
>
>
>     with Ada.Text_IO;
>
>     -- Game: guess what is wrong with that program.
>
>     procedure Test is
>
>        package Any_Package is
>
>           package Types renames Any_Package;
>
>           type Foo is private;
>           procedure Play_The_Foo_With_Me
>             (Foo : Types.Foo);
>        private
>           Type Foo is new Integer;
>        end Any_Package;

But there is still a problem if the package wants to define a function  
named Foo

So here again, “_Type ” is a more applicable solution.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Sometime it is possible to get ride of _Type, but sometime it is not
> always, and this is not predictable, and your design should cover the
> “always” otherwise it will hold a bug. If you decide it for the user,
> this is not good : premature decision. You cannot assert the user will
> never define very generic instance of that type (and there are common,
> see later [*]).

I'm sorry, but I will _not_ write what I consider badly-crafted code
simply so that someone who I don't know might find it easy to create an
even nastier mess.

I had a tongue-in-cheek rule of thumb about local variables: the name
should be no longer than log2(scope in lines). So I would have no
problem writing

   declare
      B : Buffer;
   begin
      --  one or two lines of code
   end;

Of course even I would probably draw the line at calling the read buffer
R and the write buffer W! entirely depends on the context.

Re: _Type vs no _Type

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> package RPG is
>
>    type Weapon is (Broadsword, Catapult, Torpedo);
>    procedure Attack (Weapon : RPG.Weapon);
>
> end RPG;

Neat. Certainly worth bearing in mind.

Re: Beginners question: Compound types, how-to?

[Vinzent Hoefler]

On Wed, 03 Nov 2010 22:19:03 +0100, Simon Wright <simon@pushface.org> wrote:

> "Vinzent Hoefler" <nntp-2010-10@t-domaingrabbing.de> writes:
>
>> On Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:
>>
>>> Please don't mistake this suggestion to be in favor
>>> of separate namespaces for types and other things.
>>
>> Not that this would be a problem:
>>
>>    Weapon_Procedures.Attack (Weapon : Weapon_Types.Weapon);
>
> But why would you want to attack a weapon?
>
> Well, to be fair, that's what point-defence anti-missile systems do, I
> suppose; I definitely had the 'Using' use case in mind, though!

See, if you think hard enough, the name problem is solved:

Attack_With (Weapon : Offensive_Weapon);
Defend_With (Weapon : Defensive_Weapon);

Or maybe the other way around:

Attack_With (Offensive_Weapon : Weapon);
Defend_With (Defensive_Weapon : Weapon);


Vinzent.

-- 
There is no signature.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/3/10 9:38 PM, Warren wrote:
> Georg Bauhaus expounded in
> news:4cd19583$0$6977$9b4e6d93@newsspool4.arcor-online.net:
>
>> On 03.11.10 17:56, Warren wrote:
>>
>>> There is a good practical case for _Type, IMO. If Buffer_Type is
>>> defined simply as Buffer, then we develop an inconvenient name clash:
>>>
>>>>      subtype Buffer is
>>>>         System.Storage_Elements.Storage_Array (1..Buffer_Size);
>>>
>>> In use now:
>>>
>>> declare
>>>     Buffer : Buffer;   -- hmmmm
>>> begin
>>
>> What role does the object named Buffer play?
>>
>> It is a buffer, yes. Is it different from other buffers?
>> How?  What lives in it?  How does the program use it?
>>
>> I believe answering these questions leads to a better name.
>
> Ok, so the type is a Storage_Buffer. So is the instance
> of the type.

Actually, the type is not a Storage_Buffer.  The type has no
"is a" relation to Storage_Buffer, the type defines what
instances of Storage_Buffers are going to be like. Each object
"is a"  Storage_Buffer. A type is not.   OK, that's nitpicking.

A child born is of type Child.  A son is of type Son.  Sometimes
fathers address the Child: "Son, ...!"  But the son still
has a name.  If you have another son, maybe younger, you
know how to tell them apart.  And if there are two or more
around, "Son, ...!" may not work as intended.So they've got
names, to resolve the issue.  Suppose there
is just one.  Should computer programming therefore dismiss
assigning single sons a name and just name them "Son"?

In natural language, "Son, ..." may be a special form
of address.  Something out of the ordinary.  This meaning
is not covered by the *type* Son.  Maybe our overloading
of meanings of Son lets us think we might use the same naming
scheme in formal programming, if *we* know there is one
particular Son object around and we write the statements
addressing it.  Doesn't seem like a good idea to me to carry
this over to formal programming.

The Romans just counted sons, Primus, ..., Quintus, say.
Every son "is a" Son, but none of them were without identity
and none was *named* son!   Just *called*, at times, and
in special situations where ambiguity is resolved by human
means, not by a compiler.

Therefore, then, do we do ourselves a favor if we use  this
style of anonymity by duplicating the type name for objects?
For example, "Tu quoque, fili?" can be clarified in programming
by just injecting the name Brute, for an object of type Son.
As in

package body Caesar

  procedure Last_Words is
  begin
     Say ("To quoque, Brute, fili mi?")
  end Last_Words;

end Caesar;

I guess that for insiders, the phrase might not be catchy enough.
Too long. But for a more formal analysis, the specific object is nicely
spelled out (Brute), and the relation is clear, too (mi): Brutus,
that's the son's name, is Caesar's son (fili mi), not just someone's
son (fili) as a computer could infer, absent a possessive pronoun.

Suppose the string had just been "To quoque, fili", without Brute and
without mi.  The program's author sure had known better.

He had known the name but decided not to give it.
Why not?


> Storage_Buffer : Storage_Buffer;
>
> doesn't get us any closer to solving the problem. ;-)
>
> Sometimes the number of instances is one -- matching the
> type.  In cases like these you are still left with the
> task of making them different-- merely for the purpose
> making them different.

I still think that not having a object name based on the object's
role, say,  shows that you have not yet clearly named the purpose
of this object in the program.   Sometimes that's enough.
I think, however, that quick and dirty anonymity characterizes
programs that need but a limited amount of engineering.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/3/10 9:44 PM, Yannick Duchêne (Hibou57) wrote:

> About the more : think about an inventory machine in a library, it has a method named Run_Inventory, and inside this, a loop and a book variable. This book has nothing special at all, as it is by definition, to hold any what book you may imagine. This variable, here, is, simply what the Book type, is. So your question is indeed very good : what is different ? The answer : one is a type, the other is an instance So how do you name it ? With a name which expose the difference
> Either Book_Instance and Book or
> else Book and Book_Type or even, if you like it Book_Instance and Book_Type. Book_Instance is the place for different name : A_Book, Any_Book, Current_Book, etc. What ever, you will add to the instance name, something which you reject for the type name (paradox ?).

I'm picking up an argument about "just any book" found somewhere
in the three very long lines above  ;-)

You have just started to answer my question about finding
object names: What is the role of the just-any-book variable
in the loop in Run_Inventory?  What does the loop do to the
just-any-book object?  If there is some information, fine,
the name is very much at hand.  Otherwise, I'd do the same
as Simon Wright and just use the letter B.  As long as there
aren't too many symbols around.  But I'd *not* use Book and
have readers sort out name spaces!

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 13:18:46 +0100, Stephen Leake <stephen_leake@stephe-leake.org> a écrit:
> The reason we need different names for the parameter and the type is
> because they are not in separate name spaces in Ada. So it is true that
> "the language is not sufficiently well equipped for this kind of help".
> That's something else the "no _Type" side does not want to admit.
>
> [...]
>
> We don't get to change the grammar of Ada.
>
(Sorry George, still could not configure Opera, asked for support in the Opera's forum, something seems broken with it)

May be a silly idea would be to introduce it as an option, but not a compiler option, obviously, rather something as a context clause, where we put the Withed packages. May be (I said, that's a silly idea, remember) a “with Ada.Type_Name_Space;” ? … which would direct the compiler to put type names its their own name-space.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 13:06:10 +0100, Stephen Leake <stephen_leake@stephe-leake.org> a écrit:
> Those who don't understand the purely syntactic role of the _Type suffix
> are clearly not S/W engineers.
>
> I didn't say "don't choose good names". I said "don't waste time
> choosing names when _Type will do perfectly".
Thanks to have clearly expressed things in few words.

You're a good Sentence Engineer

(just hope this will not end in the ears of a deaf)

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 23:44:00 +0100, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit:
> I'm picking up an argument about "just any book" found somewhere
> in the three very long lines above  ;-)
Apologize to you Georg, As said a prior message, I
still could not fix it, as Opera seems to not handle
the option as expected. Hope to fix it later, for
the time, it is manual formating (with your quote
as a ruler).

> You have just started to answer my question about finding
> object names: What is the role of the just-any-book variable
> in the loop in Run_Inventory?  What does the loop do to the
> just-any-book object?  If there is some information, fine,
> the name is very much at hand.  Otherwise, I'd do the same
> as Simon Wright and just use the letter B.  As long as there
> aren't too many symbols around.  But I'd *not* use Book and
> have readers sort out name spaces!
This, is not formal argument, this is a matter of taste,
just as is the difference between writing A_Book or Book_Type
(I agree both, even if for practical reasons, I prefer the
second one). Here, the matter of taste is that I really
hate this kind of one letter Identifiers. Even if the scope
is close, I will write Book, in plain word, because I want
it (personal taste) and feel it is a way to return respect to
the reader. The only place I use one letter identifiers, if
where they may stand for common mathematical variables, like
“I”, “J”, “K” (while I avoid it too if ever I'm afraid this
drop some important properties of the variables, at least,
if it lack to express their properties if ever these ones are
not obvious).

Re: Beginners question: Compound types, how-to?

[Shark8]

Somewhere on this thread, a while back, someone brought up the
question about why the Standard numeric types (Integer, Float, etc)
don't have a "_Type" suffix as an argument against such a suffix.

After some thought it dawned on me that because the name like integer
& natural are the names of the [mathematical, nor programming] type of
numbers they are. That is to say that the _Type is implicit in the
name itself.

We have this abstract class of type "number," which is precisely what
some quantity is... derived from this are the abstract types "Real"
and "Integer" [this "Integer" is Universal_Integer of the ARM]. I'll
stick with the Universal_Integer right now for simplicity's sake, but
there are further abstract types/sets within "Integer," things like
"Natural" {the counting numbers 1...}, "Whole" (0 U counting numbers),
and "Negative" (0 less some x where x is a counting number).

In the design of Ada they chose to map "whole" numbers to the name
Natural, and from there they defined the name Positive to map to the
counting numbers. This allows us to use sets to work with all the
integers representable on a computer (negative being "Range
Integer'First to Intger'Pred(Natural'First)" or perhaps "ix X Not In
Natural'Range then" ).

Real numbers are a bit more tricky. Because we're using a digital
machine we cannot represent real numbers [as such] but have to make do
with intervals {the 'accuracy' of the computer} in addition to the
finite representation range imposed on integers. {This is actually the
same problem as integers, but once-recursive: there is no way to
represent the infinite set of integers, but reals have the added
infinite range between two integers.}

It is a bit of tradition in CS that the floating-point method of
representing reals be called "float," probably precisely to remind
programmers that they were NOT dealing with the exactly mathematically-
representable type "Real" but an approximation thereof. Ada also
offers the "fixed point" method of representing real numbers, which
requires far less consideration about the implementational-differences/
shortcomings of "float" [of the 'Specification" of mathematical Real
numbers]. Take something like money; here in the US we use the Dollar
and subdivide it into 100 cents and no further [not entirely true,
once we had half-pennies]. So to represent the concept "money" we can
have a fixed-point type with the increment/accuracy set to 1/100th.
(Conceptually there isn't much difference from that method and simply
counting money-quantities in cents grouping out "dollars" and "cents"
with the mod and '/' operations.)

There is a third way of representing reals [or rather a subset} which
would be the rational method:
Type Rational is record
Numerator, Denominator : Integer;
end record;

But this method, the user-defined one is different from the others in
that the designers of Ada did not provide it as a part of Standard.

Re: Beginners question: Compound types, how-to?

[Stephen Leake]

"Vinzent Hoefler" <nntp-2010-10@t-domaingrabbing.de> writes:

> On Wed, 03 Nov 2010 18:01:55 +0100, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
>
>> On 03.11.10 17:56, Warren wrote:
>>
>>> There is a good practical case for _Type, IMO. If Buffer_Type is defined
>>> simply as Buffer, then we develop an inconvenient name clash:
>>>
>>>>     subtype Buffer is
>>>>        System.Storage_Elements.Storage_Array (1..Buffer_Size);
>>>
>>> In use now:
>>>
>>> declare
>>>    Buffer : Buffer;   -- hmmmm
>>> begin
>>
>> What role does the object named Buffer play?
>>
>> It is a buffer, yes. Is it different from other buffers?
>
> I now own it, thus it's "My_Buffer", of course. ;)
>
>> How?  What lives in it?  How does the program use it?
>>
>> I believe answering these questions leads to a better name.
>
> Yes, things like "Message_Buffer" are usually better here. Even a
> generic name like "Read_Buffer" could help somewhat.

Notice that the "find a better name" camp always suggests _several_
names, and each person suggests _different_ ones. That means there is no
common solution, and the resulting code will be confusing, and subject
to endless arguments about "the right name" in code reviews.

At least with _Type, the solution is very clear.

So it takes less time to write good code using the _Type convention :).

(Ok, it's late, and I'm tired, and this is more fun than real work :)

-- 
-- Stephe

Re: Beginners question: Compound types, how-to?

[Stephen Leake]

"Vinzent Hoefler" <nntp-2010-10@t-domaingrabbing.de> writes:

> On Wed, 03 Nov 2010 22:19:03 +0100, Simon Wright <simon@pushface.org> wrote:
>
>> "Vinzent Hoefler" <nntp-2010-10@t-domaingrabbing.de> writes:
>>
>>> On Wed, 03 Nov 2010 01:46:37 +0100, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:
>>>
>>>> Please don't mistake this suggestion to be in favor
>>>> of separate namespaces for types and other things.
>>>
>>> Not that this would be a problem:
>>>
>>>    Weapon_Procedures.Attack (Weapon : Weapon_Types.Weapon);
>>
>> But why would you want to attack a weapon?
>>
>> Well, to be fair, that's what point-defence anti-missile systems do, I
>> suppose; I definitely had the 'Using' use case in mind, though!
>
> See, if you think hard enough, the name problem is solved:
>
> Attack_With (Weapon : Offensive_Weapon);
> Defend_With (Weapon : Defensive_Weapon);
>
> Or maybe the other way around:
>
> Attack_With (Offensive_Weapon : Weapon);
> Defend_With (Defensive_Weapon : Weapon);

Once again, two solutions. How am I supposed to choose between them?

-- 
-- Stephe

Re: _Type vs no _Type

[Nasser M. Abbasi]

On 11/3/2010 2:29 PM, Simon Wright wrote:
> Stephen Leake<stephen_leake@stephe-leake.org>  writes:
>
>> package RPG is
>>
>>     type Weapon is (Broadsword, Catapult, Torpedo);
>>     procedure Attack (Weapon : RPG.Weapon);
>>
>> end RPG;
>
> Neat. Certainly worth bearing in mind.

Sorry to jump in, I have not read everything in this thread, so may be 
this was mentioned already.

Isn't this whole subject a result of Ada being case insensitive?

If Ada has been case sensitive, then one would write

weapon : Weapon;

and be done with it?

That is one part of Ada I never liked, same for Fortran or any other 
language which is not case sensitive.

But nothing can be done about it, I know.

--Nasser

Re: _Type vs no _Type

[Stephen Leake]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Wed, 03 Nov 2010 13:14:56 +0100, Stephen Leake
> <stephen_leake@stephe-leake.org> a écrit:
>> The third choice is:
>>
>> package RPG is
>>
>>    type Weapon is (Broadsword, Catapult, Torpedo);
>>    procedure Attack (Weapon : RPG.Weapon);
>>
>> end RPG;
> Which is the choice giving it a name-space ;) Exactly what we do not have.

Say what? This is legal Ada code.

> Lot of thanks for your Idea Stephen (will have it mind in the future).

It's not actually mine, but I forget who proposed it first.

-- 
-- Stephe

Re: _Type vs no _Type

[Stephen Leake]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Wed, 03 Nov 2010 22:16:07 +0100, Yannick Duchêne (Hibou57)
> <yannick_duchene@yahoo.fr> a écrit:
>> Now, using a renaming of Any_Package inside of itself :
>>
>>
>>     with Ada.Text_IO;
>>
>>     -- Game: guess what is wrong with that program.
>>
>>     procedure Test is
>>
>>        package Any_Package is
>>
>>           package Types renames Any_Package;
>>
>>           type Foo is private;
>>           procedure Play_The_Foo_With_Me
>>             (Foo : Types.Foo);
>>        private
>>           Type Foo is new Integer;
>>        end Any_Package;
>
> But there is still a problem if the package wants to define a function
> named Foo

Yes; the type name collides with the subprogram name.

But that just doesn't seem to be a problem in practice. Picking good
names does seem to be the better solution to this part of the problem;
good type names and good subprogram names tend to be different, while
good type names and good subprogram parameter names tend to be the same.

-- 
-- Stephe

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Thu, 04 Nov 2010 06:28:28 +0100, Nasser M. Abbasi <nma@12000.org> a  
écrit:
> Sorry to jump in, I have not read everything in this thread, so may be
> this was mentioned already.
>
> Isn't this whole subject a result of Ada being case insensitive?

If you see C/C++ as a reference. It is more a result of Ada being without  
a separate name-space for types, like Eiffel do. This was previously  
explained.

> If Ada has been case sensitive, then one would write
>
> weapon : Weapon;
>
> and be done with it?
>
> That is one part of Ada I never liked, same for Fortran or any other
> language which is not case sensitive.
That is counter intuitive and dangerous. Counter intuitive because “URL”  
would become a type. This is dangerous, because when you may easily type  
“Id” instead of “id”, which may lead into a program, which could be  
checked as correct, but with a very different behavior (you could even  
imagine this as an error introduced on purpose to pirate an application  
 from the inside). And then, if one start to play with letter casing to  
distinguish between entities, then there is really a trouble.

Could you recommend the following as a good practice ?

    URL : Location_Type;
    url : Identifier_Type; -- Illegal after the latter, luckily

OK, every one can guess what “URL” means. But who can guess what means the  
difference in casing ? (only the author can… while not sure, he/she may  
forget some time later).

I know you probably did not have this kind of tricky usage in mind. But if  
you allow it, be sure this will be used this way sooner or later. This is  
just to say using casing to distinguish type and instance is even worse,  
because the languages which do that, are case sensitive every where, and  
to have “URL” and “url” in the same scope, is legal C/C++. So, let Ada be  
case insensitive and use _Type, this is not the worst.

> But nothing can be done about it, I know.
Will never, for the reason given above (I think there is a rational text  
for that, will look for it someday).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Wed, 03 Nov 2010 22:31:53 +0100, Vinzent Hoefler  
<nntp-2010-10@t-domaingrabbing.de> a écrit:
> See, if you think hard enough, the name problem is solved:
>
> Attack_With (Weapon : Offensive_Weapon);
> Defend_With (Weapon : Defensive_Weapon);
>
> Or maybe the other way around:
>
> Attack_With (Offensive_Weapon : Weapon);
> Defend_With (Defensive_Weapon : Weapon);

I don't believe these two are the same : there are two different types in  
the first, while one single type in the second. The design is not the same  
(an example of how avoiding _Type can direct people to change what the  
things really are… that's bad).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Thu, 04 Nov 2010 06:18:42 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:

> Somewhere on this thread, a while back, someone brought up the
> question about why the Standard numeric types (Integer, Float, etc)
> don't have a "_Type" suffix as an argument against such a suffix.
May be this was me in a previous thread (not this one), I remember I  
opened a thread about this question last year.

> After some thought it dawned on me that because the name like integer
> & natural are the names of the [mathematical, nor programming]
I do not know the reason, but it appears this is less a trouble with  
Integer and the like, as it is unlikely some one will think of it as an  
entity name.

This is more likely to occur with a type like String, but Line and Text  
may be good alternative entity names for that case.

The more a type is complex, the more it will hold a semantic, and the more  
its name is going to be the same as a names of choice for entities.

Integer means really nothing : not a measure, not a count, not a quantity,  
not anything. Then after, if you define a derived type, like Weight_Type,  
Cardinal_Type, etc, these Weight and Cardinal really means something, so  
their variables have a strong potential to be of the same name. No chance  
this will occur with a name like Integer. Integer is too much simple and  
basic to hold any semantic (it has specifications, not semantic).

There is also the special case of Character the OP introduced  
(synonymous). This one is another story.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: _Type vs no _Type

[Shark8]

On Nov 3, 11:28 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 11/3/2010 2:29 PM, Simon Wright wrote:
>
> > Stephen Leake<stephen_le...@stephe-leake.org>  writes:
>
> >> package RPG is
>
> >>     type Weapon is (Broadsword, Catapult, Torpedo);
> >>     procedure Attack (Weapon : RPG.Weapon);
>
> >> end RPG;
>
> > Neat. Certainly worth bearing in mind.
>
> Sorry to jump in, I have not read everything in this thread, so may be
> this was mentioned already.
>
> Isn't this whole subject a result of Ada being case insensitive?
>
> If Ada has been case sensitive, then one would write
>
> weapon : Weapon;
>
> and be done with it?
>
> That is one part of Ada I never liked, same for Fortran or any other
> language which is not case sensitive.
>
> But nothing can be done about it, I know.
>
> --Nasser

Despite that this SINGULAR case where case-sensitivity would solve the
problem it COMPLETELY overlooks the many cases where case-sensitivity
[and using it to conceptually-overload an identifier] introduces Bad
Things.

Consider this code:

Type THIS is private;
Procedure this( This: out THIS; THis : in THIS; THIs : in out THIS );

Upon *hearing* your boss say "There is a problem in the program with
this; fix it." what "this" is he talking about?
{ Yes, I realize that no *sane* programmer would produce something
like this, but isn't the continued popularity of C/C++ proof that
there is a large chunk of programmers who are not sane? ;) }

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/4/10 6:23 AM, Stephen Leake wrote:

Why is it that the "_type"  camp is so consistently silent
about giving specific contexts of what are just programming
examples?

> Notice that the "find a better name" camp always suggests _several_
> names, and each person suggests _different_ ones. That means there is no
> common solution, and the resulting code will be confusing, and subject
> to endless arguments about "the right name" in code reviews.

The "find a better name" camp only suggests several names in order
to offer ideas, as best as they can not knowing the context
like the programmers do---or are supposed to do.

The programmers or team can pick the one name that matches best.
Only they have enough domain knowledge to choose properly.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/4/10 6:23 AM, Stephen Leake wrote:

> Notice that the "find a better name" camp always suggests _several_
> names, and each person suggests _different_ ones. That means there is no
> common solution, and the resulting code will be confusing, and subject
> to endless arguments about "the right name" in code reviews.
>
> At least with _Type, the solution is very clear.

The choice of _Type just dissolves the issue. :-)

Well, OK, sometimes a naming issue can be deferred to
a later day, and/or to another person, in order to get
on with the work at hand.

But part of daily programming work is studying foreign code,
written in a number of languages.  (Suppose you are writing
.NET programs and the examples are in F#, you write C++;
or you need to transform some Ada tasks into a Fortran
program using the MPI; or you are about to enhance an
algorithm presented in Python.)

Say you see program text with _Type.

_Type is very much like the "abc: Abc" approach mentioned in this
thread, that is used with case sensitive languages:
it uses the same word twice.
I'm saying the same word because both letter case and _Type do not
change the meaning of words.  "Weapon" means the same as "weapon"
or "Weapon_Type", as far as the meaning of the things in the
type's value set is concerned.

"X_type" is only supposed to indicate a different *use* of the
same word X. By using it, X still has its meaning unchanged.

I once liked the case idea, too, but after having to switch languages
every now and then, I wholly understand the complaints posted against
tword: Tword.  For a start, this convention forces one to become highly
sensitive to the presence of case sensitivity in either language.
The effect on the program's reader is a doubled effort.

Worse, if you see FooType in Python, C++, whatever, the _Type
suffix habit becomes a source of confusion.  It is very likely
possible that the authors have written "Type" to convey meaning,
and not to have it indicate "'Foo' used as a type name".
The effect is a higher risk of a misunderstanding.

If every identifier is chosen for its meaning instead of for its
function, then these two problems do not arise.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/4/10 2:19 AM, Yannick Duchêne (Hibou57) wrote:
>  I
> still could not fix it, as Opera seems to not handle
> the option as expected. Hope to fix it later, for
> the time, it is manual formating (with your quote
> as a ruler).

Thank you!

>> You have just started to answer my question about finding
>> object names: What is the role of the just-any-book variable
>> in the loop in Run_Inventory? What does the loop do to the
>> just-any-book object? If there is some information, fine,
>> the name is very much at hand.

What about these?  Is there no information about just-any-book?

>> Otherwise, I'd do the same
>> as Simon Wright and just use the letter B. As long as there
>> aren't too many symbols around. But I'd *not* use Book and
>> have readers sort out name spaces!
> This, is not formal argument, this is a matter of taste,
> just as is the difference between writing A_Book or Book_Type

OK, taste.
But here is a formal argument:

A_Book and Book_Type have Book in them, with _Type
adding no meaning, only usage information, A_ adding
the specific that some book was meant (though I might
be misreading A_Book, IIRC Bill Findlay's convention.)
Book conveys neither by itself.

Another argument about formal things.  Ada's type declarations
make me think that _Type was never intended:

    type Foo_Type is range 1 .. 10;
    ^^^^     ^^^^

And here is another formal argument:

I'd prefer A_Book, too, if I have to, because the book
object "is a" book.  If you declare

   Book: Book_Type;

then you'd have to say that Book "is a" Book_Type.
That's from the Department of Redundancy Department,
at best;  formally, it seems just wrong.

Re: Beginners question: Compound types, how-to?

[Yannick Duchêne (Hibou57)]

Le Thu, 04 Nov 2010 11:29:02 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:

> On 11/4/10 2:19 AM, Yannick Duchêne (Hibou57) wrote:
>>  I
>> still could not fix it, as Opera seems to not handle
>> the option as expected. Hope to fix it later, for
>> the time, it is manual formating (with your quote
>> as a ruler).
>
> Thank you!

I'm afraid this cannot be solved, will have to ask others if this is
same for others.



> Another argument about formal things.  Ada's type declarations
> make me think that _Type was never intended:
>
>     type Foo_Type is range 1 .. 10;
>     ^^^^     ^^^^
This is not about type declaration/definition, this is about  
usage/reference.

Somewhere else in this thread, you talked about “Meaning, not function” :  
function is part of the meaning hold. A word, a symbol, is a Signifier,  
the Signifier tell us about a Signified, and the function is part of that  
Signified.

Know it is redundant, but the reason of this redundancy has been explained  
(dedicated name-space).

A question : will you bother about giving the same name to a type (or a  
prototype in human thoughts) as an to an instance, if the question was not  
raised by this lack of name-space ?

If this was not Ada, Eiffel instead, will you bother ? Would you have  
noticed this “problem” ?

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 04.11.10 12:06, Yannick Duchêne (Hibou57) wrote:

>> Another argument about formal things.  Ada's type declarations
>> make me think that _Type was never intended:
>>
>>     type Foo_Type is range 1 .. 10;
>>     ^^^^     ^^^^
> This is not about type declaration/definition, this is about usage/reference.
> 
> Somewhere else in this thread, you talked about “Meaning, not function” :
> function is part of the meaning hold. A word, a symbol, is a Signifier, the
> Signifier tell us about a Signified, and the function is part of that Signified.

I think that a Signified's function is not normally part of the
definition of a Signified thing that is to become a type. Example:

We never know *how* a Knife is going to be used when defining
the type Knife. I.e., What its function is going to be.  That's
abstraction.  The objects using the knife have a role in this.

We do provide *operations* such as Cut.  But what the cuts will
do is beyond the reach of the definition in the following sense:

The knife can serve as a weapon in cutting someone's throat
It can serve as a tool for cutting fish. But this is *not*
part of the definition of the type Knife.  Function
is part of the way the program's uses objects of type Knife,
"cooperating" with objects of other types, such as "Vegetable".

Knife_Type instead of just Knife does not change the definition,
so Knife_Type does not predict the function either.

The grammar should tell whether a word names a type or an object.
Ada's does. If it didn't, Ada was ambiguous.

One possible exception where _Type make a lot of sense is
actual generic units that have formal type parameter.
In this case a _Type suffix is meaningful:
The formal parameter signifies no type yet.
But is says that the actual type needs to have certain
characteristics. That is, the actual type "is a" type.

generic
  type Float_Type is digits <>;
function ...

Float_Type signals that Float_Type is not a type in the unit.
But is stands for a real type in instances.


> Know it is redundant, but the reason of this redundancy has been explained
> (dedicated name-space).

Counterarguments and alternative ways have been presented:
Redundancy is not an excuse for lack of proper names, IHMO.


> If this was not Ada, Eiffel instead, will you bother ? Would you have noticed
> this “problem” ?

I have noticed this problem in Eiffel, as have others.

In fact, separate name spaces in Eiffel are not everyone's
favorite feature. One convention that some use is to write

  string_ : STRING

That's a little underscore in addition to the legal declaration

  string : STRING

or even

  STRING : STRING

A terrible choice in the presence of real-world programming where
a programmer's work requires at least reading more than one language
(Also, imagine rewriting the above declaration in another language;
this can be solved, but again, needs mechanical, arbitrary,
non-grammatical conventions.).

I remember having difficulty compiling classes defined
using either convention with one Eiffel dialect compiler.

In Ada, the problem is aggravated by attributes, and separate
name spaces won't solve it. They can be applied to both types
and objects.

So when a reader sees

 T'Something

she will not be getting additional cues from separate
name spaces.  In fact, separate namespaces have no visible
counterpart in source text.  On the contrary, they add
a possibility of mistaking a name in namespace-for-types
for one in namespace-for-objects when they are homographs
usable in the same inner region.

Re: Beginners question: Compound types, how-to?

[Peter C. Chapin]

On Nov 2, 3:02 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:

> > _Type vs "waste time thinking up other names" is a religious argument
> > (guess which side I'm on?); it has never been settled before, and won't
> > be settled this time.
>
> Those who think the essential S/W-engineering activity of choosing good names is
> a waste of time are clearly not S/W engineers.

I guess I will jump into this discussion with my thoughts on the _Type
suffix. In my view it is not noise. It is useful. It conveys the
information that the name in question is the name of a type. That
information is valuable.

The problem is that many words in ordinary English can be used as type
names identifying an entire class of objects, or as an individual
object. For example the word "Weapon" that was used in some other
posts. In some contexts "Weapon" refers to a type... the class of all
weapons. On other contexts "Weapon" refers to a specific weapon at
hand. In normal English the context is set up by the surrounding text
and by the semantics of the sentence in which the words appear. That
works. That can even work in a programming language where a name is
"obviously" the name of a type when it is used in certain ways.

However, when it comes to programming... even software engineering...
I tend to prefer redundancy and explicitness. I like Ada (over some
other languages) precisely because it is redundant and explicit. Thus
I like the name of a type to clearly indicate that it is a type name.
Using the _Type suffix does that nicely.

That said, I don't use _Type universally. There are some names where
it just does not seem necessary. Integer is a good example. It's a
judgement call about which names are good without _Type and which are
not. However, I most definitely do not think _Type is "just noise."

Peter

Re: Beginners question: Compound types, how-to?

[Warren]

Georg Bauhaus expounded in news:4cd1e2ec$0$6978$9b4e6d93
@newsspool4.arcor-online.net:

..
>> Storage_Buffer : Storage_Buffer;
>>
>> doesn't get us any closer to solving the problem. ;-)
>>
>> Sometimes the number of instances is one -- matching the
>> type.  In cases like these you are still left with the
>> task of making them different-- merely for the purpose
>> making them different.
> 
> I still think that not having a object name based on the object's
> role, say,  shows that you have not yet clearly named the purpose
> of this object in the program.   Sometimes that's enough.
> I think, however, that quick and dirty anonymity characterizes
> programs that need but a limited amount of engineering.

Here is a real world example: I define a type Terminal to 
manage state for a curses mode terminal. It is _unlikely_
that I'll ever manage more than one terminal in this Basic
interpreter, even though the curses API leaves that 
possibility open.

A terminal doesn't have a name, like Henry (no offense to
Henrys).  Adding colour to the name like Blue_Terminal is
in appropriate.   

There is only ever going to be _ONE_ instance of that type.  
So what names do you give the type and the single instance?

Terminal : Terminal_Type;
-- or
The_Terminal : Terminal;

If you say the type should be more specific like Curses_Terminal, 
then you could argue that the instance named Terminal is not a 
good enough name for the instance. 

This brings us full circle, back to:

Curses_Terminal : Curses_Terminal;

So in the end, you sometimes make a distinction, SOLELY
for the sake of making them different. 

Instance vs Type.

IDEALLY, the language would be context sensitive enough
to allow you to use the same name in both contexts. Ada
obviously is not designed that way and I'm not suggesting
it be changed. It might even be a bad idea in the context
of "safety".

As others have said, this is simply a practical issue with 
various practical solutions.  Religious practices and 
chicken bone waving sometimes applies.

Warren

Re: Beginners question: Compound types, how-to?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

=?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in
news:op.vlmu06olule2fv@garhos: 

> Le Thu, 04 Nov 2010 06:18:42 +0100, Shark8 <onewingedshark@gmail.com>
> a  écrit:
> 
>> Somewhere on this thread, a while back, someone brought up the
>> question about why the Standard numeric types (Integer, Float, etc)
>> don't have a "_Type" suffix as an argument against such a suffix.

> May be this was me in a previous thread (not this one), I remember I  
> opened a thread about this question last year.
> 
>> After some thought it dawned on me that because the name like integer
>> & natural are the names of the [mathematical, nor programming]

> I do not know the reason, but it appears this is less a trouble with  
> Integer and the like, as it is unlikely some one will think of it as
> an  entity name.

The reason it "works" is that the "type" is applied to
many instances:

   I, J : Integer;
   Count : Natural;
   Index : Positive;

You would never even think of using any of the following:

   Integer, Integer2 : Integer;
   Natural : Natural;
   Positive : Positive;
begin
   Integer := 23; 
   etc...

Integer is just an inappropriate name for an Integer.

A "type" may describe one to many instances of it.  

The naming problem only tends to occur when you have one 
instance of a type.  Otherwise, as George has expounded, 
you can be more specific about the instance's name.

Warren

Re: Beginners question: Compound types, how-to?

[Warren]

Peter C. Chapin expounded in
news:e5450e4b-25f6-427e-a746-9af30dad99b0@b19g2000prj.googlegroups.com: 
..
> That said, I don't use _Type universally. There are some names where
> it just does not seem necessary. Integer is a good example. It's a
> judgement call about which names are good without _Type and which are
> not. However, I most definitely do not think _Type is "just noise."
> 
> Peter

I'm with you here. I don't like using _Type unless it is necessary. So if 
something is a Variable (in a Basic interpreter for example), then the 
type is Variable. The instance can then be a Short_Variable or 
Dim_Variable as appropriate (i.e. what kind of Variable).

But for other objects like Terminal, I go with Terminal_Type and allow
the single instance of it to be named Terminal.

It's simply a practical matter.

Warren

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/03/2010 05:06 AM, Stephen Leake wrote:
>
> I didn't say "don't choose good names". I said "don't waste time
> choosing names when _Type will do perfectly".

"Don't waste time on choosing names" means "don't choose names". If you don't 
choose names, you can't choose good names.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/03/2010 05:14 AM, Stephen Leake wrote:
>
> The core of the argument is about what metric to use for "better". Those
> on the _Type side say the first choice is "better", because it requires
> trivial thought both for writing and reading, and leads to different
> programmers making the same choice for names.

Here is the core of the _Type argument: It helps avoid thinking. Given a 
problem, a coder sits down and starts writing code; a S/W engineer thinks about 
the problem. Thinking is thus the defining characteristic of the S/W engineer, 
and attempting to avoid thinking the antithesis of S/W engineering.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/03/2010 02:31 PM, Vinzent Hoefler wrote:
>
> See, if you think hard enough, the name problem is solved:

Precisely. But avoiding thinking is the whole point of the _Type approach.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/03/2010 10:23 PM, Stephen Leake wrote:
>
> Notice that the "find a better name" camp always suggests _several_
> names, and each person suggests _different_ ones. That means there is no
> common solution, and the resulting code will be confusing, and subject
> to endless arguments about "the right name" in code reviews.

That's because the tiny examples don't provide enough information to know what 
the correct name should be.

> this is more fun than real work :)

Agreed.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/03/2010 10:25 PM, Stephen Leake wrote:
>
> Once again, two solutions. How am I supposed to choose between them?

By thinking :)

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/03/2010 05:14 AM, Stephen Leake wrote:
>
> package RPG is
>
>     type Weapon is (Broadsword, Catapult, Torpedo);
>     procedure Attack (Weapon : RPG.Weapon);
>
> end RPG;

Too many people find this confusing for me to use it, cool though it is.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: _Type vs no _Type

[Britt Snodgrass]

On Nov 4, 12:28 am, "Nasser M. Abbasi" <n...@12000.org> wrote:
>
> That is one part of Ada I never liked, same for Fortran or any other
> language which is not case sensitive.
>

The language design decision that Ada be case insensitive is something
that I value very much.  In general, I think the "flexibility"
provided by case sensitivity causes more problems (risks, bugs,
reduced readability) than it potentially solves. I don't like case
sensitivity in programming languages or in file system names.

- Britt

Re: _Type vs no _Type

[Nasser M. Abbasi]

On 11/4/2010 11:29 AM, Britt Snodgrass wrote:
> On Nov 4, 12:28 am, "Nasser M. Abbasi"<n...@12000.org>  wrote:
>>
>> That is one part of Ada I never liked, same for Fortran or any other
>> language which is not case sensitive.
>>
>

> The language design decision that Ada be case insensitive is something
> that I value very much.  In general, I think the "flexibility"
> provided by case sensitivity causes more problems (risks, bugs,
> reduced readability) than it potentially solves. I don't like case
> sensitivity in programming languages or in file system names.
>
> - Britt

I guess you would do not like Unix/Linux systems then (or even Apple, 
which uses Unix)?

I am the complete opposite, I like case sensitive languages, and like it 
also on file systems. I guess we will never be friends then :)

Sorry, but have a look at all the new languages and also at the list of 
most popular languages. They are almost all, if not all, case sensitive. 
There must be a good reason for this.

--Nasser

Re: Beginners question: Compound types, how-to?

[Vinzent Hoefler]

On Thu, 04 Nov 2010 07:11:36 +0100, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> wrote:

> Le Wed, 03 Nov 2010 22:31:53 +0100, Vinzent Hoefler
> <nntp-2010-10@t-domaingrabbing.de> a écrit:
>> See, if you think hard enough, the name problem is solved:
>>
>> Attack_With (Weapon : Offensive_Weapon);
>> Defend_With (Weapon : Defensive_Weapon);
>>
>> Or maybe the other way around:
>>
>> Attack_With (Offensive_Weapon : Weapon);
>> Defend_With (Defensive_Weapon : Weapon);
>
> I don't believe these two are the same : there are two different types in
> the first, while one single type in the second.

Yes, that was intentional.

> The design is not the same
> (an example of how avoiding _Type can direct people to change what the
> things really are… that's bad).

No, the design depends on how you see it. There is no such thing as a single,
perfect design, so possible solutions may differ.


Vinzent.

-- 
There is no signature.

Re: _Type vs no _Type

[Britt Snodgrass]

On Nov 4, 2:08 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> I guess you would do not like Unix/Linux systems then (or even Apple,
> which uses Unix)?

I don't like case sensitivity on Unix/Linux file systems, but at least
they got the separator slash direction right ("/", not "\").

>
> I am the complete opposite, I like case sensitive languages, and like it
> also on file systems. I guess we will never be friends then :)

In a better world, we would only have small issues like this to
debate :)

>
> Sorry, but have a look at all the new languages and also at the list of
> most popular languages. They are almost all, if not all, case sensitive.
> There must be a good reason for this.

I attribute most of that to "must be like C" inertia, rather than on
any well thought out reason. Same for the widespread use of curly
braces instead of more readable begin/end pairs.

- Britt

Re: _Type vs no _Type

[Simon Wright]

"Nasser M. Abbasi" <nma@12000.org> writes:

> I guess you would do not like Unix/Linux systems then (or even Apple,
> which uses Unix)?

The standard Mac OS X file system is case-insensitive.

Interstingly, unlike Windows, it's case-insensitive in a way which
defeats gnatmake! (well, this was a while ago, and I always use
lower-case filenames for Ada source anyway ..)

Re: Beginners question: Compound types, how-to?

[Martin]

On Nov 4, 1:59 pm, Warren <ve3...@gmail.com> wrote:
> Georg Bauhaus expounded in news:4cd1e2ec$0$6978$9b4e6d93
> @newsspool4.arcor-online.net:
>
[snip]
> There is only ever going to be _ONE_ instance of that type.  
> So what names do you give the type and the single instance?
>
> Terminal : Terminal_Type;
> -- or
> The_Terminal : Terminal;
[snip]

Personally, I prefer:

   Terminal : A_Terminal;

At least this preserves the English meaning of the indefinite
article. :-)

-- Martin

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Thu, 04 Nov 2010 20:59:11 +0100, Simon Wright <simon@pushface.org> a  
écrit:
> The standard Mac OS X file system is case-insensitive.
>
> Interstingly, unlike Windows, it's case-insensitive in a way which
> defeats gnatmake!

Feel free to tell more, please…


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: _Type vs no _Type

[Georg Bauhaus]

On 11/4/10 8:08 PM, Nasser M. Abbasi wrote:
> On 11/4/2010 11:29 AM, Britt Snodgrass wrote:
>
>> The language design decision that Ada be case insensitive is something
>> that I value very much. In general, I think the "flexibility"
>> provided by case sensitivity causes more problems (risks, bugs,
>> reduced readability) than it potentially solves. I don't like case
>> sensitivity in programming languages or in file system names.
>>
>> - Britt
>
> I guess you would do not like Unix/Linux systems then (or even Apple, which uses Unix)?

Apple is special :-)

$ ls -l x X
ls: X: No such file or directory
ls: x: No such file or directory
$ touch x
$ ls -l x X
-rw-r--r--  1 bauhaus  staff  0 Nov  5 04:08 X
-rw-r--r--  1 bauhaus  staff  0 Nov  5 04:08 x
$ echo y > x
$ ls -li x X
5055985 -rw-r--r--  1 bauhaus  staff  2 Nov  5 04:08 X
5055985 -rw-r--r--  1 bauhaus  staff  2 Nov  5 04:08 x

Re: _Type vs no _Type

[J-P. Rosen]

Le 04/11/2010 19:29, Britt Snodgrass a �crit :
> On Nov 4, 12:28 am, "Nasser M. Abbasi" <n...@12000.org> wrote:
>>
>> That is one part of Ada I never liked, same for Fortran or any other
>> language which is not case sensitive.
>>
> 
> The language design decision that Ada be case insensitive is something
> that I value very much.  
Here is my Euro 0.02 explanation of the difference:

The rule in C is simple: an identifier is a character string that
designates a memory location. Two different strings designate two
different locations.

The rule in Ada is: an identifier is a name that represents a certain
entity for the human programmer. Since the meaning of a name is
independent of casing (safe for exceptionnal cases), case is not
significant.

In short: C is oriented towards the computer, Ada is oriented towards
the programmer.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[J-P. Rosen]

Le 04/11/2010 20:08, Nasser M. Abbasi a �crit :
> Sorry, but have a look at all the new languages and also at the list of
> most popular languages. They are almost all, if not all, case sensitive.
> There must be a good reason for this.
> 

Everybody knows that syntax is the least important thing in a
programming language, however if a new language does not have C-like
syntax, people will dismiss it. That does not mean the syntax is good,
but just that the new generations have seen only one syntax in all of
their studies, and they believe that it is the only possible syntax. Sigh...

BTW: do you want to see my collection of things where the most succesful
design failed to be the most popular one?
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[Florian Weimer]

* Simon Wright:

> "Nasser M. Abbasi" <nma@12000.org> writes:
>
>> I guess you would do not like Unix/Linux systems then (or even Apple,
>> which uses Unix)?
>
> The standard Mac OS X file system is case-insensitive.

It applies some sort of Unicode normalization, which is just about as
bad as case normalization.

Re: _Type vs no _Type

[Florian Weimer]

* Britt Snodgrass:

> The language design decision that Ada be case insensitive is something
> that I value very much.  In general, I think the "flexibility"
> provided by case sensitivity causes more problems (risks, bugs,
> reduced readability) than it potentially solves.

And with case insensitivity, we have a seemingly neverending
collection of warts, bugs and incompatibilities in the Ada language.

Re: _Type vs no _Type

[J-P. Rosen]

Le 05/11/2010 08:05, Florian Weimer a �crit :
> And with case insensitivity, we have a seemingly neverending
> collection of warts, bugs and incompatibilities in the Ada language.

??? Could you be more precise, and especially for "incompatibilities" ?
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Fri, 05 Nov 2010 08:05:29 +0100, Florian Weimer <fw@deneb.enyo.de> a  
écrit:

> * Simon Wright:
>
>> "Nasser M. Abbasi" <nma@12000.org> writes:
>>
>>> I guess you would do not like Unix/Linux systems then (or even Apple,
>>> which uses Unix)?
>>
>> The standard Mac OS X file system is case-insensitive.
>
> It applies some sort of Unicode normalization, which is just about as
> bad as case normalization.
What a surprise this would be for a user, to face a case where “É” =/= “É”
This may also be for security reason (there have been some attacks based  
on tricky issues with Unicode).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

Re: _Type vs no _Type

[Georg Bauhaus]

On 11/5/10 8:05 AM, Florian Weimer wrote:
> * Britt Snodgrass:
>
>> The language design decision that Ada be case insensitive is something
>> that I value very much.  In general, I think the "flexibility"
>> provided by case sensitivity causes more problems (risks, bugs,
>> reduced readability) than it potentially solves.
>
> And with case insensitivity, we have a seemingly neverending
> collection of warts, bugs and incompatibilities in the Ada language.

We can choose our case ourselves, as Ada programmers.

Case insensitivity reduces the number of very similar
identifiers by 2.

If I could, I'd go further and make A_Foo mean
the same as AFoo and aFoo and _aFoo.

Does AdaControl have a rule for too similar names?

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Fri, 05 Nov 2010 09:48:23 +0100, Yannick Duchêne (Hibou57) wrote:

> What a surprise this would be for a user, to face a case where “É” =/= “É”

BTW, Greek Ε, Cyrillic Е, Latin E are all different code points, so an Ada
2005 program with Unicode support should consider them distinct
identifiers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Fri, 05 Nov 2010 11:58:24 +0100, Georg Bauhaus wrote:

> Case insensitivity reduces the number of very similar
> identifiers by 2.

by 2**n? Where n is the identifier's length.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: _Type vs no _Type

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> BTW: do you want to see my collection of things where the most succesful
> design failed to be the most popular one?

I do, although I'm not sure you said what you meant above ;-).

- Bob

Re: _Type vs no _Type

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> Here is the core of the _Type argument: It helps avoid thinking.

It avoids thinking about one mundane aspect of the program.
The argument is: save your "thinking" for more important things.

>... Given a
> problem, a coder sits down and starts writing code; a S/W engineer
> thinks about the problem.

You're getting perilously close to an ad-hominem.  I don't much
like the "_Type" convention, either, but I'm not going to
accuse people who disagree of being less than competent.

At AdaCore, I never, ever think about how many blanks to
indent by.  There is an AdaCore law that it's 3, and I
obey that law without thinking (and have my editor do
it automatically).  I'd prefer 4, myself, but getting
creative at this level is a Bad Thing.

And calling oneself "engineer" doesn't make one better at
making software.

>...Thinking is thus the defining characteristic
> of the S/W engineer, and attempting to avoid thinking the antithesis of
> S/W engineering.

That doesn't follow -- the fact that I avoid thinking about
"3 blanks to indent" doesn't mean I avoid thinking.
Likewise, people who avoid thinking by using "_Type"
do not avoid thinking altogether.

There are some cases where it is very wrong to come up
with "meaningful" names.  In particular, a parameter
of a general-purpose subprogram, when named notation
is inappropriate.  In such a case, a single-letter
name, or (a variation on) the type name, is exactly
right.

- Bob

Re: _Type vs no _Type

[Robert A Duff]

"Nasser M. Abbasi" <nma@12000.org> writes:

> Isn't this whole subject a result of Ada being case insensitive?
>
> If Ada has been case sensitive, then one would write
>
> weapon : Weapon;

You don't need case sensitivity to allow "weapon: Weapon;".
Nor do you need separate namespaces for types, as some
have suggested.

A language could allow overloading of object and type
names, and determine what you mean by context.
And have some syntax for disambiguation when necessary
(like Ada does with qualified expressions).
In Ada, you can say "F(f(X));" and it's clear from
the syntax that the first F is a procedure name, and the
second f is a function name.  Likewise, in "not Ada",
it might be clear in "weapon: Weapon;", the first one
declares an object name, and second one is a type name.
Something would have to be done about "Mumble'First"
and the like.

I'm not advocating for or against the idea -- just pointing
out some language design issues.

By the way, I don't like case sensitivity, and I don't like
case insensitivity, either.  A better rule is the one
implemented by GNAT in its default mode (or with -gnatwe).

- Bob

Re: _Type vs no _Type

[Robert A Duff]

"Nasser M. Abbasi" <nma@12000.org> writes:

> Sorry, but have a look at all the new languages and also at the list of
> most popular languages. They are almost all, if not all, case
> sensitive. There must be a good reason for this.

I don't buy arguments based on popularity, nor on new-ness.
If I did, I wouldn't be using Ada, which is neither the
most popular, nor the newest, programming language!  ;-)

In most popular/new languages, if you don't give others/default
in a case/switch/whatever statement, the case statement is a no-op.
"There must be a good reason for this."???  Well, no, there
is no good reason -- it's just a bad idea.  Ada does it
right.

- Bob

Re: _Type vs no _Type

[Florian Weimer]

* Georg Bauhaus:

>> And with case insensitivity, we have a seemingly neverending
>> collection of warts, bugs and incompatibilities in the Ada language.
>
> We can choose our case ourselves, as Ada programmers.

Except when we can't, like in the result of 'Image for enumeration
literals.  Please get your facts straight.

Re: _Type vs no _Type

[Georg Bauhaus]

On 05.11.10 17:31, Dmitry A. Kazakov wrote:
> On Fri, 05 Nov 2010 11:58:24 +0100, Georg Bauhaus wrote:
> 
>> Case insensitivity reduces the number of very similar
>> identifiers by 2.
> 
> by 2**n? Where n is the identifier's length.

Yes, the exponential thing is what I had in mind.
Thanks.

Re: _Type vs no _Type

[Florian Weimer]

* J-P. Rosen:

> Le 05/11/2010 08:05, Florian Weimer a �crit :
>> And with case insensitivity, we have a seemingly neverending
>> collection of warts, bugs and incompatibilities in the Ada language.
>
> ??? Could you be more precise, and especially for "incompatibilities" ?

The following program

with Ada.Text_IO;
procedure T is
   type E is (�);
begin
   Ada.Text_IO.Put_Line (E'Image (�));
end T;

should print a line containing the single character "�".  Can you
tweak your favorite Ada compiler to produce this output?  Does it
still work when the program runs under another system-supported
locale?

Part of those difficulties are related to case insensitivity (but not
all of them).

Re: _Type vs no _Type

[Florian Weimer]

* Shark8:

> Consider this code:
>
> Type THIS is private;
> Procedure this( This: out THIS; THis : in THIS; THIs : in out THIS );
>
> Upon *hearing* your boss say "There is a problem in the program with
> this; fix it." what "this" is he talking about?

Given that Ada allows you to write this:

   Type TΗIS is private;
   Procedure this( Τhis: out TΗIS; ΤΗis : in TΗIS; THIs : in out TΗIS );

if you really want to, I find this argument totally out of place in
the Ada context.  (In any case, a program which is provable correct,
passes the compiler, and works as expected, can still be written in a
bad style.)

There is a considerable amount of wording in the standard to make the
example above legal, so I guess some people feel really strongly about
this language feature.  And it interacts very badly with case
insensitivity, by the way.

Re: _Type vs no _Type

[Georg Bauhaus]

On 05.11.10 18:31, Florian Weimer wrote:
> * Georg Bauhaus:
> 
>>> And with case insensitivity, we have a seemingly neverending
>>> collection of warts, bugs and incompatibilities in the Ada language.
>>
>> We can choose our case ourselves, as Ada programmers.
> 
> Except when we can't, like in the result of 'Image for enumeration
> literals.  Please get your facts straight.

As a fact, I have been able to use identifiers like
�pfel for a very long time.

with Ada.Text_IO;
procedure T is
   type E is (�);
   �pfel : E := E'First;
begin
   Ada.Text_IO.Put_Line (E'Image (�pfel));
end T;

Enum_Type'Image (�) not outputting � is a bug in GNAT.

The Ada fact is that there are rules about character
case in identifiers.  Just like there are rules
about digits in numbers. There is no problem with
compiling the above: even though �pfel and �pfel use
different case, GNAT considers them the same
identifier, as should be.

You might be talking about Birnen or the phase
of the moon, I think.

Re: _Type vs no _Type

[Georg Bauhaus]

On 05.11.10 18:39, Florian Weimer wrote:

> should print a line containing the single character "�".  Can you
> tweak your favorite Ada compiler to produce this output?  Does it
> still work when the program runs under another system-supported
> locale?
>
> Part of those difficulties are related to case insensitivity (but not
> all of them).

The difficulty with character case in the real world
is mostly related to a teaching tradition and its
effect on non-US software.

The tradition produces programmers who think of themselves
as engineers which means 'A' .. 'Z' and nothing else.
And 'A' is 65, please!  So, after decades of programming,
engineers continue to shy away from properly typed notions
of what text characters are.

It's a pride thing, I believe, since you'd have to admit
that you need training in characters.

The usual rationalization is a self-fulfilling prophecy:

We don't have customers complaining about this.

Re: _Type vs no _Type

[Georg Bauhaus]

On 05.11.10 18:49, Florian Weimer wrote:

> Given that Ada allows you to write this:
> 
>    Type TΗIS is private;
>    Procedure this( Τhis: out TΗIS; ΤΗis : in TΗIS; THIs : in out TΗIS );

You do not want o revive a discussion about the number I0l, do you?

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/05/2010 10:15 AM, Robert A Duff wrote:
>
>
> That doesn't follow -- the fact that I avoid thinking about "3 blanks to
> indent" doesn't mean I avoid thinking. Likewise, people who avoid thinking by
> using "_Type" do not avoid thinking altogether.

Not thinking about indentation is fine. It would also be fine if you never 
thought about type identifiers. But using _Type doesn't eliminate thinking about 
type identifiers, just thinking about /good/ type identifiers (the most 
important kind of thinking).

> There are some cases where it is very wrong to come up with "meaningful"
> names.  In particular, a parameter of a general-purpose subprogram, when
> named notation is inappropriate.  In such a case, a single-letter name, or (a
> variation on) the type name, is exactly right.

I disagree very strongly with the single-letter idea. Although I have seen 
plenty of single-letter parameter names, I have never seen a case where it was 
appropriate, or where a little thought couldn't come up with good names.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/05/2010 09:01 AM, Dmitry A. Kazakov wrote:
>
> BTW, Greek Ε, Cyrillic Е, Latin E are all different code points, so an Ada
> 2005 program with Unicode support should consider them distinct
> identifiers.

Personally, I think allowing non-English identifiers in a language with English 
reserved words is a mistake.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/05/2010 10:29 AM, Robert A Duff wrote:
> "Nasser M. Abbasi"<nma@12000.org>  writes:
>
>> Sorry, but have a look at all the new languages and also at the list of
>> most popular languages. They are almost all, if not all, case
>> sensitive. There must be a good reason for this.
>
> I don't buy arguments based on popularity, nor on new-ness.
> If I did, I wouldn't be using Ada, which is neither the
> most popular, nor the newest, programming language!  ;-)

Ada is not, and never will be, popular. Ada is a S/W-engineering language, and 
most developers are not S/W engineers.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Fri, 05 Nov 2010 12:26:32 -0700, Jeffrey Carter wrote:

> On 11/05/2010 09:01 AM, Dmitry A. Kazakov wrote:
>>
>> BTW, Greek 嚙瘡, Cyrillic ザ, Latin E are all different code points, so an Ada
>> 2005 program with Unicode support should consider them distinct
>> identifiers.
> 
> Personally, I think allowing non-English identifiers in a language with English 
> reserved words is a mistake.

Yes

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: _Type vs no _Type

[Florian Weimer]

* Jeffrey Carter:

> Personally, I think allowing non-English identifiers in a language
> with English reserved words is a mistake.

"English" or "ASCII"?

Re: _Type vs no _Type

[Vinzent Hoefler]

On Fri, 05 Nov 2010 18:24:09 +0100, Robert A Duff <bobduff@shell01.theworld.com> wrote:

> By the way, I don't like case sensitivity, and I don't like
> case insensitivity, either.  A better rule is the one
> implemented by GNAT in its default mode (or with -gnatwe).

? "-gnatwe" is "treat warning as errors" (at least here, GNAT GPL2010).

Do you mean the rule, that once you declared an identifier, you have
to stick to its casing?

What do you call that? "Case stickiness"?


Vinzent.

-- 
There is no signature.

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Fri, 05 Nov 2010 20:35:46 +0100, Florian Weimer wrote:

> * Jeffrey Carter:
> 
>> Personally, I think allowing non-English identifiers in a language
>> with English reserved words is a mistake.
> 
> "English" or "ASCII"?

Is there any other language that does not deploy diaeresis marks, except
for English and Latin?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: _Type vs no _Type

[Florian Weimer]

* Dmitry A. Kazakov:

> On Fri, 05 Nov 2010 20:35:46 +0100, Florian Weimer wrote:
>
>> * Jeffrey Carter:
>> 
>>> Personally, I think allowing non-English identifiers in a language
>>> with English reserved words is a mistake.
>> 
>> "English" or "ASCII"?
>
> Is there any other language that does not deploy diaeresis marks, except
> for English and Latin?

Call me na�ve, but I assumed that English uses that diacritic mark,
too.

Re: Beginners question: Compound types, how-to?

[Warren]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

Martin expounded in news:6a4be998-e934-4a96-842c-
c1e73b5bb11f@j25g2000yqa.googlegroups.com:

> On Nov 4, 1:59�pm, Warren <ve3...@gmail.com> wrote:
>> Georg Bauhaus expounded in news:4cd1e2ec$0$6978$9b4e6d93
>> @newsspool4.arcor-online.net:
>>
> [snip]
>> There is only ever going to be _ONE_ instance of that type. �
>> So what names do you give the type and the single instance?
>>
>> Terminal : Terminal_Type;
>> -- or
>> The_Terminal : Terminal;
> [snip]
> 
> Personally, I prefer:
> 
>    Terminal : A_Terminal;
> 
> At least this preserves the English meaning of the indefinite
> article. :-)
> 
> -- Martin

Personal choice can be An_Enigma. ;-)

Warren

Re: _Type vs no _Type

[Warren]

Florian Weimer expounded in news:87iq0bef71.fsf@mid.deneb.enyo.de:

> * Jeffrey Carter:
> 
>> Personally, I think allowing non-English identifiers in a language
>> with English reserved words is a mistake.
> 
> "English" or "ASCII"?

I am fluent in ASCII. ACK?

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Fri, 05 Nov 2010 21:14:33 +0100, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>> On Fri, 05 Nov 2010 20:35:46 +0100, Florian Weimer wrote:
>>
>>> * Jeffrey Carter:
>>> 
>>>> Personally, I think allowing non-English identifiers in a language
>>>> with English reserved words is a mistake.
>>> 
>>> "English" or "ASCII"?
>>
>> Is there any other language that does not deploy diaeresis marks, except
>> for English and Latin?
> 
> Call me na�ve, but I assumed that English uses that diacritic mark,
> too.

Nobody cared when ASCII was defined.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/05/2010 12:35 PM, Florian Weimer wrote:
> * Jeffrey Carter:
>
>> Personally, I think allowing non-English identifiers in a language
>> with English reserved words is a mistake.
>
> "English" or "ASCII"?

Ideally, English, but that's rather hard to enforce. But something like

Identifier = Initial_Part {'_' Following_Part}

Initial_Part = All_Caps | Upper_Case {Lower_Or_Digit}

Following_Part = Initial_Part | Digit {Digit}

All_Caps = Upper_Case {Upper_Case}

Upper_Case = Character range 'A' .. 'Z'

Lower_Or_Digit = Lower_Case | Digit

Digit = Character range '0' .. '9'

Lower_Case = Character range 'a' .. 'z'

would probably work (if you can understand my pseudo-BNF).

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: _Type vs no _Type

[Robert A Duff]

"Vinzent Hoefler" <nntp-2010-10@t-domaingrabbing.de> writes:

> On Fri, 05 Nov 2010 18:24:09 +0100, Robert A Duff <bobduff@shell01.theworld.com> wrote:
>
>> By the way, I don't like case sensitivity, and I don't like
>> case insensitivity, either.  A better rule is the one
>> implemented by GNAT in its default mode (or with -gnatwe).
>
> ? "-gnatwe" is "treat warning as errors" (at least here, GNAT GPL2010).

Right.  I don't think there's a big difference between errors
and warnings in practise.

> Do you mean the rule, that once you declared an identifier, you have
> to stick to its casing?

Yes.

It all gets very complicated with Unicode, but I mostly
stick with 7-bit ASCII, so I'm reasonably happy with this GNAT
rule.

> What do you call that? "Case stickiness"?

I don't have a name for it.  "Case stickiness" is reasonable,
I suppose.

- Bob

Re: _Type vs no _Type

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> Not thinking about indentation is fine. It would also be fine if you
> never thought about type identifiers. But using _Type doesn't eliminate
> thinking about type identifiers, just thinking about /good/ type
> identifiers (the most important kind of thinking).

Well, you still have to think of something /good/ to go before
the "_Type".

> I disagree very strongly with the single-letter idea. Although I have
> seen plenty of single-letter parameter names, I have never seen a case
> where it was appropriate, or where a little thought couldn't come up
> with good names.
       ^^^^

But, you see, some folks, including me, think single-letter parameters
names ARE "good", in some cases.  Here's an example (from the GNAT
sources, file sinfo.ads):

   function Abort_Present (N : Node_Id) return Boolean;

The body of this function is short, so the single-letter "N"
doesn't get lost.  What would you call it?

It could just as well be "Node" or (in Not-Ada) "node_id",
but that doesn't add any useful information to the reader
of the program, IMHO.  And named notation doesn't make
sense for calls to Abort_Present, no matter what the
parameter name is.

What about operators?  The Ada RM says:

    function "+"(Left, Right: T) return T;

but I think that's just silly.  I usually say:

    function "+"(X, Y: T) return T;

Named notation never, ever, ever makes sense for operators.
And if the body of "+" is short, single-letter
names are crystal clear.

Verbosity is good when it imparts useful information to
the reader of the code, but not otherwise.

- Bob

Re: _Type vs no _Type

[Brian Drummond]

On Fri, 5 Nov 2010 20:45:07 +0000 (UTC), Warren <ve3wwg@gmail.com> wrote:

>Florian Weimer expounded in news:87iq0bef71.fsf@mid.deneb.enyo.de:
>
>> * Jeffrey Carter:
>> 
>>> Personally, I think allowing non-English identifiers in a language
>>> with English reserved words is a mistake.
>> 
>> "English" or "ASCII"?
>
>I am fluent in ASCII. ACK?

I'm sure I've forgotten the code for ACK, but control-G rings a bell...

- Brian

Re: _Type vs no _Type

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> Ada is not, and never will be, popular. ...

Probably true, relative to some other languages.
In its small niche, Ada is pretty popular.

>...Ada is a S/W-engineering
> language, and most developers are not S/W engineers.

Well, maybe, but how many people will be attracted to
Ada by sneering at them for being less than true
engineers?

- Bob

P.S. My grandfather was a "true" engineer.  He drove a train.
He worked for the Pennsylvania Railroad.  ;-)

Re: _Type vs no _Type

[J-P. Rosen]

Le 05/11/2010 11:58, Georg Bauhaus a �crit :

> Does AdaControl have a rule for too similar names?
> 
N**2 comparisons, with pattern matching? Sorry, no ;-)

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[J-P. Rosen]

Le 05/11/2010 17:39, Robert A Duff a �crit :
> "J-P. Rosen" <rosen@adalog.fr> writes:
> 
>> BTW: do you want to see my collection of things where the most succesful
>> design failed to be the most popular one?
> 
> I do, although I'm not sure you said what you meant above ;-).
> 
By "most successful" I meant "technically best".

Mac vs PC, VMS vs Unix, Betamax vs VHS, OS/2 vs Windows to name a few...
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[J-P. Rosen]

Le 05/11/2010 18:39, Florian Weimer a �crit :
> The following program
> 
> with Ada.Text_IO;
> procedure T is
>    type E is (�);
> begin
>    Ada.Text_IO.Put_Line (E'Image (�));
> end T;
> 
> should print a line containing the single character "�".  Can you
> tweak your favorite Ada compiler to produce this output?  Does it
> still work when the program runs under another system-supported
> locale?
> 
> Part of those difficulties are related to case insensitivity (but not
> all of them).
The 'Image attribute has nothing to do whatsoever with case insensitivity.

The issue of upper-case mapping is very difficult, and there are
actually several mappings defined in Unicode. Moreover, what's printed
on your terminal reflects the mapping that your terminal does between
code-points and glyphs, which is totally outside of the domain of the
programming language.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 05/11/2010 11:58, Georg Bauhaus a �crit :
>
>> Does AdaControl have a rule for too similar names?
>> 
> N**2 comparisons, with pattern matching? Sorry, no ;-)

I don't see any N**2.  Yeah, that would be bad.

Squeeze out "_".  Convert to lower case (or upper case?).
Convert similar-looking characters to the same.
(E.g. "0"(zero) --> "O"(Oh).)  Then compare.

It might be complicated to figure out what characters
are "similar-looking", and to figure out which Unicode
case-mapping to use, but it seems like an O(N) lookup
in a hash table should then suffice.

- Bob

Re: _Type vs no _Type

[Georg Bauhaus]

On 11/6/10 12:29 AM, J-P. Rosen wrote:
> Le 05/11/2010 11:58, Georg Bauhaus a �crit :
>
>> Does AdaControl have a rule for too similar names?
>>
> N**2 comparisons, with pattern matching? Sorry, no ;-)
>
(:-)

But surely some inspiring code in GNAT transforms identifiers
to some canonical form?  It has a soundex algorithm built in,
AFAICT  :->

Re: _Type vs no _Type

[Simon Wright]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> Le 05/11/2010 11:58, Georg Bauhaus a écrit :
>>
>>> Does AdaControl have a rule for too similar names?
>>> 
>> N**2 comparisons, with pattern matching? Sorry, no ;-)
>
> I don't see any N**2.  Yeah, that would be bad.
>
> Squeeze out "_".  Convert to lower case (or upper case?).
> Convert similar-looking characters to the same.
> (E.g. "0"(zero) --> "O"(Oh).)  Then compare.

Lower-case l (ell) and 1 (one)? but if the original was an upper-case L
it wouldn't be so bad.

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/05/2010 03:52 PM, Robert A Duff wrote:
>
> Well, you still have to think of something /good/ to go before
> the "_Type".

In which case you might as well think of something that's good without _Type.

> But, you see, some folks, including me, think single-letter parameters
> names ARE "good", in some cases.  Here's an example (from the GNAT
> sources, file sinfo.ads):
>
>     function Abort_Present (N : Node_Id) return Boolean;
>
> The body of this function is short, so the single-letter "N"
> doesn't get lost.  What would you call it?

I don't know, since I don't know what it's for or what role the parameter plays.

> What about operators?  The Ada RM says:
>
>      function "+"(Left, Right: T) return T;
>
> but I think that's just silly.  I usually say:
>
>      function "+"(X, Y: T) return T;
>
> Named notation never, ever, ever makes sense for operators.

I agree, but use Left and Right for consistency.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: _Type vs no _Type

[Shark8]

On Nov 5, 4:52 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> What about operators?  The Ada RM says:
>
>     function "+"(Left, Right: T) return T;
>
> but I think that's just silly.  I usually say:
>
>     function "+"(X, Y: T) return T;

I have to agree with the Ada RM here, I like Left and Right as the
parameter names.
In justifying the usage of single-letter names for the parameters, say
as in mathematics, then you ALSO have to acknowledge that "a < b" is
exactly equivalent to "b < a" when 'b' and 'a' are completely free.
{That is, when starting your proof you could say "let a = 1 and b = 2"
just as easily, and validly, as "let be = 1 and a = 2."}

> Named notation never, ever, ever makes sense for operators.
> And if the body of "+" is short, single-letter
> names are crystal clear.

Well, except in the case where you need to specify an operator that
might not be immediately visible.
In that case it makes 'Left' and 'Right' into excellent parameter
names as opposed to the single-letter ones.

> Verbosity is good when it imparts useful information to
> the reader of the code, but not otherwise.

Agreed.

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/05/2010 04:09 PM, Robert A Duff wrote:
> Jeffrey Carter<spam.jrcarter.not@spam.not.acm.org>  writes:
>
>> ...Ada is a S/W-engineering
>> language, and most developers are not S/W engineers.
>
> Well, maybe, but how many people will be attracted to
> Ada by sneering at them for being less than true
> engineers?

I don't want to attract coders to Ada.

> P.S. My grandfather was a "true" engineer.  He drove a train.
> He worked for the Pennsylvania Railroad.  ;-)

Cool. Do you try to buy that when you play Monopoly?

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Sat, 06 Nov 2010 00:32:02 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:

> Le 05/11/2010 17:39, Robert A Duff a écrit :
>> "J-P. Rosen" <rosen@adalog.fr> writes:
>>
>>> BTW: do you want to see my collection of things where the most  
>>> succesful
>>> design failed to be the most popular one?
>>
>> I do, although I'm not sure you said what you meant above ;-).
>>
> By "most successful" I meant "technically best".
>
> Mac vs PC, VMS vs Unix, Betamax vs VHS, OS/2 vs Windows to name a few...

Mac vs PC : a matter of price
http://vista.blorge.com/2009/04/20/apple-fanboys-fight-back-in-mac-vs-pc-pricing-debate/

VMS vs Unix : do not know, while interestingly VMS run on 64 bits  
architectures as early as… 1992
http://www3.sympatico.ca/n.rieck/docs/vms_vs_unix.html
At least, VMS commands was more intelligible than the ones of UNIX
http://shum.huji.ac.il/cc/guides/VMSvsUNIX.html

Betamax vs VHS : a matter of price, and a matter of recording length
http://www.mediacollege.com/video/format/compare/betamax-vhs.html

OS/2 vs Windows : do not have any reference in hand, just that I remember  
Microsoft played all he could to make it forgotten.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Fri, 05 Nov 2010 18:39:46 +0100, Florian Weimer <fw@deneb.enyo.de> a  
écrit:

> * J-P. Rosen:
>
>> Le 05/11/2010 08:05, Florian Weimer a écrit :
>>> And with case insensitivity, we have a seemingly neverending
>>> collection of warts, bugs and incompatibilities in the Ada language.
>>
>> ??? Could you be more precise, and especially for "incompatibilities" ?
>
> The following program
>
> with Ada.Text_IO;
> procedure T is
>    type E is (ä);
> begin
>    Ada.Text_IO.Put_Line (E'Image (ä));
> end T;
>
> should print a line containing the single character "ä".  Can you
> tweak your favorite Ada compiler to produce this output?

Tested on Windows XP, with two different results depending on the console  
used. If the resulting program is run in the classic console  
(CMD.exe/COMMAND.com), it outputs a capital letter A with a diaeresis  
(OK). If the program in launched in a PowerShell console (also available  
for Windows XP), then it output a long-dash instead (PS prefers UTF-16).

What the complier produce is OK.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Fri, 05 Nov 2010 23:52:03 +0100, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:
> What about operators?  The Ada RM says:
>
>     function "+"(Left, Right: T) return T;
>
> but I think that's just silly.  I usually say:
>
>     function "+"(X, Y: T) return T;
>
The same (except I use A, B), but the Left, Right is nice when the  
operation is not commutative, like with divide, then it is better to give  
two explicit names.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Fri, 05 Nov 2010 17:40:49 -0700, Jeffrey Carter wrote:

>>      function "+"(X, Y: T) return T;
>>
>> Named notation never, ever, ever makes sense for operators.
> 
> I agree, but use Left and Right for consistency.

Hmm, I would expect you arguing for

   function "/" (Dividend : T; Divisor : T) return T;

For commutative operations like "+" it becomes a bit difficult:

   function "+" (2 * Summand : T) return T;    -- (:-))

which BTW, illustrates another problem. The name meaningful for the client
is not necessarily meaningful for the implementation and conversely. For
the client of "+" operands are equivalent and names should reflect this
fact, but cannot. An implementation of "+" will have to distinguish
operands and Left/Right is a poor choice because unrelated to the
implementation. For primitive operations you even allowed to rename
arguments, which is looks very implementation-oriented.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Sat, 06 Nov 2010 08:12:29 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> which BTW, illustrates another problem. The name meaningful for the  
> client is not necessarily meaningful for the implementation and  
> conversely.

Yes. And sometime, something, when you want to avoid hiding, you still get  
hiding due to parameter names.

It happened I though this could be nice to have some names at the  
declaration side, and an aliasing at the implementation side. You can use  
rename clauses at the implementation, but this does not avoid warnings  
about a name hiding another. This is a matter if you treat warnings as  
errors.

    function Foo return Foo_Type;
    -- Will be “hidden” (at least, the compiler
    -- see the story this way).

    procedure Truc (Foo : Foo_Type);
    -- The parameter Foo hides nothing for the
    -- user, but it hides something for the
    -- implementation (note: Truc is the french
    -- for “Foo”).

Then

    procedure Truc (Foo : Foo_Type)
    is
       Input_Foo : Foo_Type renames Truc.Foo;
       -- There is clearly no more ambiguity,
       -- but the compiler don't want to know
       -- and still complains about the parameter
       -- Foo hiding the other.
    begin
       ...
       ...
    end;

May be a more cooperative compiler is an idea.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Georg Bauhaus]

On 11/6/10 8:12 AM, Dmitry A. Kazakov wrote:

> Hmm, I would expect you arguing for
>
>     function "/" (Dividend : T; Divisor : T) return T;
>
> For commutative operations like "+" it becomes a bit difficult:

You aren't suggesting the computer-"+" is a commutative
operation, are you?

Re: _Type vs no _Type

[J-P. Rosen]

Le 06/11/2010 01:00, Robert A Duff a �crit :
> "J-P. Rosen" <rosen@adalog.fr> writes:
> 
>> Le 05/11/2010 11:58, Georg Bauhaus a �crit :
>>
>>> Does AdaControl have a rule for too similar names?
>>>
>> N**2 comparisons, with pattern matching? Sorry, no ;-)
> 
> I don't see any N**2.  Yeah, that would be bad.
> 
> Squeeze out "_".  Convert to lower case (or upper case?).
> Convert similar-looking characters to the same.
> (E.g. "0"(zero) --> "O"(Oh).)  Then compare.
> 
> It might be complicated to figure out what characters
> are "similar-looking", and to figure out which Unicode
> case-mapping to use, but it seems like an O(N) lookup
> in a hash table should then suffice.
> 
Plus the management of visibility - which AdaControl can do.
OK, might be doable. If you can provide me with a specification of
"similar" - and funding ;-) - it might appear.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Sat, 06 Nov 2010 12:00:38 +0100, Georg Bauhaus wrote:

> On 11/6/10 8:12 AM, Dmitry A. Kazakov wrote:
> 
>> Hmm, I would expect you arguing for
>>
>>     function "/" (Dividend : T; Divisor : T) return T;
>>
>> For commutative operations like "+" it becomes a bit difficult:
> 
> You aren't suggesting the computer-"+" is a commutative
> operation, are you?

I do. The implementation of "+" is not "strictly" commutative, but its
interface does not tell that. The implied, not stated contract, is that "+"
is indeed commutative allowing certain compiler optimizations. A numeric
expression denotes a set of results satisfying certain conditions (accuracy
constraints required by the ARM). Within these limits "+" is "weakly"
commutative.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: _Type vs no _Type

[Robert A Duff]

Shark8 <onewingedshark@gmail.com> writes:

> On Nov 5, 4:52�pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>> Named notation never, ever, ever makes sense for operators.
>> And if the body of "+" is short, single-letter
>> names are crystal clear.
>
> Well, except in the case where you need to specify an operator that
> might not be immediately visible.

IMHO, you should never, ever, ever be in that situation.

The whole point of operator symbols is that you don't
want a nice long meaningful name, you want a short
symbol, and all readers of the code must memorize
what it means.  (For "+" they probably memorized
it in grade school, except the part about overflow.)

Writing Foo."+"(Left => ..., Right => ...) or
Foo."+"(..., ...) completely defeats the purpose.
You should instead say "use" or "use type".
Or if you really want the package name, then
you shouldn't have made it an operator symbol
in the first place.

If I were in charge, operators would always be directly
visible.  It's really silly that ":=" is always visible,
but "=" is not.  This idea was proposed for Ada 9X,
but it was rejected because it is (slightly)
incompatible.  That's when "use type" was invented
as a workaround.

- Bob

Re: _Type vs no _Type

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 06 Nov 2010 12:00:38 +0100, Georg Bauhaus wrote:
>
>> On 11/6/10 8:12 AM, Dmitry A. Kazakov wrote:
>> 
>>> Hmm, I would expect you arguing for
>>>
>>>     function "/" (Dividend : T; Divisor : T) return T;
>>>
>>> For commutative operations like "+" it becomes a bit difficult:
>> 
>> You aren't suggesting the computer-"+" is a commutative
>> operation, are you?
>
> I do. The implementation of "+" is not "strictly" commutative, but its
> interface does not tell that. The implied, not stated contract, is
> that "+" is indeed commutative allowing certain compiler
> optimizations. A numeric expression denotes a set of results
> satisfying certain conditions (accuracy constraints required by the
> ARM). Within these limits "+" is "weakly" commutative.

One would very much _hope_ that these two would behave commutatively, of
course.

function "+" (L : Time; R : Duration) return Time;
function "+" (L : Duration; R : Time) return Time;

Re: _Type vs no _Type

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> At least, VMS commands was more intelligible than the ones of UNIX
> http://shum.huji.ac.il/cc/guides/VMSvsUNIX.html

For me, once I'd started serious work on Unix I was very pleased to
leave VMS behind.

Re: _Type vs no _Type

[Dmitry A. Kazakov]

On Sat, 06 Nov 2010 13:34:41 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 06 Nov 2010 12:00:38 +0100, Georg Bauhaus wrote:
>>
>>> On 11/6/10 8:12 AM, Dmitry A. Kazakov wrote:
>>> 
>>>> Hmm, I would expect you arguing for
>>>>
>>>>     function "/" (Dividend : T; Divisor : T) return T;
>>>>
>>>> For commutative operations like "+" it becomes a bit difficult:
>>> 
>>> You aren't suggesting the computer-"+" is a commutative
>>> operation, are you?
>>
>> I do. The implementation of "+" is not "strictly" commutative, but its
>> interface does not tell that. The implied, not stated contract, is
>> that "+" is indeed commutative allowing certain compiler
>> optimizations. A numeric expression denotes a set of results
>> satisfying certain conditions (accuracy constraints required by the
>> ARM). Within these limits "+" is "weakly" commutative.
> 
> One would very much _hope_ that these two would behave commutatively, of
> course.
> 
> function "+" (L : Time; R : Duration) return Time;
> function "+" (L : Duration; R : Time) return Time;

Yes, though neither of two is commutative.

It would be nice if Ada supported class-wide operations defined on tuples,
e.g. (imaginary syntax):

  function "+" (L : Time | R : Duration) return Time;

a class-wide truly commutative operation defined on the anonymous class:

  { (Time, Duration), (Duration, Time) }

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Beginners question: Compound types, how-to?

[Stephen Leake]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

> On 11/4/10 6:23 AM, Stephen Leake wrote:
>
> Why is it that the "_type"  camp is so consistently silent
> about giving specific contexts of what are just programming
> examples?

Because when you are writing a general purpose library, there is no
specific context.

A list package can be used in many different contexts. The package
should be named Lists (or Gen_Lists if it is generic), the type should
be named Lists.List, the subprogram arguments should be named List. 

What more is there to say?

>> Notice that the "find a better name" camp always suggests _several_
>> names, and each person suggests _different_ ones. That means there is no
>> common solution, and the resulting code will be confusing, and subject
>> to endless arguments about "the right name" in code reviews.
>
> The "find a better name" camp only suggests several names in order
> to offer ideas, as best as they can not knowing the context
> like the programmers do---or are supposed to do.

Like I said, not actually solving the problem, only providing for
endless discussion.

> The programmers or team can pick the one name that matches best.

No, they can't, because they won't agree on what is "best", any more
than this newsgroup does.

-- 
-- Stephe

Re: Beginners question: Compound types, how-to?

[Stephen Leake]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

> On 11/4/10 6:23 AM, Stephen Leake wrote:
>
>> Notice that the "find a better name" camp always suggests _several_
>> names, and each person suggests _different_ ones. That means there is no
>> common solution, and the resulting code will be confusing, and subject
>> to endless arguments about "the right name" in code reviews.
>>
>> At least with _Type, the solution is very clear.
>
> The choice of _Type just dissolves the issue. :-)

Yes. What's wrong with that?

> Say you see program text with _Type.
>
> _Type is very much like the "abc: Abc" approach mentioned in this
> thread, that is used with case sensitive languages:
> it uses the same word twice.

Yes.

> I'm saying the same word because both letter case and _Type do not
> change the meaning of words. "Weapon" means the same as "weapon" or
> "Weapon_Type", as far as the meaning of the things in the type's value
> set is concerned.

Right.

> I once liked the case idea, too, but after having to switch languages
> every now and then, I wholly understand the complaints posted against
> tword: Tword.  For a start, this convention forces one to become highly
> sensitive to the presence of case sensitivity in either language.
> The effect on the program's reader is a doubled effort.

Doubled compared to what? 

I don't like the pure case distinction becuase it does not convey when
spoken. _Type doesn't have that problem.

> Worse, if you see FooType in Python, C++, whatever, the _Type
> suffix habit becomes a source of confusion.  It is very likely
> possible that the authors have written "Type" to convey meaning,
> and not to have it indicate "'Foo' used as a type name".
> The effect is a higher risk of a misunderstanding.

That's purely dependent on the naming convention. If the convention is
to use Type for all types, there is no risk of understanding.

If there is no convention at all, then there will be misunderstanding.

> If every identifier is chosen for its meaning instead of for its
> function, then these two problems do not arise.

If a clear, simple, consistent naming convention is used, these problems
do not arise.

Please stop putting up straw man arguments!

-- 
-- Stephe

Re: _Type vs no _Type

[(see below)]

On 06/11/2010 07:12, in article g99f7vycatem$.1xtq9qp9kz0rt.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> For commutative operations like "+" it becomes a bit difficult:
> 
>    function "+" (2 * Summand : T) return T;    -- (:-))
> 
> which BTW, illustrates another problem. The name meaningful for the client
> is not necessarily meaningful for the implementation and conversely.

SCL, the command language for the ICL/Fujitsu VME OS, is loosely based on
Algol 68 and has a facility to deal with this. A procedure's signature
includes for each parameter, as well as its identifier and type, an optional
"keyword". It is the latter that is used where Ada uses the formal parameter
identifier, in named parameter associations. Only the formal parameter
identifier can be used within the procedure body.

-- 
Bill Findlay
with blueyonder.co.uk;
<surname><forename>

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/06/2010 09:49 AM, Stephen Leake wrote:
>
> A list package can be used in many different contexts. The package
> should be named Lists (or Gen_Lists if it is generic), the type should
> be named Lists.List, the subprogram arguments should be named List.

How much better if the parameter names for Insert are Into and Before, and for 
Append, Onto (and After, if appending after a location is allowed), rather than 
List and Position.

Sorry, I forgot: that involves thinking.

-- 
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/6/10 5:53 PM, Stephen Leake wrote:

> If a clear, simple, consistent naming convention is used, these problems
> do not arise.

A simple, consistent naming convention may simply not exist when
you work across (a) languages, (b) on different projects...

> Please stop putting up straw man arguments!

... hence the argument is not at all a straw man. Is is a simple
observation of programming realities (a) and (b).

What I see here is an attempt to generalize a special case.

By sheer luck, some here on c.l.ada seem to be working in places
where there is one established coding convention.  This sure makes
for a happy living on a coding island and when this island has sufficient
extent, fine.  But in the light of (a) and (b) above, it does not
make for a general argument in favor of a convention in place of
good names.

Re: Beginners question: Compound types, how-to?

[Georg Bauhaus]

On 11/6/10 5:49 PM, Stephen Leake wrote:

> Because when you are writing a general purpose library, there is no
> specific context.
>
> A list package can be used in many different contexts. The package
> should be named Lists (or Gen_Lists if it is generic), the type should
> be named Lists.List, the subprogram arguments should be named List.

I find this description of a List type to be perfectly
listing the specifics.

> What more is there to say?

Nothing.  :-)

> Like I said, not actually solving the problem, only providing for
> endless discussion.

You said earlier that you have see a solution of a problem
to have the same value as its dissolution.

I guess, then, we should settle on different view of the
Gordian Knot and on what Alexander did using his _Type sword.

Georg

Re: _Type vs no _Type

[Shark8]

On Nov 6, 5:00 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:
> On 11/6/10 8:12 AM, Dmitry A. Kazakov wrote:
>
> > Hmm, I would expect you arguing for
>
> >     function "/" (Dividend : T; Divisor : T) return T;
>
> > For commutative operations like "+" it becomes a bit difficult:
>
> You aren't suggesting the computer-"+" is a commutative
> operation, are you?

Excepting floating point numbers; addition is commutative, isn't it?

But things get 'interesting' when they become non-commutative, like
'*' regarding matrices.

Re: _Type vs no _Type

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 11/05/2010 04:09 PM, Robert A Duff wrote:
>> Jeffrey Carter<spam.jrcarter.not@spam.not.acm.org>  writes:
>>
>>> ...Ada is a S/W-engineering
>>> language, and most developers are not S/W engineers.
>>
>> Well, maybe, but how many people will be attracted to
>> Ada by sneering at them for being less than true
>> engineers?
>
> I don't want to attract coders to Ada.

I reject your dichotomy -- S/W engineers vs. mere coders.
There's certainly a wide spectrum of competence among
programmers (why, at least half of them are below average!),
but many of whom you disparagingly call "coders" are educable.

Anyway, the more people who use a given language the
better for that language (more money to make compilers,
better compilers, more widely available for obscure
machines, more textbooks...).  That goes for incompetent
programmers just as much as the ones you prefer to call
"engineers".

By the way, one of my profs in college (Bill Wulf, maybe?)
said something about how engineering is a way to allow
mediocre people to do good work.  There's some truth in
that, but it also allows the best people to do even
better work.

>> P.S. My grandfather was a "true" engineer.  He drove a train.
>> He worked for the Pennsylvania Railroad.  ;-)
>
> Cool. Do you try to buy that when you play Monopoly?

I haven't played Monopoly in years, but yeah, I'm happy
to buy Penn RR for $200.00.  ;-)

- Bob

Re: _Type vs no _Type

[Shark8]

On Nov 6, 7:24 am, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> Shark8 <onewingedsh...@gmail.com> writes:
> > On Nov 5, 4:52 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> >> Named notation never, ever, ever makes sense for operators.
> >> And if the body of "+" is short, single-letter
> >> names are crystal clear.
>
> > Well, except in the case where you need to specify an operator that
> > might not be immediately visible.
>
> IMHO, you should never, ever, ever be in that situation.

True enough.
But sometimes you have constraints such as "must be Ada83 compilable"
or somesuch.

> Writing Foo."+"(Left => ..., Right => ...) or
> Foo."+"(..., ...) completely defeats the purpose.

Agreed.

> You should instead say "use" or "use type".

Being relatively new to Ada, I didn't know about "use type" when I ran
into the problem and used dot-qualification instead of the [otherwise-
needed] "use".

> Or if you really want the package name, then
> you shouldn't have made it an operator symbol
> in the first place.

I don't think it was in a package I'd wrote, I don't remember the
details; just that the solution pkg."+"( Left => XXX, Right YYY )
looked odd, but did what it needed.

> If I were in charge, operators would always be directly
> visible.  It's really silly that ":=" is always visible,
> but "=" is not.  

There've been a few cases where I would have liked a 'Type attribute
for variables/parameters; with such you could duplicate the GNAT-
specific Var'Img via Var'Type'Image. But maybe that's getting a little
too picky.

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Sat, 06 Nov 2010 21:52:58 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:

> On Nov 6, 5:00 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
> wrote:
>> On 11/6/10 8:12 AM, Dmitry A. Kazakov wrote:
>>
>> > Hmm, I would expect you arguing for
>>
>> >     function "/" (Dividend : T; Divisor : T) return T;
>>
>> > For commutative operations like "+" it becomes a bit difficult:
>>
>> You aren't suggesting the computer-"+" is a commutative
>> operation, are you?
>
> Excepting floating point numbers; addition is commutative, isn't it?

I would welcome an example here. Does not mean I do not believe that (I  
know floating points easily leads to trouble), just that I would like to  
understand, as I always though even with floating points, the addition is  
commutative.

What kind of addition algorithm can end into a none-commutative addition ?

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Niklas Holsti]

(see below) wrote:
> On 06/11/2010 07:12, in article g99f7vycatem$.1xtq9qp9kz0rt.dlg@40tude.net,
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> For commutative operations like "+" it becomes a bit difficult:
>>
>>    function "+" (2 * Summand : T) return T;    -- (:-))
>>
>> which BTW, illustrates another problem. The name meaningful for the client
>> is not necessarily meaningful for the implementation and conversely.
> 
> SCL, the command language for the ICL/Fujitsu VME OS, is loosely based on
> Algol 68 and has a facility to deal with this. A procedure's signature
> includes for each parameter, as well as its identifier and type, an optional
> "keyword". It is the latter that is used where Ada uses the formal parameter
> identifier, in named parameter associations. Only the formal parameter
> identifier can be used within the procedure body.

That's a nice feature. For named associations I often find that I would 
like to identify parameters with words like "with", "of", "in", that are 
reserved words in Ada and so cannot be used as parameter names. Perhaps 
such words could be allowed as "keywords" if this SCL feature were 
adopted in Ada.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Sat, 06 Nov 2010 22:20:19 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:
> Being relatively new to Ada, I didn't know about "use type" when I ran
> into the problem and used dot-qualification instead of the [otherwise-
> needed] "use".

In few words, this is a useful feature to Use all operations of a type  
without requiring to Use the whole package where it is defined and without  
(like this would be if you wanted to avoid to Use the whole package) to  
import these operations via renames clause.

if package A defines a type and some operations, if you want to invok  
these operation with using a prefix notation of many renames clause, the  
you can do a “use type”.

This is especially useful with predefined operators like “+”, “-”, when  
this way you can get ride of all of these “My_Package."+"(Left =>  
Expression_1, Right => Expression_2)”

For more details, see (Ada 2005):
http://www.adaic.org/standards/05rm/html/RM-8-4.html

But as this did not solved everything, ex. you still have to use a prefix  
to refer to enumeration items as an example, the “use type” has been  
extended in Ada 2012, with a “use all type”, which import every thing of a  
type, no more restricted to its operations.

For more details, see (Ada 2012):
http://www.ada-auth.org/standards/12rm/html/RM-8-4.html

And also if you are inquisitive:
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0150-1.txt?rev=1.8
> There have been complaints that a use type clause does not make
> enough things visible (e.g. enumeration literals, classwide operations
> for tagged types), whereas a use_package_clause makes too much visible.
> Something in between is wanted.

By the way: do someone know why the Ada LRM 2012 has moved from AdaIC to  
Ada-Auth ?


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Sat, 06 Nov 2010 23:08:22 +0100, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
>>  SCL, the command language for the ICL/Fujitsu VME OS, is loosely based  
>> on
>> Algol 68 and has a facility to deal with this. A procedure's signature
>> includes for each parameter, as well as its identifier and type, an  
>> optional
>> "keyword". It is the latter that is used where Ada uses the formal  
>> parameter
>> identifier, in named parameter associations. Only the formal parameter
>> identifier can be used within the procedure body.
>
> That's a nice feature. For named associations I often find that I would  
> like to identify parameters with words like "with", "of", "in", that are  
> reserved words in Ada and so cannot be used as parameter names. Perhaps  
> such words could be allowed as "keywords" if this SCL feature were  
> adopted in Ada.

Got my Vote too!


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Brian Drummond]

On Sat, 06 Nov 2010 17:10:11 -0400, Robert A Duff <bobduff@shell01.TheWorld.com>
wrote:

>Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
>
>> On 11/05/2010 04:09 PM, Robert A Duff wrote:
>>> Jeffrey Carter<spam.jrcarter.not@spam.not.acm.org>  writes:
>>>
>>>> ...Ada is a S/W-engineering
>>>> language, and most developers are not S/W engineers.
>>>
>>> Well, maybe, but how many people will be attracted to
>>> Ada by sneering at them for being less than true
>>> engineers?
>>
>> I don't want to attract coders to Ada.
>
>I reject your dichotomy -- S/W engineers vs. mere coders.
>There's certainly a wide spectrum of competence among
>programmers (why, at least half of them are below average!),
>but many of whom you disparagingly call "coders" are educable.

Let me echo my agreement on this.

I was educated on Algol-W and transitioned to Modula-2 in the 1980s, via another
of Wirth's languages.. (Ada was not really "available" at the time.) 

More recently I have been using C and C++, but I do not consider I have ever
really learned them, and during those years I definitely lapsed into "coding".
Doing what was expedient, knowing it wasn't good, and feeling encouraged by the
language to do so (or sometimes, punished when I tried to do better!)

Coming to Ada has been - not so much learning (yet, though there are parts of
the language I haven't touched yet) as healing. I'm starting to think I may be
on the road back to SW engineering. 

(Interestingly enough, it's also having an effect, probably positive, on the C++
I still have to write)

- Brian 

Re: _Type vs no _Type

[Shark8]

On Nov 6, 3:58 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> > Excepting floating point numbers; addition is commutative, isn't it?
>
> I would welcome an example here. Does not mean I do not believe that (I  
> know floating points easily leads to trouble), just that I would like to  
> understand, as I always though even with floating points, the addition is  
> commutative.

The general way to show the non-commutativity of floating-point would
be
something like the initialization of the number to something large,
say
a hundred-million, and some repetitive additions of some small number
say a hundred-thousand hundred-thousandths, so that what you would
expect
mathematically would be a hundred-million and one would actually have
the
value one hundred million.

The reason for this is that the "largeness" of the floating point
number
at the start causes all the small values to be dropped so that after
the
addition you are left with the large number itself.

Whereas if you were to reverse the order of the additions; initialize
to
zero and do the repeated additions of the smaller number followed by
the
large number you are likely to get the correct result.

I've heard someone tell a story where they had to disable optimization
on
their compiler because it was changing the order of operations for a
floating-point number and giving results as described.

>
> What kind of addition algorithm can end into a none-commutative addition ?
>

http://en.wikipedia.org/wiki/Quaternion
These are non-communative on multipclation and are, basically, to the
complex-numbers what the complex-numbers are to real numbers.

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Sun, 07 Nov 2010 03:57:33 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:

> On Nov 6, 3:58 pm, Yannick Duchêne (Hibou57)
> <yannick_duch...@yahoo.fr> wrote:
>> > Excepting floating point numbers; addition is commutative, isn't it?
>>
>> I would welcome an example here. Does not mean I do not believe that (I  
>>  know floating points easily leads to trouble), just that I would like  
>> to understand, as I always though even with floating points, the  
>> addition is commutative.
>
> The general way to show the non-commutativity of floating-point would
> be
> something like the initialization of the number to something large,
> say
> a hundred-million, and some repetitive additions of some small number
> say a hundred-thousand hundred-thousandths, so that what you would
> expect
> mathematically would be a hundred-million and one would actually have
> the
> value one hundred million.
OK, this was about iteration. Yes, I know the case of iterations.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[J-P. Rosen]

Le 07/11/2010 03:57, Shark8 a �crit :
> The general way to show the non-commutativity of floating-point would
> be something like the initialization of the number to something large,
> say a hundred-million, and some repetitive additions of some small number
> say a hundred-thousand hundred-thousandths, so that what you would expect
> mathematically would be a hundred-million and one would actually have
> the value one hundred million.
> 
This has nothing to do with commutativity, but with associativity. For
sure, floating-point addition is not associative, but can you give an
example of non commutativity?
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: _Type vs no _Type

[Jeffrey Carter]

On 11/06/2010 02:10 PM, Robert A Duff wrote:
>
> Anyway, the more people who use a given language the
> better for that language (more money to make compilers,
> better compilers, more widely available for obscure
> machines, more textbooks...).  That goes for incompetent
> programmers just as much as the ones you prefer to call
> "engineers".

Use, yes. That doesn't necessarily require attracting coders to the language. 
Just as construction workers have to use the materials chosen by the civil 
engineer, coders should have to use the language chosen by the S/W engineer. So 
the use could increase without coders wanting to use the language.

-- 
Jeff Carter
"If you don't get the President of the United States on that
phone, ... you're going to have to answer to the Coca-Cola
Company."
Dr. Strangelove
32

Re: _Type vs no _Type

[Yannick Duchêne (Hibou57)]

Le Sun, 07 Nov 2010 21:41:57 +0100, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:
> Use, yes. That doesn't necessarily require attracting coders to the  
> language. Just as construction workers have to use the materials chosen  
> by the civil engineer, coders should have to use the language chosen by  
> the S/W engineer. So the use could increase without coders wanting to  
> use the language.
Yes, but you know bosses and managers, have some management and decision  
theories, and one of these, states a good strategy is to follow the crowd  
so that they will be sure to never be held responsible for anything: “I  
did nothing wrong, made no wrong decision, see you self, every one was  
thinking the same at that time! I am not responsible!” [Any resemblance to  
persons living or dead is purely coincidental (TM)].

Off-topic for people who read french: je les appelle “les responsables de  
toucher la paie” (cheese). End of Off-topic.

Seriously, while I enjoy Ada, one thing I bother about, is that there is  
even no real Ada competitor. I believe Ada is not the only one of the like  
which could exist and some other ways as good as this one may be possible.  
We would have more interesting comparison basis, talks and others. This  
would be fine to have a serious Ada competitor, the culture in that area  
would be richer, with even more interesting talks.

TBH: a target language is not the only topic, but we are precisely talking  
about this here.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: _Type vs no _Type

[Warren]

Brian Drummond expounded in news:g039d6tdnaoh335goqkb2q8qe8bl6dbc79@
4ax.com:

> On Fri, 5 Nov 2010 20:45:07 +0000 (UTC), Warren <ve3wwg@gmail.com> 
wrote:
> 
>>Florian Weimer expounded in news:87iq0bef71.fsf@mid.deneb.enyo.de:
>>
>>> * Jeffrey Carter:
>>> 
>>>> Personally, I think allowing non-English identifiers in a language
>>>> with English reserved words is a mistake.
>>> 
>>> "English" or "ASCII"?
>>
>>I am fluent in ASCII. ACK?
> 
> I'm sure I've forgotten the code for ACK, but control-G rings a bell...
> 
> - Brian

That's a favourite for sure.

Warren

Re: _Type vs no _Type

[Warren]

Florian Weimer expounded in news:87eib06yir.fsf@mid.deneb.enyo.de:

> * Britt Snodgrass:
> 
>> The language design decision that Ada be case insensitive is something
>> that I value very much.  In general, I think the "flexibility"
>> provided by case sensitivity causes more problems (risks, bugs,
>> reduced readability) than it potentially solves.
> 
> And with case insensitivity, we have a seemingly neverending
> collection of warts, bugs and incompatibilities in the Ada language.

Even though C/C++ has case sensitivity, I don't think this is
actually exploited much in practice.  Even C programmers don't
really like the idea of "My_Handle" and "my_handle" meaning 
different things.

A lot of things get underscores added/prefixed/doubled for
uniqueness. Uppercased items tend to be avoided as they
tend to be used for manifest constants and macros. Of course
Ada forbids leading and trailing underscores, which I like
(I hate the C/C++ use of these).

Then there's windows: MyFile vs my_file etc. Even there, you
won't usually find case distinctions like MyFile vs myfile,
mYfILE, myfile etc. "my_file" is more likely if a distinction
must be used.

Type names often use the _t suffix convention, to avoid
conflicts with instances of those types.

So after all is said and done, even in C/C++, case distinctions
tend to be a lot less significant in practice than you might
think. I think Ada made the right choice.

Warren

Re: Beginners question: Compound types, how-to?

[Randy Brukardt]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:4cd27fb2$0$7658$9b4e6d93@newsspool1.arcor-online.net...
> On 11/4/10 6:23 AM, Stephen Leake wrote:
>
> Why is it that the "_type"  camp is so consistently silent
> about giving specific contexts of what are just programming
> examples?

Because most of the time it isn't worth a lot of effort to "find a better 
name". The majority of names in my programs are for local variables that are 
used in very small contexts. Spending 15 minutes to find a good name (and 
that isn't unusual when it comes to naming; ARG discussions on naming often 
go longer than that...) is simply not worth it for temporaries, loop 
parameters and the like. Moreover, mechanically adding a "Temp_" prefix just 
to avoid adding a "_Type" doesn't exactly help anything.

The time when lots of effort in naming is important is when the names will 
have long life and wide visibility, as when designing reusable libraries. We 
in fact did spend quite a bit of time when design Claw in determining the 
naming conventions. These require at least:
   (1) Consistency and predicability -- users need to be able to predict the 
names of entities without referring to the manual or specification (once 
they are familar with the layout). Similarly, programmers of new Claw 
packages need to be able to figure out the names needed more-or-less 
mechanically.
   (2) Works for the use-adverse -- The naming needs to work for the 
use-adverse, so the names have to be reasonably short.
   (3) Works for the use-lovers -- The names needs to work for people using 
lots of use-clauses, so the names of types and objects need to be reasonably 
unique.
   (4) Clients should have maximum flexibility in names of objects and 
parameters -- as these are the most important in terms of readability.

In the end, we adopted "_Type" (as in "Root_Window_Type", "Button_Type", 
etc.); thus parameters are generally "Button : Button_Type". It seemed that 
some such prefix or suffix is needed in order to meet (1); using a fixed 
name like "Object" fails (3); and nothing else would be consistent. 
Subprogram identifiers are kept very short (they don't repeat any type 
information, thus "Create" rather than "Create_Button" -- use named notation 
if you need type information: "Create (Button => ...").

Note that Ada.Containers has similar requirements and ended up using similar 
solutions.

                                  Randy.

Re: Beginners question: Compound types, how-to?

[Jeffrey Carter]

On 11/12/2010 01:17 PM, Randy Brukardt wrote:
>
>     (3) Works for the use-lovers -- The names needs to work for people using
> lots of use-clauses, so the names of types and objects need to be reasonably
> unique.

The idea that unique identifiers are needed to cater to the use-addicted is 
false. They can always write P.Non_Unique_Name.

-- 
Jeff Carter
"This scene's supposed to be in a saloon, but
the censor cut it out. It'll play just as well
this way." [in a soda fountain]
Never Give a Sucker an Even Break
113

Re: _Type vs no _Type

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.vlrrycf2ule2fv@garhos...
>By the way: do someone know why the Ada LRM 2012 has moved from AdaIC to 
>Ada-Auth ?

Sure: there is a new AdaIC site under development; it won't be my 
responsiblity any more, so things that I need to update frequently have been 
moved to Ada-Auth. (The same was done with the ACATS.)

                         Randy.