From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8d472879e3f609e0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-03 10:21:28 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Case sensitivity (was Re: no title) Date: 03 Jun 2003 13:21:27 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <0vGdnQFmVPoZj0Gj4p2dnA@gbronline.com> <1054647054.761122@master.nyc.kbcfp.com> <1054651042.211055@master.nyc.kbcfp.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1054660887 2057 199.172.62.241 (3 Jun 2003 17:21:27 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 3 Jun 2003 17:21:27 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:38514 Date: 2003-06-03T13:21:27-04:00 List-Id: Hyman Rosen writes: > Preben Randhol wrote: > > It is far easier to rather better to use different > > words than to simply change the case. > > The point remains that I may want to use the same word > in different cases to mean different things. The C > example of upper case as the type and lower case as the > object is an example. Ada says I can't do that. Why? > Because having one English word mean two different things > is confusing? But Ada already allows that. So it's an > arbitrary decision made by people who don't like case > sensitivity forcing their view on those who do. Well, that last sentence is sort of silly. *Every* rule of every programming language is a decision made by people forcing their decision on other people don't like that rule. Call it an "arbitrary" rule, if you like. ;-) Anyway, what lots of folks seem to be missing is that there are more choices than "case sensitive" or "case insensitive". The rule I favor would be for overload resolution to be case insensitive, but to have an extra legality rule saying you have to use the right case. This is essentially what you get if you use the GNAT switch that somebody mentioned. For example: procedure FOO(X: Integer); procedure Foo(X: Boolean); Foo(True); would use types, and not case, to resolve which foo you're talking about (the Boolean one). But if you say: FOO(True); -- illegal it would still resolve to the Boolean foo, but you get an error because you spelled it with the wrong case. FOO(123) would be OK. If we further allow everything to be overloaded (not just subprograms, and then bogusly pretend that enumeration literals are subprograms), then your example: function Put(string: String); would be fine. Presumably, the "String" after ":" would resolve to the type name in Standard, since that's what is expected after ":". ("The type of type is type.") The case sensitive rule says you can declare "Foo: Integer; FOO: Integer;", which is clearly confusing. The case insenstive rule says you can't do that, but you can declare "Foo: Integer;" and then refer to it as FOO, which I think damages readability. The more complicated rule I outlined above solves *both* problems. Somebody elsewhere in this thread denigrated this: function Put(string: String); as being too "lazy" to come up with good names. I don't agree. We've had endless debates as to whether it should be "A_String: String" versus "String: String_Type" and all kinds of other variations on those. But it seems to me that "string/String" is a perfectly good name for a type, and for a parameter of that type. A_String doesn't help; it doesn't add any information (references make it obvious on context). And with this idea, case helps distinguish, but can never confuse. A language should not be about punishing programmers who are too "lazy" to jump through hoops, but should be about aiding the writing of readable code. Many folks have advocated using more-descriptive names for the objects. For example, City_Name instead of A_String. That's of course a good idea when there *is* a more descriptive name, but for general-purpose parameters, it doesn't work. Put takes *any* string; there is no adjective such that Adj_String would aid understanding of the program. Of course, neither the Ada rule nor the C rule is going to change. (I'm on the ARG, and I would certainly never vote for a grossly incompatible language change!) I just find it interesting to discuss better alternatives. - Bob