> One reason to use "_Type" is precisely _because_ it means "Ada type"; > there's no need to wonder about what it means.
But the language meaning of "type" does not help with the mentioned Message_Type_Type? If I stubbornly follow your conventions as I understand them, I'd have to write
procedure Something (Message_Type : in Message_Type_Type); or procedure Something (Message_Type : in Message_Types.Message_Type);
wouldn't I? (I speculate that one could add a remark about first class type objects here, as per Dmitry's suggestion. More confusion.)
>>>>>> Cf. valid Eiffel:
>>>>>> local >>>>>> string: STRING >>>>>> do >>>>>> ... -- more uses of string and STRING. Or StrINg. >>> Ah; Eiffel has separate type and object name >>> spaces. So I don't understand the original example; what was the >>> point?
>> In a dozen or so lines of subprogram text, the sequence of >> characters "String" can refer to two different concepts, in Eiffel, >> when you have declared string : STRING, an object and a type.
> So the case is not important; why did you introduce it?
The "String : String" part of the declaration means -object-named-String- : -type-named-String- in Eiffel. The very same word names both the object and the type. Characters case is important to the reader, however (you have mentioned GNAT's warnings). The writer may like to use case distinction to "disambiguate" the same sequence of letters. That's fine as long as you live in a single universe of formal names, like when you are working on the same set of Ada programs for months, and never need to look elsewhere.
> In another post, someone said Eiffel required<> around types; is that > not true?
I mentioned Dylan where you would write string : <string>; In Eiffel, and in hypothetical 2-namespace-Ada you write STring: STring, if you want to. The visual difference is none. Is the difference in meaning perfectly clear in the body lines following the declaration?
> The point, as always in this discussion, is to save time making up > separate names for types and objects.
>>> Yes, this is an example of name overloading. Overloading, like any >>> good thing, can be abused.
>> Assuming separate namespaces for objects and types, >> I can imagine programmers who find "string : STRING" >> very clever. Or just a good match for some twisted programming >> trick. Why make cleverness, or the appearance thereof, >> easy to achieve?
> Good programmers will just find it natural; why introduce twisted > programmers into this?
OK, I thought that the design of a general purpose programming language, together with the naming conventions surrounding it, should be manageable by a general public of programmers, not just "programmers who find this natural" =:def "good programmers". Some good programmers, in fact language makers, have made String : String impossible. Supposedly, then, they did not deem String : String a natural thing, even though they were good programmers.
Here is an analogous example. The argument (be a better programmer if you want to use our language properly) is popular. Whenever I had the courage to mention that there are sharp corners in C and that, therefore, we should be expecting these corners to cause trouble, I heard it: programmers causing trouble in C programs lack education! Well... Proof of trouble is the weekly CVE report about C programs and the type "int". That's am empirical fact. QED.
Is it an empirical fact that most programmers lack education? Or does C have some dangerous imperfections? The typical response is a exaggeration of your question: Why count stupid non-C-knowing less than excellent programmers in the select set of programmers-finding-C-natural who know by heart the C standard and the compiler documentation? ("Because we live on planet earth!" is what I think, then. "A language, or a naming convention, should respect this fact.")
Before turning back to Ada and naming conventions, let me stress the analogy, regarding Ada programmer skills. What about C programmers who are writing programs even though they don't know every detail about C's "int"? They are writing programs controlling machines that affect our daily lives. Should they not? Should we shape a language and conventions around the idea that "int" is fine in the hands of brilliant programmers and that other programmers should seek different occupations? In any case, the above speakers will not accept the group of normal programmers as a premise; mostly because doing so will show C's imperfections when in the hands of imperfect programmers, *to* *a* *degree* that is largely caused by C---it could be less (which is why Cyclone is different, I should think). Those speaking in favor of C's "idiosyncrasies" like "int" deny the normal situation of imperfect programming... This is why I am skeptical of naming conventions that need twisted knowledge, like List : in out List.
My claim is that if Ada allows List : in out List, then there will be a growing number of programmers who "save time making up separate names" and routinely use T : T. To support this claim, I think I can point at another time saver: Anonymous "access" was introduced with Ada 2005. People like it. One reason is that it saves time making up pointer type names. (Viz. why, instead of declaring pointer types, not just add Foo* and &Bar like we are used to? Of course, I meant "X : access Foo;" and "Bar'Unchecked_Access"? Easy. Saves time.)
IMO, the effect of naming conventions is first and foremost an effect on human Ada programmers, caused by human programmers. The language definition will influence naming conventions, but this is accidental.
>>>>>>> local >>>>>>> string: STRING >>>>>>> do >>>>>>> ... -- more uses of string and STRING. Or StrINg. >>>> Ah; Eiffel has separate type and object name >>>> spaces. So I don't understand the original example; what was the >>>> point?
>>> In a dozen or so lines of subprogram text, the sequence of >>> characters "String" can refer to two different concepts, in Eiffel, >>> when you have declared string : STRING, an object and a type.
>> So the case is not important; why did you introduce it?
> The "String : String" part of the declaration means > -object-named-String- : -type-named-String- > in Eiffel. The very same word names both the > object and the type. Characters case is important to the > reader, however (you have mentioned GNAT's warnings). > The writer may like to use case distinction to "disambiguate" > the same sequence of letters. That's fine as long as you
will be
> live in a single universe of formal names, like when you are > working on the same set of Ada programs for months, and
Ada-with-two-namespace
> never need to look elsewhere.
and [Ss][Tt][Rr][Ii][Nn][Gg]'s meaning is easily seen from immediate context.
Georg Bauhaus <rm-host.bauh...@maps.futureapps.de> writes: > On 11/7/09 6:49 AM, Stephen Leake wrote:
>> One reason to use "_Type" is precisely _because_ it means "Ada type"; >> there's no need to wonder about what it means.
> But the language meaning of "type" does not help with > the mentioned Message_Type_Type? > If I stubbornly follow your conventions as I understand them, > I'd have to write
> procedure Something (Message_Type : in Message_Type_Type); > or > procedure Something (Message_Type : in Message_Types.Message_Type);
> wouldn't I?
Yes. This is the only special case, and usually I just stubbornly follow the convention. You get used to it.
Another choice is to use Message_Label instead;
procedure Something (Message_Label : in Message_Label_Type);
>> In another post, someone said Eiffel required<> around types; is that >> not true?
> I mentioned Dylan where you would write string : <string>;
Ah, sorry for the confusion.
> In Eiffel, and in hypothetical 2-namespace-Ada you write STring: > STring, if you want to. The visual difference is none. Is the > difference in meaning perfectly clear in the body lines following > the declaration?
No, there are times when either an object or a type could be used, in attributes. Which is probably why Ada has a single namespace.
>>>> Yes, this is an example of name overloading. Overloading, like any >>>> good thing, can be abused.
>>> Assuming separate namespaces for objects and types, >>> I can imagine programmers who find "string : STRING" >>> very clever. Or just a good match for some twisted programming >>> trick. Why make cleverness, or the appearance thereof, >>> easy to achieve?
>> Good programmers will just find it natural; why introduce twisted >> programmers into this?
> OK, I thought that the design of a general purpose programming > language, together with the naming conventions surrounding it, > should be manageable by a general public of programmers, not just > "programmers who find this natural" =:def "good programmers". > Some good programmers, in fact language makers, > have made String : String impossible.
Yes, for good reasons.
> Supposedly, then, they did not deem String : String a natural thing, > even though they were good programmers.
That's a stretch! Avoiding actual ambiguities is a better reason. But I don't presume to read their minds. It would be interesting to read some rationale on this; I don't think there is any in the Ada Language Manual.
> Before turning back to Ada and naming conventions, let me > stress the analogy, regarding Ada programmer skills. > What about C programmers who are writing programs even > though they don't know every detail about C's "int"?
They are undereducated programmers, by definition.
> They are writing programs controlling machines that affect our daily > lives. Should they not?
They should not.
> Should we shape a language and conventions around the idea that > "int" is fine in the hands of brilliant programmers and that other > programmers should seek different occupations?
No, we should shape languages that are easy to learn.
> In any case, the above speakers will not accept the group of normal > programmers as a premise; mostly because doing so will show C's > imperfections when in the hands of imperfect programmers, *to* *a* > *degree* that is largely caused by C---it could be less (which is > why Cyclone is different, I should think).
And why Ada is different.
> Those speaking in favor of C's "idiosyncrasies" like "int" deny the > normal situation of imperfect programming...
I don't know how "normal" it is to be programming in C and not understand "int". I would hope it is not common at all!
> This is why I am skeptical of naming conventions that need twisted > knowledge, like List : in out List.
I deny that this is "twisted"; that was the point of my response.
It makes perfect sense in English; we often use the same word to refer to an item or a group. More commonly we use a plural form, but often the plural form is the same as the singular. "List : Container" is no better and no worse in English.
> My claim is that if Ada allows List : in out List, then there > will be a growing number of programmers who "save time making > up separate names" and routinely use T : T.
Yes! Then we will have more time for other things, like coming up with good names for the other parameters.
You seem to be implying that this is a bad thing; what, exactly, is the downside?
> To support this claim, I think I can point at another time saver: > Anonymous "access" was introduced with Ada 2005. People like it. One > reason is that it saves time making up pointer type names. (Viz. > why, instead of declaring pointer types, not just add Foo* and &Bar > like we are used to? Of course, I meant "X : access Foo;" and > "Bar'Unchecked_Access"? Easy. Saves time.)
'Unchecked_Access is _not_ the same as as 'Access. Introducing bogus arguments is not a good arguing tactic.
What is your point here? You seem to be implying that anonymous access types are bad, but you don't say so. I disagree that they are bad.
> IMO, the effect of naming conventions is first and foremost an > effect on human Ada programmers, caused by human programmers. > The language definition will influence naming conventions, > but this is accidental.
Yes, no one has said otherwise.
In this case, the fact that the language design has a single namespace for objects and types leads to the need for a convention to distinguish the two.
I argue for a simple mechanical convention; append _type to type names.
Others argue for a complex time-consuming convention; come up with different names.
Others also argue that types and objects should have names that differ by more than a suffix for other reasons. Several attempts have been made to explain those other reasons; as I understand it, they all come down to this:
Names should convey as much information as possible, thus they should be domain-specific whenever possible. Thus the natural names for objects and types are different in many situations.
To which the reply is:
When the domain is very general, very general names are appropriate, and the natural object and type names are the same. Then _Type (or some similar noise) is necessary.
One could then suggest a relaxed convention:
Append _Type if the type name is very general, use a domain-specific name otherwise.
I never seriously considered the latter; it involves deciding whether a name is "very general", which is even harder than coming up with different names. It's far easier to just use _Type.
Also, I prefer writing reusable code, which tends to be domain-independent. If I'm working on robots, and I need a vector math package to compute the robot positions, I don't call it robot_position_vectors, I call it vectors. And it's generic in the floating point type, which is just named Real_Type, not Meters, or Radians, or Positions.
Concrete objects in the robot code are call Pos_Joint_n, Pos_Tool, etc. Parameters to subprograms tend to have more generic names.
>>>>> So we have to add noise to either the object or the type, to keep the >>>>> compiler happy. That's all there is to it.
>>>> That is not necessary:
>>>> package sdgfkjasf is -- or whayever
>>>> type List is ...
>>>> procedure jsdfks (List : sdgfkjasf.List);
>>>> ...
>>> That's the first time I've seen that suggestion.
>> Or maybe you forgot!
> Always possible.
>> The following is part of a old discusion to which you contributed:
> <snip>
> I don't see your point; that old discussion does _not_ propose using > <package>.<type> to resolve the ambiguity.
My point was to show that my mentioning using <package>.<type> to resolve ambiguity nicely in my first message was actually not the first time that it was mentioned (ever if not explicitely) in c.l.a. I probably expected that seeing that simple example would be enough to cause a mental "click" regarding some benifits of that construction.
No big deal, as long as there may now be at least one less "_Type" writer. ;)
(Note that I wrote alittle more in one of your other messages in the thread regarding original Ada rationale.)
> Georg Bauhaus <rm-host.bauh...@maps.futureapps.de> writes:
>> On 11/7/09 6:49 AM, Stephen Leake wrote:
>>> One reason to use "_Type" is precisely _because_ it means "Ada type"; >>> there's no need to wonder about what it means.
>> But the language meaning of "type" does not help with >> the mentioned Message_Type_Type? >> If I stubbornly follow your conventions as I understand them, >> I'd have to write
>> procedure Something (Message_Type : in Message_Type_Type); >> or >> procedure Something (Message_Type : in Message_Types.Message_Type);
>> wouldn't I?
> Yes. This is the only special case, and usually I just stubbornly > follow the convention. You get used to it.
> Another choice is to use Message_Label instead;
> procedure Something (Message_Label : in Message_Label_Type);
>>> In another post, someone said Eiffel required<> around types; is that >>> not true?
>> I mentioned Dylan where you would write string : <string>;
> Ah, sorry for the confusion.
>> In Eiffel, and in hypothetical 2-namespace-Ada you write STring: >> STring, if you want to. The visual difference is none. Is the >> difference in meaning perfectly clear in the body lines following >> the declaration?
> No, there are times when either an object or a type could be used, in > attributes. Which is probably why Ada has a single namespace.
>>>>> Yes, this is an example of name overloading. Overloading, like any >>>>> good thing, can be abused.
>>>> Assuming separate namespaces for objects and types, >>>> I can imagine programmers who find "string : STRING" >>>> very clever. Or just a good match for some twisted programming >>>> trick. Why make cleverness, or the appearance thereof, >>>> easy to achieve?
>>> Good programmers will just find it natural; why introduce twisted >>> programmers into this?
>> OK, I thought that the design of a general purpose programming >> language, together with the naming conventions surrounding it, >> should be manageable by a general public of programmers, not just >> "programmers who find this natural" =:def "good programmers". >> Some good programmers, in fact language makers, >> have made String : String impossible.
> Yes, for good reasons.
>> Supposedly, then, they did not deem String : String a natural thing, >> even though they were good programmers.
> That's a stretch! Avoiding actual ambiguities is a better reason. But > I don't presume to read their minds. It would be interesting to read > some rationale on this; I don't think there is any in the Ada Language > Manual.
What I gathered was that the original chief language designer constructed the language rules with a goal of trying to drive/impose the necessity of "good" program architecture and trying to prevent/discourage "bad" program architecture and I think that the following was one of the things that was to be promoted:
- separating (having in different packages) the declaration of types (abstract data types) and object of the type.
I think that having two namespaces would have made having both in the same declarative region easier but that would only really come up for the type and only one object (or as a yucky "workaround") an array of them) declared together. Clearly, whenever there are two objects of the type, the simple name of one of them _must_ be different than the name of the type unless they are in different declarative regions. I think that separate object and type namespaces would simply have been redundant.
Also, I showed that the "parameter of subprogram declaration" case (which was the old example that I brought up in an earlier message) is easily and elegantly dealt with by the sjkdf.type_name construct So, that there is really no need for two namespaces but there also is really is no need for any overall naming convention either!
As to why there is "File_Type" in Text_IO instead of various Sub(File:Text_IO.File) declarations, I'd for a couple of reasons) say it was just a "mistake" due to expediency. My reasons are: (1) The big text_IO package was not part of the original language, it was added (relatively quickly?) in order to reduce the amount of generic instantiations that would be required to do simple io. (2) The original chief designer afterward acknowlegded/commented that he thought that even having text_io depend on the predefined "integer" was a mistake.
With all of that I am not trying to be be "diffinative" in any way, I'm just putting out what I remember and (though about) from earily on at the start of my use of Ada.
I hope that at least some of what I wrote is at all useful (and that none of it is inacurate!)
"Vincent Marciante" <vmarcia...@decilog.com> writes: >>>> That's the first time I've seen that suggestion.
>>> Or maybe you forgot!
>> Always possible.
>>> The following is part of a old discusion to which you contributed:
>> <snip>
>> I don't see your point; that old discussion does _not_ propose using >> <package>.<type> to resolve the ambiguity.
> My point was to show that my mentioning using > <package>.<type> to resolve ambiguity nicely > in my first message was actually not the first > time that it was mentioned (ever if not explicitely) > in c.l.a.
I still don't get it. If it was not mentioned explicitly, how was it mentioned? If I had seen that suggestion before, I might be using it now.
> No big deal, as long as there may now be at least > one less "_Type" writer. ;)
"Vincent Marciante" <vmarcia...@decilog.com> writes: >>> Supposedly, then, they did not deem String : String a natural thing, >>> even though they were good programmers.
>> That's a stretch! Avoiding actual ambiguities is a better reason. But >> I don't presume to read their minds. It would be interesting to read >> some rationale on this; I don't think there is any in the Ada Language >> Manual.
> What I gathered was that the original chief language > designer constructed the language rules with a goal > of trying to drive/impose the necessity of "good" > program architecture and trying to prevent/discourage > "bad" program architecture and I think that the following > was one of the things that was to be promoted:
> - separating (having in different packages) the declaration > of types (abstract data types) and object of the type.
Maybe, but we are also talking about subprogram parameters, which are in the same package.
And there are certainly valid use cases for local types, especially subtypes.
> I think that having two namespaces would have made > having both in the same declarative region easier
Not much, it just would have avoided _Type.
> but that would only really come up for the type > and only one object (or as a yucky "workaround") > an array of them) declared together. Clearly, whenever > there are two objects of the type, the simple name > of one of them _must_ be different than the name of > the type unless they are in different declarative > regions.
Again, not true for subprogram parameters; there are many (one per subprogram) with the same name. I guess the subprogram parameter list can be thought of as a separate declarative region; I'm not sure it is formally.
> Also, I showed that the "parameter of subprogram > declaration" case (which was the old example that > I brought up in an earlier message) is easily and > elegantly dealt with by the sjkdf.type_name construct
Yes.
> So, that there is really no need for two namespaces but there also > is really is no need for any overall naming convention either!
No, there is still a need for a convention; people need to know how to react to the compiler error message. You are proposing that the convention be "add enough of the full name of the type to disambiguate". Which is also the convention for resolving other name ambiguities (rather than changing one).
>>>>> That's the first time I've seen that suggestion.
>>>> Or maybe you forgot!
>>> Always possible.
>>>> The following is part of a old discusion to which you contributed:
>>> <snip>
>>> I don't see your point; that old discussion does _not_ propose using >>> <package>.<type> to resolve the ambiguity.
>> My point was to show that my mentioning using >> <package>.<type> to resolve ambiguity nicely >> in my first message was actually not the first >> time that it was mentioned (ever if not explicitely) >> in c.l.a.
> I still don't get it. If it was not mentioned explicitly, how was it > mentioned? If I had seen that suggestion before, I might be using it > now. >> No big deal, as long as there may now be at least >> one less "_Type" writer. ;)
> Not likely, after 15 years of habit forming.
I just reread all of the old thread and see exactly what was previously discussed. How about lets just leave it at this:
Ada _does_ allow one to name an object with the same simple name as that of its type as long as the type is in a different declarative region. Also, (obviously only) one subprogram parameter can also share the same simple name as its type as long as the type name is fully qualified. Given that, adding noise characters to a type name or a object name is not scrictly necessary.
|
