* Beginners question: Compound types, how-to? @ 2010-10-31 22:00 Mart van de Wege 2010-10-31 22:36 ` Vinzent Hoefler ` (2 more replies) 0 siblings, 3 replies; 190+ messages in thread From: Mart van de Wege @ 2010-10-31 22:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-10-31 22:00 Beginners question: Compound types, how-to? Mart van de Wege @ 2010-10-31 22:36 ` Vinzent Hoefler 2010-10-31 23:27 ` Yannick Duchêne (Hibou57) 2010-11-01 3:55 ` Jeffrey Carter 2010-11-01 12:03 ` Brian Drummond 2 siblings, 1 reply; 190+ messages in thread From: Vinzent Hoefler @ 2010-10-31 22:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-10-31 22:36 ` Vinzent Hoefler @ 2010-10-31 23:27 ` Yannick Duchêne (Hibou57) 2010-11-01 7:14 ` Mart van de Wege 2010-11-02 9:38 ` J-P. Rosen 0 siblings, 2 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-10-31 23:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-10-31 23:27 ` Yannick Duchêne (Hibou57) @ 2010-11-01 7:14 ` Mart van de Wege 2010-11-01 19:22 ` Jeffrey Carter 2010-11-02 9:38 ` J-P. Rosen 1 sibling, 1 reply; 190+ messages in thread From: Mart van de Wege @ 2010-11-01 7:14 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 7:14 ` Mart van de Wege @ 2010-11-01 19:22 ` Jeffrey Carter 0 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-01 19:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-10-31 23:27 ` Yannick Duchêne (Hibou57) 2010-11-01 7:14 ` Mart van de Wege @ 2010-11-02 9:38 ` J-P. Rosen 1 sibling, 0 replies; 190+ messages in thread From: J-P. Rosen @ 2010-11-02 9:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-10-31 22:00 Beginners question: Compound types, how-to? Mart van de Wege 2010-10-31 22:36 ` Vinzent Hoefler @ 2010-11-01 3:55 ` Jeffrey Carter 2010-11-01 7:12 ` Mart van de Wege 2010-11-01 11:50 ` (see below) 2010-11-01 12:03 ` Brian Drummond 2 siblings, 2 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-01 3:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 3:55 ` Jeffrey Carter @ 2010-11-01 7:12 ` Mart van de Wege 2010-11-01 15:04 ` Shark8 ` (2 more replies) 2010-11-01 11:50 ` (see below) 1 sibling, 3 replies; 190+ messages in thread From: Mart van de Wege @ 2010-11-01 7:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 7:12 ` Mart van de Wege @ 2010-11-01 15:04 ` Shark8 2010-11-01 17:06 ` Mart van de Wege 2010-11-01 17:24 ` Yannick Duchêne (Hibou57) 2010-11-01 19:05 ` Jeffrey Carter 2 siblings, 1 reply; 190+ messages in thread From: Shark8 @ 2010-11-01 15:04 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 15:04 ` Shark8 @ 2010-11-01 17:06 ` Mart van de Wege 2010-11-01 17:39 ` Yannick Duchêne (Hibou57) 2010-11-01 19:19 ` Jeffrey Carter 0 siblings, 2 replies; 190+ messages in thread From: Mart van de Wege @ 2010-11-01 17:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:06 ` Mart van de Wege @ 2010-11-01 17:39 ` Yannick Duchêne (Hibou57) 2010-11-01 17:58 ` Mart van de Wege 2010-11-01 19:19 ` Jeffrey Carter 1 sibling, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 17:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:39 ` Yannick Duchêne (Hibou57) @ 2010-11-01 17:58 ` Mart van de Wege 0 siblings, 0 replies; 190+ messages in thread From: Mart van de Wege @ 2010-11-01 17:58 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:06 ` Mart van de Wege 2010-11-01 17:39 ` Yannick Duchêne (Hibou57) @ 2010-11-01 19:19 ` Jeffrey Carter 2010-11-01 19:41 ` Yannick Duchêne (Hibou57) ` (3 more replies) 1 sibling, 4 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-01 19:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:19 ` Jeffrey Carter @ 2010-11-01 19:41 ` Yannick Duchêne (Hibou57) 2010-11-01 20:56 ` Jeffrey Carter 2010-11-03 16:56 ` Warren 2010-11-01 19:59 ` Shark8 ` (2 subsequent siblings) 3 siblings, 2 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 19:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:41 ` Yannick Duchêne (Hibou57) @ 2010-11-01 20:56 ` Jeffrey Carter 2010-11-01 21:05 ` Yannick Duchêne (Hibou57) 2010-11-03 16:56 ` Warren 1 sibling, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-01 20:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 20:56 ` Jeffrey Carter @ 2010-11-01 21:05 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 21:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:41 ` Yannick Duchêne (Hibou57) 2010-11-01 20:56 ` Jeffrey Carter @ 2010-11-03 16:56 ` Warren 2010-11-03 17:01 ` Georg Bauhaus 1 sibling, 1 reply; 190+ messages in thread From: Warren @ 2010-11-03 16:56 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 16:56 ` Warren @ 2010-11-03 17:01 ` Georg Bauhaus 2010-11-03 17:42 ` Vinzent Hoefler ` (2 more replies) 0 siblings, 3 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 17:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 17:01 ` Georg Bauhaus @ 2010-11-03 17:42 ` Vinzent Hoefler 2010-11-04 5:23 ` Stephen Leake 2010-11-03 20:38 ` Warren 2010-11-03 20:44 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 190+ messages in thread From: Vinzent Hoefler @ 2010-11-03 17:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 17:42 ` Vinzent Hoefler @ 2010-11-04 5:23 ` Stephen Leake 2010-11-04 9:41 ` Georg Bauhaus ` (2 more replies) 0 siblings, 3 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-04 5:23 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 5:23 ` Stephen Leake @ 2010-11-04 9:41 ` Georg Bauhaus 2010-11-06 16:49 ` Stephen Leake 2010-11-12 20:17 ` Randy Brukardt 2010-11-04 10:09 ` Georg Bauhaus 2010-11-04 17:46 ` Jeffrey Carter 2 siblings, 2 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-04 9:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 9:41 ` Georg Bauhaus @ 2010-11-06 16:49 ` Stephen Leake 2010-11-06 18:43 ` Jeffrey Carter 2010-11-06 19:35 ` Georg Bauhaus 2010-11-12 20:17 ` Randy Brukardt 1 sibling, 2 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-06 16:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-06 16:49 ` Stephen Leake @ 2010-11-06 18:43 ` Jeffrey Carter 2010-11-06 19:35 ` Georg Bauhaus 1 sibling, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-06 18:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-06 16:49 ` Stephen Leake 2010-11-06 18:43 ` Jeffrey Carter @ 2010-11-06 19:35 ` Georg Bauhaus 1 sibling, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-06 19:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 9:41 ` Georg Bauhaus 2010-11-06 16:49 ` Stephen Leake @ 2010-11-12 20:17 ` Randy Brukardt 2010-11-12 21:25 ` Jeffrey Carter 1 sibling, 1 reply; 190+ messages in thread From: Randy Brukardt @ 2010-11-12 20:17 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-12 20:17 ` Randy Brukardt @ 2010-11-12 21:25 ` Jeffrey Carter 0 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-12 21:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 5:23 ` Stephen Leake 2010-11-04 9:41 ` Georg Bauhaus @ 2010-11-04 10:09 ` Georg Bauhaus 2010-11-06 16:53 ` Stephen Leake 2010-11-04 17:46 ` Jeffrey Carter 2 siblings, 1 reply; 190+ messages in thread From: Georg Bauhaus @ 2010-11-04 10:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 10:09 ` Georg Bauhaus @ 2010-11-06 16:53 ` Stephen Leake 2010-11-06 19:24 ` Georg Bauhaus 0 siblings, 1 reply; 190+ messages in thread From: Stephen Leake @ 2010-11-06 16:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-06 16:53 ` Stephen Leake @ 2010-11-06 19:24 ` Georg Bauhaus 0 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-06 19:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 5:23 ` Stephen Leake 2010-11-04 9:41 ` Georg Bauhaus 2010-11-04 10:09 ` Georg Bauhaus @ 2010-11-04 17:46 ` Jeffrey Carter 2 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-04 17:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 17:01 ` Georg Bauhaus 2010-11-03 17:42 ` Vinzent Hoefler @ 2010-11-03 20:38 ` Warren 2010-11-03 20:50 ` Yannick Duchêne (Hibou57) 2010-11-03 22:32 ` Georg Bauhaus 2010-11-03 20:44 ` Yannick Duchêne (Hibou57) 2 siblings, 2 replies; 190+ messages in thread From: Warren @ 2010-11-03 20:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 20:38 ` Warren @ 2010-11-03 20:50 ` Yannick Duchêne (Hibou57) 2010-11-03 22:32 ` Georg Bauhaus 1 sibling, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-03 20:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 20:38 ` Warren 2010-11-03 20:50 ` Yannick Duchêne (Hibou57) @ 2010-11-03 22:32 ` Georg Bauhaus 2010-11-04 13:59 ` Warren 1 sibling, 1 reply; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 22:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 22:32 ` Georg Bauhaus @ 2010-11-04 13:59 ` Warren 2010-11-04 20:57 ` Martin 0 siblings, 1 reply; 190+ messages in thread From: Warren @ 2010-11-04 13:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 13:59 ` Warren @ 2010-11-04 20:57 ` Martin 2010-11-05 20:43 ` Warren 0 siblings, 1 reply; 190+ messages in thread From: Martin @ 2010-11-04 20:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 20:57 ` Martin @ 2010-11-05 20:43 ` Warren 0 siblings, 0 replies; 190+ messages in thread From: Warren @ 2010-11-05 20:43 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 17:01 ` Georg Bauhaus 2010-11-03 17:42 ` Vinzent Hoefler 2010-11-03 20:38 ` Warren @ 2010-11-03 20:44 ` Yannick Duchêne (Hibou57) 2010-11-03 20:45 ` Yannick Duchêne (Hibou57) ` (2 more replies) 2 siblings, 3 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-03 20:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 20:44 ` Yannick Duchêne (Hibou57) @ 2010-11-03 20:45 ` Yannick Duchêne (Hibou57) 2010-11-03 21:27 ` Simon Wright 2010-11-03 22:44 ` Georg Bauhaus 2 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-03 20:45 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 20:44 ` Yannick Duchêne (Hibou57) 2010-11-03 20:45 ` Yannick Duchêne (Hibou57) @ 2010-11-03 21:27 ` Simon Wright 2010-11-03 22:44 ` Georg Bauhaus 2 siblings, 0 replies; 190+ messages in thread From: Simon Wright @ 2010-11-03 21:27 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 20:44 ` Yannick Duchêne (Hibou57) 2010-11-03 20:45 ` Yannick Duchêne (Hibou57) 2010-11-03 21:27 ` Simon Wright @ 2010-11-03 22:44 ` Georg Bauhaus 2010-11-04 1:19 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 22:44 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 22:44 ` Georg Bauhaus @ 2010-11-04 1:19 ` Yannick Duchêne (Hibou57) 2010-11-04 5:18 ` Shark8 2010-11-04 10:29 ` Georg Bauhaus 0 siblings, 2 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 1:19 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 1:19 ` Yannick Duchêne (Hibou57) @ 2010-11-04 5:18 ` Shark8 2010-11-04 6:30 ` Yannick Duchêne (Hibou57) 2010-11-04 10:29 ` Georg Bauhaus 1 sibling, 1 reply; 190+ messages in thread From: Shark8 @ 2010-11-04 5:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 5:18 ` Shark8 @ 2010-11-04 6:30 ` Yannick Duchêne (Hibou57) 2010-11-04 14:23 ` Warren 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 6:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 6:30 ` Yannick Duchêne (Hibou57) @ 2010-11-04 14:23 ` Warren 0 siblings, 0 replies; 190+ messages in thread From: Warren @ 2010-11-04 14:23 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 1:19 ` Yannick Duchêne (Hibou57) 2010-11-04 5:18 ` Shark8 @ 2010-11-04 10:29 ` Georg Bauhaus 2010-11-04 11:06 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 190+ messages in thread From: Georg Bauhaus @ 2010-11-04 10:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 10:29 ` Georg Bauhaus @ 2010-11-04 11:06 ` Yannick Duchêne (Hibou57) 2010-11-04 12:56 ` Georg Bauhaus 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 11:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 11:06 ` Yannick Duchêne (Hibou57) @ 2010-11-04 12:56 ` Georg Bauhaus 0 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-04 12:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:19 ` Jeffrey Carter 2010-11-01 19:41 ` Yannick Duchêne (Hibou57) @ 2010-11-01 19:59 ` Shark8 2010-11-01 20:43 ` Yannick Duchêne (Hibou57) 2010-11-01 21:01 ` Jeffrey Carter 2010-11-02 0:07 ` Adam Beneschan 2010-11-02 8:17 ` Stephen Leake 3 siblings, 2 replies; 190+ messages in thread From: Shark8 @ 2010-11-01 19:59 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:59 ` Shark8 @ 2010-11-01 20:43 ` Yannick Duchêne (Hibou57) 2010-11-01 21:54 ` Shark8 2010-11-01 21:01 ` Jeffrey Carter 1 sibling, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 20:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 20:43 ` Yannick Duchêne (Hibou57) @ 2010-11-01 21:54 ` Shark8 0 siblings, 0 replies; 190+ messages in thread From: Shark8 @ 2010-11-01 21:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:59 ` Shark8 2010-11-01 20:43 ` Yannick Duchêne (Hibou57) @ 2010-11-01 21:01 ` Jeffrey Carter 2010-11-01 21:49 ` Shark8 1 sibling, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-01 21:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 21:01 ` Jeffrey Carter @ 2010-11-01 21:49 ` Shark8 0 siblings, 0 replies; 190+ messages in thread From: Shark8 @ 2010-11-01 21:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:19 ` Jeffrey Carter 2010-11-01 19:41 ` Yannick Duchêne (Hibou57) 2010-11-01 19:59 ` Shark8 @ 2010-11-02 0:07 ` Adam Beneschan 2010-11-02 8:17 ` Stephen Leake 3 siblings, 0 replies; 190+ messages in thread From: Adam Beneschan @ 2010-11-02 0:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 19:19 ` Jeffrey Carter ` (2 preceding siblings ...) 2010-11-02 0:07 ` Adam Beneschan @ 2010-11-02 8:17 ` Stephen Leake 2010-11-02 8:29 ` Yannick Duchêne (Hibou57) 2010-11-02 19:02 ` Beginners question: Compound types, how-to? Jeffrey Carter 3 siblings, 2 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-02 8:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 8:17 ` Stephen Leake @ 2010-11-02 8:29 ` Yannick Duchêne (Hibou57) 2010-11-02 8:50 ` Dmitry A. Kazakov 2010-11-03 12:02 ` Searching for "_Type" discussions Stephen Leake 2010-11-02 19:02 ` Beginners question: Compound types, how-to? Jeffrey Carter 1 sibling, 2 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-02 8:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 8:29 ` Yannick Duchêne (Hibou57) @ 2010-11-02 8:50 ` Dmitry A. Kazakov 2010-11-03 12:02 ` Searching for "_Type" discussions Stephen Leake 1 sibling, 0 replies; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-02 8:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Searching for "_Type" discussions 2010-11-02 8:29 ` Yannick Duchêne (Hibou57) 2010-11-02 8:50 ` Dmitry A. Kazakov @ 2010-11-03 12:02 ` Stephen Leake 1 sibling, 0 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-03 12:02 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 8:17 ` Stephen Leake 2010-11-02 8:29 ` Yannick Duchêne (Hibou57) @ 2010-11-02 19:02 ` Jeffrey Carter 2010-11-02 19:22 ` Yannick Duchêne (Hibou57) ` (3 more replies) 1 sibling, 4 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-02 19:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 19:02 ` Beginners question: Compound types, how-to? Jeffrey Carter @ 2010-11-02 19:22 ` Yannick Duchêne (Hibou57) 2010-11-02 20:24 ` Simon Wright 2010-11-02 20:38 ` Beginners question: Compound types, how-to? Jeffrey Carter 2010-11-02 20:59 ` Britt Snodgrass ` (2 subsequent siblings) 3 siblings, 2 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-02 19:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 19:22 ` Yannick Duchêne (Hibou57) @ 2010-11-02 20:24 ` Simon Wright 2010-11-03 12:14 ` _Type vs no _Type Stephen Leake 2010-11-02 20:38 ` Beginners question: Compound types, how-to? Jeffrey Carter 1 sibling, 1 reply; 190+ messages in thread From: Simon Wright @ 2010-11-02 20:24 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-02 20:24 ` Simon Wright @ 2010-11-03 12:14 ` Stephen Leake 2010-11-03 21:16 ` Yannick Duchêne (Hibou57) ` (3 more replies) 0 siblings, 4 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-03 12:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 12:14 ` _Type vs no _Type Stephen Leake @ 2010-11-03 21:16 ` Yannick Duchêne (Hibou57) 2010-11-03 21:19 ` Yannick Duchêne (Hibou57) 2010-11-04 5:29 ` Stephen Leake 2010-11-03 21:29 ` Simon Wright ` (2 subsequent siblings) 3 siblings, 2 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-03 21:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 21:16 ` Yannick Duchêne (Hibou57) @ 2010-11-03 21:19 ` Yannick Duchêne (Hibou57) 2010-11-04 5:37 ` Stephen Leake 2010-11-04 5:29 ` Stephen Leake 1 sibling, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-03 21:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 21:19 ` Yannick Duchêne (Hibou57) @ 2010-11-04 5:37 ` Stephen Leake 0 siblings, 0 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-04 5:37 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 21:16 ` Yannick Duchêne (Hibou57) 2010-11-03 21:19 ` Yannick Duchêne (Hibou57) @ 2010-11-04 5:29 ` Stephen Leake 1 sibling, 0 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-04 5:29 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 12:14 ` _Type vs no _Type Stephen Leake 2010-11-03 21:16 ` Yannick Duchêne (Hibou57) @ 2010-11-03 21:29 ` Simon Wright 2010-11-04 5:28 ` Nasser M. Abbasi 2010-11-04 17:40 ` Jeffrey Carter 2010-11-04 17:49 ` Jeffrey Carter 3 siblings, 1 reply; 190+ messages in thread From: Simon Wright @ 2010-11-03 21:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 21:29 ` Simon Wright @ 2010-11-04 5:28 ` Nasser M. Abbasi 2010-11-04 6:06 ` Yannick Duchêne (Hibou57) ` (3 more replies) 0 siblings, 4 replies; 190+ messages in thread From: Nasser M. Abbasi @ 2010-11-04 5:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 5:28 ` Nasser M. Abbasi @ 2010-11-04 6:06 ` Yannick Duchêne (Hibou57) 2010-11-04 6:40 ` Shark8 ` (2 subsequent siblings) 3 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 6:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 5:28 ` Nasser M. Abbasi 2010-11-04 6:06 ` Yannick Duchêne (Hibou57) @ 2010-11-04 6:40 ` Shark8 2010-11-05 17:49 ` Florian Weimer 2010-11-04 18:29 ` Britt Snodgrass 2010-11-05 17:24 ` Robert A Duff 3 siblings, 1 reply; 190+ messages in thread From: Shark8 @ 2010-11-04 6:40 UTC (permalink / raw) 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? ;) } ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 6:40 ` Shark8 @ 2010-11-05 17:49 ` Florian Weimer 2010-11-05 18:18 ` Georg Bauhaus 0 siblings, 1 reply; 190+ messages in thread From: Florian Weimer @ 2010-11-05 17:49 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:49 ` Florian Weimer @ 2010-11-05 18:18 ` Georg Bauhaus 0 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-05 18:18 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 5:28 ` Nasser M. Abbasi 2010-11-04 6:06 ` Yannick Duchêne (Hibou57) 2010-11-04 6:40 ` Shark8 @ 2010-11-04 18:29 ` Britt Snodgrass 2010-11-04 19:08 ` Nasser M. Abbasi ` (2 more replies) 2010-11-05 17:24 ` Robert A Duff 3 siblings, 3 replies; 190+ messages in thread From: Britt Snodgrass @ 2010-11-04 18:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 18:29 ` Britt Snodgrass @ 2010-11-04 19:08 ` Nasser M. Abbasi 2010-11-04 19:47 ` Britt Snodgrass ` (4 more replies) 2010-11-05 6:49 ` J-P. Rosen 2010-11-05 7:05 ` Florian Weimer 2 siblings, 5 replies; 190+ messages in thread From: Nasser M. Abbasi @ 2010-11-04 19:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 19:08 ` Nasser M. Abbasi @ 2010-11-04 19:47 ` Britt Snodgrass 2010-11-04 19:59 ` Simon Wright ` (3 subsequent siblings) 4 siblings, 0 replies; 190+ messages in thread From: Britt Snodgrass @ 2010-11-04 19:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 19:08 ` Nasser M. Abbasi 2010-11-04 19:47 ` Britt Snodgrass @ 2010-11-04 19:59 ` Simon Wright 2010-11-04 22:38 ` Yannick Duchêne (Hibou57) 2010-11-05 7:05 ` Florian Weimer 2010-11-05 3:10 ` Georg Bauhaus ` (2 subsequent siblings) 4 siblings, 2 replies; 190+ messages in thread From: Simon Wright @ 2010-11-04 19:59 UTC (permalink / raw) "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 ..) ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 19:59 ` Simon Wright @ 2010-11-04 22:38 ` Yannick Duchêne (Hibou57) 2010-11-05 7:05 ` Florian Weimer 1 sibling, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 22:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 19:59 ` Simon Wright 2010-11-04 22:38 ` Yannick Duchêne (Hibou57) @ 2010-11-05 7:05 ` Florian Weimer 2010-11-05 8:48 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 190+ messages in thread From: Florian Weimer @ 2010-11-05 7:05 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 7:05 ` Florian Weimer @ 2010-11-05 8:48 ` Yannick Duchêne (Hibou57) 2010-11-05 16:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-05 8:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 8:48 ` Yannick Duchêne (Hibou57) @ 2010-11-05 16:01 ` Dmitry A. Kazakov 2010-11-05 19:26 ` Jeffrey Carter 0 siblings, 1 reply; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-05 16:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 16:01 ` Dmitry A. Kazakov @ 2010-11-05 19:26 ` Jeffrey Carter 2010-11-05 19:34 ` Dmitry A. Kazakov 2010-11-05 19:35 ` Florian Weimer 0 siblings, 2 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-05 19:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 19:26 ` Jeffrey Carter @ 2010-11-05 19:34 ` Dmitry A. Kazakov 2010-11-05 19:35 ` Florian Weimer 1 sibling, 0 replies; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-05 19:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 19:26 ` Jeffrey Carter 2010-11-05 19:34 ` Dmitry A. Kazakov @ 2010-11-05 19:35 ` Florian Weimer 2010-11-05 20:08 ` Dmitry A. Kazakov ` (2 more replies) 1 sibling, 3 replies; 190+ messages in thread From: Florian Weimer @ 2010-11-05 19:35 UTC (permalink / raw) * Jeffrey Carter: > Personally, I think allowing non-English identifiers in a language > with English reserved words is a mistake. "English" or "ASCII"? ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 19:35 ` Florian Weimer @ 2010-11-05 20:08 ` Dmitry A. Kazakov 2010-11-05 20:14 ` Florian Weimer 2010-11-05 20:45 ` Warren 2010-11-05 21:37 ` Jeffrey Carter 2 siblings, 1 reply; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-05 20:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 20:08 ` Dmitry A. Kazakov @ 2010-11-05 20:14 ` Florian Weimer 2010-11-05 21:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 190+ messages in thread From: Florian Weimer @ 2010-11-05 20:14 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 20:14 ` Florian Weimer @ 2010-11-05 21:01 ` Dmitry A. Kazakov 0 siblings, 0 replies; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-05 21:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 19:35 ` Florian Weimer 2010-11-05 20:08 ` Dmitry A. Kazakov @ 2010-11-05 20:45 ` Warren 2010-11-05 22:59 ` Brian Drummond 2010-11-05 21:37 ` Jeffrey Carter 2 siblings, 1 reply; 190+ messages in thread From: Warren @ 2010-11-05 20:45 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 20:45 ` Warren @ 2010-11-05 22:59 ` Brian Drummond 2010-11-09 20:29 ` Warren 0 siblings, 1 reply; 190+ messages in thread From: Brian Drummond @ 2010-11-05 22:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 22:59 ` Brian Drummond @ 2010-11-09 20:29 ` Warren 0 siblings, 0 replies; 190+ messages in thread From: Warren @ 2010-11-09 20:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 19:35 ` Florian Weimer 2010-11-05 20:08 ` Dmitry A. Kazakov 2010-11-05 20:45 ` Warren @ 2010-11-05 21:37 ` Jeffrey Carter 2 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-05 21:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 19:08 ` Nasser M. Abbasi 2010-11-04 19:47 ` Britt Snodgrass 2010-11-04 19:59 ` Simon Wright @ 2010-11-05 3:10 ` Georg Bauhaus 2010-11-05 6:54 ` J-P. Rosen 2010-11-05 17:29 ` Robert A Duff 4 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-05 3:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 19:08 ` Nasser M. Abbasi ` (2 preceding siblings ...) 2010-11-05 3:10 ` Georg Bauhaus @ 2010-11-05 6:54 ` J-P. Rosen 2010-11-05 16:39 ` Robert A Duff 2010-11-05 17:29 ` Robert A Duff 4 siblings, 1 reply; 190+ messages in thread From: J-P. Rosen @ 2010-11-05 6:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 6:54 ` J-P. Rosen @ 2010-11-05 16:39 ` Robert A Duff 2010-11-05 23:32 ` J-P. Rosen 0 siblings, 1 reply; 190+ messages in thread From: Robert A Duff @ 2010-11-05 16:39 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 16:39 ` Robert A Duff @ 2010-11-05 23:32 ` J-P. Rosen 2010-11-06 0:55 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 190+ messages in thread From: J-P. Rosen @ 2010-11-05 23:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 23:32 ` J-P. Rosen @ 2010-11-06 0:55 ` Yannick Duchêne (Hibou57) 2010-11-06 13:40 ` Simon Wright 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-06 0:55 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 0:55 ` Yannick Duchêne (Hibou57) @ 2010-11-06 13:40 ` Simon Wright 0 siblings, 0 replies; 190+ messages in thread From: Simon Wright @ 2010-11-06 13:40 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 19:08 ` Nasser M. Abbasi ` (3 preceding siblings ...) 2010-11-05 6:54 ` J-P. Rosen @ 2010-11-05 17:29 ` Robert A Duff 2010-11-05 19:28 ` Jeffrey Carter 4 siblings, 1 reply; 190+ messages in thread From: Robert A Duff @ 2010-11-05 17:29 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:29 ` Robert A Duff @ 2010-11-05 19:28 ` Jeffrey Carter 2010-11-05 23:09 ` Robert A Duff 0 siblings, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-05 19:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 19:28 ` Jeffrey Carter @ 2010-11-05 23:09 ` Robert A Duff 2010-11-06 0:44 ` Jeffrey Carter 0 siblings, 1 reply; 190+ messages in thread From: Robert A Duff @ 2010-11-05 23:09 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 23:09 ` Robert A Duff @ 2010-11-06 0:44 ` Jeffrey Carter 2010-11-06 21:10 ` Robert A Duff 0 siblings, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-06 0:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 0:44 ` Jeffrey Carter @ 2010-11-06 21:10 ` Robert A Duff 2010-11-07 0:01 ` Brian Drummond 2010-11-07 20:41 ` Jeffrey Carter 0 siblings, 2 replies; 190+ messages in thread From: Robert A Duff @ 2010-11-06 21:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 21:10 ` Robert A Duff @ 2010-11-07 0:01 ` Brian Drummond 2010-11-07 20:41 ` Jeffrey Carter 1 sibling, 0 replies; 190+ messages in thread From: Brian Drummond @ 2010-11-07 0:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 21:10 ` Robert A Duff 2010-11-07 0:01 ` Brian Drummond @ 2010-11-07 20:41 ` Jeffrey Carter 2010-11-07 21:03 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-07 20:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-07 20:41 ` Jeffrey Carter @ 2010-11-07 21:03 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-07 21:03 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 18:29 ` Britt Snodgrass 2010-11-04 19:08 ` Nasser M. Abbasi @ 2010-11-05 6:49 ` J-P. Rosen 2010-11-05 7:05 ` Florian Weimer 2 siblings, 0 replies; 190+ messages in thread From: J-P. Rosen @ 2010-11-05 6:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 18:29 ` Britt Snodgrass 2010-11-04 19:08 ` Nasser M. Abbasi 2010-11-05 6:49 ` J-P. Rosen @ 2010-11-05 7:05 ` Florian Weimer 2010-11-05 7:20 ` J-P. Rosen ` (2 more replies) 2 siblings, 3 replies; 190+ messages in thread From: Florian Weimer @ 2010-11-05 7:05 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 7:05 ` Florian Weimer @ 2010-11-05 7:20 ` J-P. Rosen 2010-11-05 17:39 ` Florian Weimer 2010-11-05 10:58 ` Georg Bauhaus 2010-11-09 20:43 ` Warren 2 siblings, 1 reply; 190+ messages in thread From: J-P. Rosen @ 2010-11-05 7:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 7:20 ` J-P. Rosen @ 2010-11-05 17:39 ` Florian Weimer 2010-11-05 18:08 ` Georg Bauhaus ` (2 more replies) 0 siblings, 3 replies; 190+ messages in thread From: Florian Weimer @ 2010-11-05 17:39 UTC (permalink / raw) * 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). ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:39 ` Florian Weimer @ 2010-11-05 18:08 ` Georg Bauhaus 2010-11-05 23:36 ` J-P. Rosen 2010-11-06 1:05 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-05 18:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:39 ` Florian Weimer 2010-11-05 18:08 ` Georg Bauhaus @ 2010-11-05 23:36 ` J-P. Rosen 2010-11-06 1:05 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 190+ messages in thread From: J-P. Rosen @ 2010-11-05 23:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:39 ` Florian Weimer 2010-11-05 18:08 ` Georg Bauhaus 2010-11-05 23:36 ` J-P. Rosen @ 2010-11-06 1:05 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-06 1:05 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 7:05 ` Florian Weimer 2010-11-05 7:20 ` J-P. Rosen @ 2010-11-05 10:58 ` Georg Bauhaus 2010-11-05 16:31 ` Dmitry A. Kazakov ` (2 more replies) 2010-11-09 20:43 ` Warren 2 siblings, 3 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-05 10:58 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 10:58 ` Georg Bauhaus @ 2010-11-05 16:31 ` Dmitry A. Kazakov 2010-11-05 17:38 ` Georg Bauhaus 2010-11-05 17:31 ` Florian Weimer 2010-11-05 23:29 ` J-P. Rosen 2 siblings, 1 reply; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-05 16:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 16:31 ` Dmitry A. Kazakov @ 2010-11-05 17:38 ` Georg Bauhaus 0 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-05 17:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 10:58 ` Georg Bauhaus 2010-11-05 16:31 ` Dmitry A. Kazakov @ 2010-11-05 17:31 ` Florian Weimer 2010-11-05 18:02 ` Georg Bauhaus 2010-11-05 23:29 ` J-P. Rosen 2 siblings, 1 reply; 190+ messages in thread From: Florian Weimer @ 2010-11-05 17:31 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:31 ` Florian Weimer @ 2010-11-05 18:02 ` Georg Bauhaus 0 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-05 18:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 10:58 ` Georg Bauhaus 2010-11-05 16:31 ` Dmitry A. Kazakov 2010-11-05 17:31 ` Florian Weimer @ 2010-11-05 23:29 ` J-P. Rosen 2010-11-06 0:00 ` Robert A Duff 2010-11-06 0:01 ` Georg Bauhaus 2 siblings, 2 replies; 190+ messages in thread From: J-P. Rosen @ 2010-11-05 23:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 23:29 ` J-P. Rosen @ 2010-11-06 0:00 ` Robert A Duff 2010-11-06 0:12 ` Simon Wright 2010-11-06 11:34 ` J-P. Rosen 2010-11-06 0:01 ` Georg Bauhaus 1 sibling, 2 replies; 190+ messages in thread From: Robert A Duff @ 2010-11-06 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 0:00 ` Robert A Duff @ 2010-11-06 0:12 ` Simon Wright 2010-11-06 11:34 ` J-P. Rosen 1 sibling, 0 replies; 190+ messages in thread From: Simon Wright @ 2010-11-06 0:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 0:00 ` Robert A Duff 2010-11-06 0:12 ` Simon Wright @ 2010-11-06 11:34 ` J-P. Rosen 1 sibling, 0 replies; 190+ messages in thread From: J-P. Rosen @ 2010-11-06 11:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 23:29 ` J-P. Rosen 2010-11-06 0:00 ` Robert A Duff @ 2010-11-06 0:01 ` Georg Bauhaus 1 sibling, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-06 0:01 UTC (permalink / raw) 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 :-> ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 7:05 ` Florian Weimer 2010-11-05 7:20 ` J-P. Rosen 2010-11-05 10:58 ` Georg Bauhaus @ 2010-11-09 20:43 ` Warren 2 siblings, 0 replies; 190+ messages in thread From: Warren @ 2010-11-09 20:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 5:28 ` Nasser M. Abbasi ` (2 preceding siblings ...) 2010-11-04 18:29 ` Britt Snodgrass @ 2010-11-05 17:24 ` Robert A Duff 2010-11-05 20:05 ` Vinzent Hoefler 3 siblings, 1 reply; 190+ messages in thread From: Robert A Duff @ 2010-11-05 17:24 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:24 ` Robert A Duff @ 2010-11-05 20:05 ` Vinzent Hoefler 2010-11-05 22:28 ` Robert A Duff 0 siblings, 1 reply; 190+ messages in thread From: Vinzent Hoefler @ 2010-11-05 20:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 20:05 ` Vinzent Hoefler @ 2010-11-05 22:28 ` Robert A Duff 0 siblings, 0 replies; 190+ messages in thread From: Robert A Duff @ 2010-11-05 22:28 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 12:14 ` _Type vs no _Type Stephen Leake 2010-11-03 21:16 ` Yannick Duchêne (Hibou57) 2010-11-03 21:29 ` Simon Wright @ 2010-11-04 17:40 ` Jeffrey Carter 2010-11-05 17:15 ` Robert A Duff 2010-11-04 17:49 ` Jeffrey Carter 3 siblings, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-04 17:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-04 17:40 ` Jeffrey Carter @ 2010-11-05 17:15 ` Robert A Duff 2010-11-05 19:24 ` Jeffrey Carter 0 siblings, 1 reply; 190+ messages in thread From: Robert A Duff @ 2010-11-05 17:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 17:15 ` Robert A Duff @ 2010-11-05 19:24 ` Jeffrey Carter 2010-11-05 22:52 ` Robert A Duff 0 siblings, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-05 19:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 19:24 ` Jeffrey Carter @ 2010-11-05 22:52 ` Robert A Duff 2010-11-06 0:40 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 190+ messages in thread From: Robert A Duff @ 2010-11-05 22:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 22:52 ` Robert A Duff @ 2010-11-06 0:40 ` Jeffrey Carter 2010-11-06 7:12 ` Dmitry A. Kazakov 2010-11-06 0:42 ` Shark8 2010-11-06 1:33 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 190+ messages in thread From: Jeffrey Carter @ 2010-11-06 0:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 0:40 ` Jeffrey Carter @ 2010-11-06 7:12 ` Dmitry A. Kazakov 2010-11-06 10:13 ` Yannick Duchêne (Hibou57) ` (2 more replies) 0 siblings, 3 replies; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-06 7:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 7:12 ` Dmitry A. Kazakov @ 2010-11-06 10:13 ` Yannick Duchêne (Hibou57) 2010-11-06 11:00 ` Georg Bauhaus 2010-11-06 17:10 ` (see below) 2 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-06 10:13 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 7:12 ` Dmitry A. Kazakov 2010-11-06 10:13 ` Yannick Duchêne (Hibou57) @ 2010-11-06 11:00 ` Georg Bauhaus 2010-11-06 11:35 ` Dmitry A. Kazakov 2010-11-06 20:52 ` Shark8 2010-11-06 17:10 ` (see below) 2 siblings, 2 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-06 11:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 11:00 ` Georg Bauhaus @ 2010-11-06 11:35 ` Dmitry A. Kazakov 2010-11-06 13:34 ` Simon Wright 2010-11-06 20:52 ` Shark8 1 sibling, 1 reply; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-06 11:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 11:35 ` Dmitry A. Kazakov @ 2010-11-06 13:34 ` Simon Wright 2010-11-06 14:53 ` Dmitry A. Kazakov 0 siblings, 1 reply; 190+ messages in thread From: Simon Wright @ 2010-11-06 13:34 UTC (permalink / raw) "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; ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 13:34 ` Simon Wright @ 2010-11-06 14:53 ` Dmitry A. Kazakov 0 siblings, 0 replies; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-06 14:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 11:00 ` Georg Bauhaus 2010-11-06 11:35 ` Dmitry A. Kazakov @ 2010-11-06 20:52 ` Shark8 2010-11-06 21:58 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 190+ messages in thread From: Shark8 @ 2010-11-06 20:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 20:52 ` Shark8 @ 2010-11-06 21:58 ` Yannick Duchêne (Hibou57) 2010-11-07 2:57 ` Shark8 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-06 21:58 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 21:58 ` Yannick Duchêne (Hibou57) @ 2010-11-07 2:57 ` Shark8 2010-11-07 3:12 ` Yannick Duchêne (Hibou57) 2010-11-07 6:37 ` J-P. Rosen 0 siblings, 2 replies; 190+ messages in thread From: Shark8 @ 2010-11-07 2:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-07 2:57 ` Shark8 @ 2010-11-07 3:12 ` Yannick Duchêne (Hibou57) 2010-11-07 6:37 ` J-P. Rosen 1 sibling, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-07 3:12 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-07 2:57 ` Shark8 2010-11-07 3:12 ` Yannick Duchêne (Hibou57) @ 2010-11-07 6:37 ` J-P. Rosen 1 sibling, 0 replies; 190+ messages in thread From: J-P. Rosen @ 2010-11-07 6:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 7:12 ` Dmitry A. Kazakov 2010-11-06 10:13 ` Yannick Duchêne (Hibou57) 2010-11-06 11:00 ` Georg Bauhaus @ 2010-11-06 17:10 ` (see below) 2010-11-06 22:08 ` Niklas Holsti 2 siblings, 1 reply; 190+ messages in thread From: (see below) @ 2010-11-06 17:10 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 17:10 ` (see below) @ 2010-11-06 22:08 ` Niklas Holsti 2010-11-06 22:24 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 190+ messages in thread From: Niklas Holsti @ 2010-11-06 22:08 UTC (permalink / raw) (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 . @ . ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 22:08 ` Niklas Holsti @ 2010-11-06 22:24 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-06 22:24 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 22:52 ` Robert A Duff 2010-11-06 0:40 ` Jeffrey Carter @ 2010-11-06 0:42 ` Shark8 2010-11-06 13:24 ` Robert A Duff 2010-11-06 1:33 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 190+ messages in thread From: Shark8 @ 2010-11-06 0:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 0:42 ` Shark8 @ 2010-11-06 13:24 ` Robert A Duff 2010-11-06 21:20 ` Shark8 0 siblings, 1 reply; 190+ messages in thread From: Robert A Duff @ 2010-11-06 13:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 13:24 ` Robert A Duff @ 2010-11-06 21:20 ` Shark8 2010-11-06 22:12 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 190+ messages in thread From: Shark8 @ 2010-11-06 21:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 21:20 ` Shark8 @ 2010-11-06 22:12 ` Yannick Duchêne (Hibou57) 2010-11-16 20:33 ` Randy Brukardt 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-06 22:12 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-06 22:12 ` Yannick Duchêne (Hibou57) @ 2010-11-16 20:33 ` Randy Brukardt 0 siblings, 0 replies; 190+ messages in thread From: Randy Brukardt @ 2010-11-16 20:33 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-05 22:52 ` Robert A Duff 2010-11-06 0:40 ` Jeffrey Carter 2010-11-06 0:42 ` Shark8 @ 2010-11-06 1:33 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-06 1:33 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: _Type vs no _Type 2010-11-03 12:14 ` _Type vs no _Type Stephen Leake ` (2 preceding siblings ...) 2010-11-04 17:40 ` Jeffrey Carter @ 2010-11-04 17:49 ` Jeffrey Carter 3 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-04 17:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 19:22 ` Yannick Duchêne (Hibou57) 2010-11-02 20:24 ` Simon Wright @ 2010-11-02 20:38 ` Jeffrey Carter 1 sibling, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-02 20:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 19:02 ` Beginners question: Compound types, how-to? Jeffrey Carter 2010-11-02 19:22 ` Yannick Duchêne (Hibou57) @ 2010-11-02 20:59 ` Britt Snodgrass 2010-11-03 0:46 ` Georg Bauhaus 2010-11-03 12:06 ` Stephen Leake 2010-11-04 13:47 ` Peter C. Chapin 3 siblings, 1 reply; 190+ messages in thread From: Britt Snodgrass @ 2010-11-02 20:59 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 20:59 ` Britt Snodgrass @ 2010-11-03 0:46 ` Georg Bauhaus 2010-11-03 1:59 ` Yannick Duchêne (Hibou57) ` (3 more replies) 0 siblings, 4 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 0:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 0:46 ` Georg Bauhaus @ 2010-11-03 1:59 ` Yannick Duchêne (Hibou57) 2010-11-03 12:59 ` Georg Bauhaus 2010-11-03 8:58 ` Dmitry A. Kazakov ` (2 subsequent siblings) 3 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-03 1:59 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 1:59 ` Yannick Duchêne (Hibou57) @ 2010-11-03 12:59 ` Georg Bauhaus 2010-11-03 15:28 ` Georg Bauhaus 0 siblings, 1 reply; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 12:59 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 12:59 ` Georg Bauhaus @ 2010-11-03 15:28 ` Georg Bauhaus 0 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 15:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 0:46 ` Georg Bauhaus 2010-11-03 1:59 ` Yannick Duchêne (Hibou57) @ 2010-11-03 8:58 ` Dmitry A. Kazakov 2010-11-03 12:31 ` Georg Bauhaus 2010-11-03 12:18 ` Stephen Leake 2010-11-03 17:35 ` Vinzent Hoefler 3 siblings, 1 reply; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-03 8:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 8:58 ` Dmitry A. Kazakov @ 2010-11-03 12:31 ` Georg Bauhaus 0 siblings, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 12:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 0:46 ` Georg Bauhaus 2010-11-03 1:59 ` Yannick Duchêne (Hibou57) 2010-11-03 8:58 ` Dmitry A. Kazakov @ 2010-11-03 12:18 ` Stephen Leake 2010-11-03 13:12 ` Georg Bauhaus 2010-11-04 0:55 ` Yannick Duchêne (Hibou57) 2010-11-03 17:35 ` Vinzent Hoefler 3 siblings, 2 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-03 12:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 12:18 ` Stephen Leake @ 2010-11-03 13:12 ` Georg Bauhaus 2010-11-04 0:55 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 190+ messages in thread From: Georg Bauhaus @ 2010-11-03 13:12 UTC (permalink / raw) 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. :-) ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 12:18 ` Stephen Leake 2010-11-03 13:12 ` Georg Bauhaus @ 2010-11-04 0:55 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 0:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 0:46 ` Georg Bauhaus ` (2 preceding siblings ...) 2010-11-03 12:18 ` Stephen Leake @ 2010-11-03 17:35 ` Vinzent Hoefler 2010-11-03 21:19 ` Simon Wright 3 siblings, 1 reply; 190+ messages in thread From: Vinzent Hoefler @ 2010-11-03 17:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 17:35 ` Vinzent Hoefler @ 2010-11-03 21:19 ` Simon Wright 2010-11-03 21:31 ` Vinzent Hoefler 0 siblings, 1 reply; 190+ messages in thread From: Simon Wright @ 2010-11-03 21:19 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 21:19 ` Simon Wright @ 2010-11-03 21:31 ` Vinzent Hoefler 2010-11-04 5:25 ` Stephen Leake ` (2 more replies) 0 siblings, 3 replies; 190+ messages in thread From: Vinzent Hoefler @ 2010-11-03 21:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 21:31 ` Vinzent Hoefler @ 2010-11-04 5:25 ` Stephen Leake 2010-11-04 17:47 ` Jeffrey Carter 2010-11-04 6:11 ` Yannick Duchêne (Hibou57) 2010-11-04 17:42 ` Jeffrey Carter 2 siblings, 1 reply; 190+ messages in thread From: Stephen Leake @ 2010-11-04 5:25 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 5:25 ` Stephen Leake @ 2010-11-04 17:47 ` Jeffrey Carter 0 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-04 17:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 21:31 ` Vinzent Hoefler 2010-11-04 5:25 ` Stephen Leake @ 2010-11-04 6:11 ` Yannick Duchêne (Hibou57) 2010-11-04 19:30 ` Vinzent Hoefler 2010-11-04 17:42 ` Jeffrey Carter 2 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 6:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 6:11 ` Yannick Duchêne (Hibou57) @ 2010-11-04 19:30 ` Vinzent Hoefler 0 siblings, 0 replies; 190+ messages in thread From: Vinzent Hoefler @ 2010-11-04 19:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 21:31 ` Vinzent Hoefler 2010-11-04 5:25 ` Stephen Leake 2010-11-04 6:11 ` Yannick Duchêne (Hibou57) @ 2010-11-04 17:42 ` Jeffrey Carter 2 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-04 17:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 19:02 ` Beginners question: Compound types, how-to? Jeffrey Carter 2010-11-02 19:22 ` Yannick Duchêne (Hibou57) 2010-11-02 20:59 ` Britt Snodgrass @ 2010-11-03 12:06 ` Stephen Leake 2010-11-04 1:04 ` Yannick Duchêne (Hibou57) 2010-11-04 17:11 ` Jeffrey Carter 2010-11-04 13:47 ` Peter C. Chapin 3 siblings, 2 replies; 190+ messages in thread From: Stephen Leake @ 2010-11-03 12:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 12:06 ` Stephen Leake @ 2010-11-04 1:04 ` Yannick Duchêne (Hibou57) 2010-11-04 17:11 ` Jeffrey Carter 1 sibling, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-04 1:04 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-03 12:06 ` Stephen Leake 2010-11-04 1:04 ` Yannick Duchêne (Hibou57) @ 2010-11-04 17:11 ` Jeffrey Carter 1 sibling, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-04 17:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-02 19:02 ` Beginners question: Compound types, how-to? Jeffrey Carter ` (2 preceding siblings ...) 2010-11-03 12:06 ` Stephen Leake @ 2010-11-04 13:47 ` Peter C. Chapin 2010-11-04 14:30 ` Warren 3 siblings, 1 reply; 190+ messages in thread From: Peter C. Chapin @ 2010-11-04 13:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-04 13:47 ` Peter C. Chapin @ 2010-11-04 14:30 ` Warren 0 siblings, 0 replies; 190+ messages in thread From: Warren @ 2010-11-04 14:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 7:12 ` Mart van de Wege 2010-11-01 15:04 ` Shark8 @ 2010-11-01 17:24 ` Yannick Duchêne (Hibou57) 2010-11-01 21:31 ` Simon Wright 2010-11-01 19:05 ` Jeffrey Carter 2 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 17:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:24 ` Yannick Duchêne (Hibou57) @ 2010-11-01 21:31 ` Simon Wright 0 siblings, 0 replies; 190+ messages in thread From: Simon Wright @ 2010-11-01 21:31 UTC (permalink / raw) "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; ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 7:12 ` Mart van de Wege 2010-11-01 15:04 ` Shark8 2010-11-01 17:24 ` Yannick Duchêne (Hibou57) @ 2010-11-01 19:05 ` Jeffrey Carter 2 siblings, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-01 19:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 3:55 ` Jeffrey Carter 2010-11-01 7:12 ` Mart van de Wege @ 2010-11-01 11:50 ` (see below) 2010-11-01 17:16 ` Yannick Duchêne (Hibou57) 2010-11-01 19:25 ` Jeffrey Carter 1 sibling, 2 replies; 190+ messages in thread From: (see below) @ 2010-11-01 11:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 11:50 ` (see below) @ 2010-11-01 17:16 ` Yannick Duchêne (Hibou57) 2010-11-01 17:27 ` Georg Bauhaus 2010-11-01 18:12 ` Adam Beneschan 2010-11-01 19:25 ` Jeffrey Carter 1 sibling, 2 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 17:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:16 ` Yannick Duchêne (Hibou57) @ 2010-11-01 17:27 ` Georg Bauhaus 2010-11-01 17:41 ` Yannick Duchêne (Hibou57) 2010-11-01 18:12 ` Adam Beneschan 1 sibling, 1 reply; 190+ messages in thread From: Georg Bauhaus @ 2010-11-01 17:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:27 ` Georg Bauhaus @ 2010-11-01 17:41 ` Yannick Duchêne (Hibou57) 2010-11-01 17:55 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 17:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:41 ` Yannick Duchêne (Hibou57) @ 2010-11-01 17:55 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 17:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 17:16 ` Yannick Duchêne (Hibou57) 2010-11-01 17:27 ` Georg Bauhaus @ 2010-11-01 18:12 ` Adam Beneschan 1 sibling, 0 replies; 190+ messages in thread From: Adam Beneschan @ 2010-11-01 18:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 11:50 ` (see below) 2010-11-01 17:16 ` Yannick Duchêne (Hibou57) @ 2010-11-01 19:25 ` Jeffrey Carter 1 sibling, 0 replies; 190+ messages in thread From: Jeffrey Carter @ 2010-11-01 19:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-10-31 22:00 Beginners question: Compound types, how-to? Mart van de Wege 2010-10-31 22:36 ` Vinzent Hoefler 2010-11-01 3:55 ` Jeffrey Carter @ 2010-11-01 12:03 ` Brian Drummond 2010-11-01 12:17 ` Florian Weimer 2010-11-01 13:05 ` Mart van de Wege 2 siblings, 2 replies; 190+ messages in thread From: Brian Drummond @ 2010-11-01 12:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 12:03 ` Brian Drummond @ 2010-11-01 12:17 ` Florian Weimer 2010-11-01 13:05 ` Mart van de Wege 1 sibling, 0 replies; 190+ messages in thread From: Florian Weimer @ 2010-11-01 12:17 UTC (permalink / raw) * 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.) ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 12:03 ` Brian Drummond 2010-11-01 12:17 ` Florian Weimer @ 2010-11-01 13:05 ` Mart van de Wege 2010-11-01 22:45 ` Brian Drummond 1 sibling, 1 reply; 190+ messages in thread From: Mart van de Wege @ 2010-11-01 13:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 13:05 ` Mart van de Wege @ 2010-11-01 22:45 ` Brian Drummond 2010-11-01 23:17 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 190+ messages in thread From: Brian Drummond @ 2010-11-01 22:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 22:45 ` Brian Drummond @ 2010-11-01 23:17 ` Yannick Duchêne (Hibou57) 2010-11-02 8:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 190+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-11-01 23:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Beginners question: Compound types, how-to? 2010-11-01 23:17 ` Yannick Duchêne (Hibou57) @ 2010-11-02 8:32 ` Dmitry A. Kazakov 0 siblings, 0 replies; 190+ messages in thread From: Dmitry A. Kazakov @ 2010-11-02 8:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 190+ messages in thread
end of thread, other threads:[~2010-11-16 20:33 UTC | newest] Thread overview: 190+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-10-31 22:00 Beginners question: Compound types, how-to? Mart van de Wege 2010-10-31 22:36 ` Vinzent Hoefler 2010-10-31 23:27 ` Yannick Duchêne (Hibou57) 2010-11-01 7:14 ` Mart van de Wege 2010-11-01 19:22 ` Jeffrey Carter 2010-11-02 9:38 ` J-P. Rosen 2010-11-01 3:55 ` Jeffrey Carter 2010-11-01 7:12 ` Mart van de Wege 2010-11-01 15:04 ` Shark8 2010-11-01 17:06 ` Mart van de Wege 2010-11-01 17:39 ` Yannick Duchêne (Hibou57) 2010-11-01 17:58 ` Mart van de Wege 2010-11-01 19:19 ` Jeffrey Carter 2010-11-01 19:41 ` Yannick Duchêne (Hibou57) 2010-11-01 20:56 ` Jeffrey Carter 2010-11-01 21:05 ` Yannick Duchêne (Hibou57) 2010-11-03 16:56 ` Warren 2010-11-03 17:01 ` Georg Bauhaus 2010-11-03 17:42 ` Vinzent Hoefler 2010-11-04 5:23 ` Stephen Leake 2010-11-04 9:41 ` Georg Bauhaus 2010-11-06 16:49 ` Stephen Leake 2010-11-06 18:43 ` Jeffrey Carter 2010-11-06 19:35 ` Georg Bauhaus 2010-11-12 20:17 ` Randy Brukardt 2010-11-12 21:25 ` Jeffrey Carter 2010-11-04 10:09 ` Georg Bauhaus 2010-11-06 16:53 ` Stephen Leake 2010-11-06 19:24 ` Georg Bauhaus 2010-11-04 17:46 ` Jeffrey Carter 2010-11-03 20:38 ` Warren 2010-11-03 20:50 ` Yannick Duchêne (Hibou57) 2010-11-03 22:32 ` Georg Bauhaus 2010-11-04 13:59 ` Warren 2010-11-04 20:57 ` Martin 2010-11-05 20:43 ` Warren 2010-11-03 20:44 ` Yannick Duchêne (Hibou57) 2010-11-03 20:45 ` Yannick Duchêne (Hibou57) 2010-11-03 21:27 ` Simon Wright 2010-11-03 22:44 ` Georg Bauhaus 2010-11-04 1:19 ` Yannick Duchêne (Hibou57) 2010-11-04 5:18 ` Shark8 2010-11-04 6:30 ` Yannick Duchêne (Hibou57) 2010-11-04 14:23 ` Warren 2010-11-04 10:29 ` Georg Bauhaus 2010-11-04 11:06 ` Yannick Duchêne (Hibou57) 2010-11-04 12:56 ` Georg Bauhaus 2010-11-01 19:59 ` Shark8 2010-11-01 20:43 ` Yannick Duchêne (Hibou57) 2010-11-01 21:54 ` Shark8 2010-11-01 21:01 ` Jeffrey Carter 2010-11-01 21:49 ` Shark8 2010-11-02 0:07 ` Adam Beneschan 2010-11-02 8:17 ` Stephen Leake 2010-11-02 8:29 ` Yannick Duchêne (Hibou57) 2010-11-02 8:50 ` Dmitry A. Kazakov 2010-11-03 12:02 ` Searching for "_Type" discussions Stephen Leake 2010-11-02 19:02 ` Beginners question: Compound types, how-to? Jeffrey Carter 2010-11-02 19:22 ` Yannick Duchêne (Hibou57) 2010-11-02 20:24 ` Simon Wright 2010-11-03 12:14 ` _Type vs no _Type Stephen Leake 2010-11-03 21:16 ` Yannick Duchêne (Hibou57) 2010-11-03 21:19 ` Yannick Duchêne (Hibou57) 2010-11-04 5:37 ` Stephen Leake 2010-11-04 5:29 ` Stephen Leake 2010-11-03 21:29 ` Simon Wright 2010-11-04 5:28 ` Nasser M. Abbasi 2010-11-04 6:06 ` Yannick Duchêne (Hibou57) 2010-11-04 6:40 ` Shark8 2010-11-05 17:49 ` Florian Weimer 2010-11-05 18:18 ` Georg Bauhaus 2010-11-04 18:29 ` Britt Snodgrass 2010-11-04 19:08 ` Nasser M. Abbasi 2010-11-04 19:47 ` Britt Snodgrass 2010-11-04 19:59 ` Simon Wright 2010-11-04 22:38 ` Yannick Duchêne (Hibou57) 2010-11-05 7:05 ` Florian Weimer 2010-11-05 8:48 ` Yannick Duchêne (Hibou57) 2010-11-05 16:01 ` Dmitry A. Kazakov 2010-11-05 19:26 ` Jeffrey Carter 2010-11-05 19:34 ` Dmitry A. Kazakov 2010-11-05 19:35 ` Florian Weimer 2010-11-05 20:08 ` Dmitry A. Kazakov 2010-11-05 20:14 ` Florian Weimer 2010-11-05 21:01 ` Dmitry A. Kazakov 2010-11-05 20:45 ` Warren 2010-11-05 22:59 ` Brian Drummond 2010-11-09 20:29 ` Warren 2010-11-05 21:37 ` Jeffrey Carter 2010-11-05 3:10 ` Georg Bauhaus 2010-11-05 6:54 ` J-P. Rosen 2010-11-05 16:39 ` Robert A Duff 2010-11-05 23:32 ` J-P. Rosen 2010-11-06 0:55 ` Yannick Duchêne (Hibou57) 2010-11-06 13:40 ` Simon Wright 2010-11-05 17:29 ` Robert A Duff 2010-11-05 19:28 ` Jeffrey Carter 2010-11-05 23:09 ` Robert A Duff 2010-11-06 0:44 ` Jeffrey Carter 2010-11-06 21:10 ` Robert A Duff 2010-11-07 0:01 ` Brian Drummond 2010-11-07 20:41 ` Jeffrey Carter 2010-11-07 21:03 ` Yannick Duchêne (Hibou57) 2010-11-05 6:49 ` J-P. Rosen 2010-11-05 7:05 ` Florian Weimer 2010-11-05 7:20 ` J-P. Rosen 2010-11-05 17:39 ` Florian Weimer 2010-11-05 18:08 ` Georg Bauhaus 2010-11-05 23:36 ` J-P. Rosen 2010-11-06 1:05 ` Yannick Duchêne (Hibou57) 2010-11-05 10:58 ` Georg Bauhaus 2010-11-05 16:31 ` Dmitry A. Kazakov 2010-11-05 17:38 ` Georg Bauhaus 2010-11-05 17:31 ` Florian Weimer 2010-11-05 18:02 ` Georg Bauhaus 2010-11-05 23:29 ` J-P. Rosen 2010-11-06 0:00 ` Robert A Duff 2010-11-06 0:12 ` Simon Wright 2010-11-06 11:34 ` J-P. Rosen 2010-11-06 0:01 ` Georg Bauhaus 2010-11-09 20:43 ` Warren 2010-11-05 17:24 ` Robert A Duff 2010-11-05 20:05 ` Vinzent Hoefler 2010-11-05 22:28 ` Robert A Duff 2010-11-04 17:40 ` Jeffrey Carter 2010-11-05 17:15 ` Robert A Duff 2010-11-05 19:24 ` Jeffrey Carter 2010-11-05 22:52 ` Robert A Duff 2010-11-06 0:40 ` Jeffrey Carter 2010-11-06 7:12 ` Dmitry A. Kazakov 2010-11-06 10:13 ` Yannick Duchêne (Hibou57) 2010-11-06 11:00 ` Georg Bauhaus 2010-11-06 11:35 ` Dmitry A. Kazakov 2010-11-06 13:34 ` Simon Wright 2010-11-06 14:53 ` Dmitry A. Kazakov 2010-11-06 20:52 ` Shark8 2010-11-06 21:58 ` Yannick Duchêne (Hibou57) 2010-11-07 2:57 ` Shark8 2010-11-07 3:12 ` Yannick Duchêne (Hibou57) 2010-11-07 6:37 ` J-P. Rosen 2010-11-06 17:10 ` (see below) 2010-11-06 22:08 ` Niklas Holsti 2010-11-06 22:24 ` Yannick Duchêne (Hibou57) 2010-11-06 0:42 ` Shark8 2010-11-06 13:24 ` Robert A Duff 2010-11-06 21:20 ` Shark8 2010-11-06 22:12 ` Yannick Duchêne (Hibou57) 2010-11-16 20:33 ` Randy Brukardt 2010-11-06 1:33 ` Yannick Duchêne (Hibou57) 2010-11-04 17:49 ` Jeffrey Carter 2010-11-02 20:38 ` Beginners question: Compound types, how-to? Jeffrey Carter 2010-11-02 20:59 ` Britt Snodgrass 2010-11-03 0:46 ` Georg Bauhaus 2010-11-03 1:59 ` Yannick Duchêne (Hibou57) 2010-11-03 12:59 ` Georg Bauhaus 2010-11-03 15:28 ` Georg Bauhaus 2010-11-03 8:58 ` Dmitry A. Kazakov 2010-11-03 12:31 ` Georg Bauhaus 2010-11-03 12:18 ` Stephen Leake 2010-11-03 13:12 ` Georg Bauhaus 2010-11-04 0:55 ` Yannick Duchêne (Hibou57) 2010-11-03 17:35 ` Vinzent Hoefler 2010-11-03 21:19 ` Simon Wright 2010-11-03 21:31 ` Vinzent Hoefler 2010-11-04 5:25 ` Stephen Leake 2010-11-04 17:47 ` Jeffrey Carter 2010-11-04 6:11 ` Yannick Duchêne (Hibou57) 2010-11-04 19:30 ` Vinzent Hoefler 2010-11-04 17:42 ` Jeffrey Carter 2010-11-03 12:06 ` Stephen Leake 2010-11-04 1:04 ` Yannick Duchêne (Hibou57) 2010-11-04 17:11 ` Jeffrey Carter 2010-11-04 13:47 ` Peter C. Chapin 2010-11-04 14:30 ` Warren 2010-11-01 17:24 ` Yannick Duchêne (Hibou57) 2010-11-01 21:31 ` Simon Wright 2010-11-01 19:05 ` Jeffrey Carter 2010-11-01 11:50 ` (see below) 2010-11-01 17:16 ` Yannick Duchêne (Hibou57) 2010-11-01 17:27 ` Georg Bauhaus 2010-11-01 17:41 ` Yannick Duchêne (Hibou57) 2010-11-01 17:55 ` Yannick Duchêne (Hibou57) 2010-11-01 18:12 ` Adam Beneschan 2010-11-01 19:25 ` Jeffrey Carter 2010-11-01 12:03 ` Brian Drummond 2010-11-01 12:17 ` Florian Weimer 2010-11-01 13:05 ` Mart van de Wege 2010-11-01 22:45 ` Brian Drummond 2010-11-01 23:17 ` Yannick Duchêne (Hibou57) 2010-11-02 8:32 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox