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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6f69b1cf0f02b9ac X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-22 08:30:09 PST Path: supernews.google.com!sn-xit-02!sn-xit-04!supernews.com!xfer13.netnews.com!netnews.com!newsfeed.skycache.com!Cidera!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: mark_lundquist@my-deja.com Newsgroups: comp.lang.ada Subject: Re: Built-in types (was Re: How can I avoid Using a Semaphore? Date: Mon, 22 Jan 2001 16:18:42 GMT Organization: Deja.com Message-ID: <94hmgo$o2k$1@nnrp1.deja.com> References: <93ti8b$bjpps$1@ID-25716.news.dfncis.de> <9BP86.270637$U46.8654942@news1.sttls1.wa.home.com> <94563n$cb6kp$1@ID-25716.news.dfncis.de> <0Cka6.290338$U46.9207275@news1.sttls1.wa.home.com> <94co6t$v27$1@nnrp1.deja.com> <94f1a8$k9r$1@nnrp1.deja.com> <94fv9d$cjt$1@nnrp1.deja.com> <94g3tf$gb9$1@nnrp1.deja.com> NNTP-Posting-Host: 130.213.203.87 X-Article-Creation-Date: Mon Jan 22 16:18:42 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Http-Proxy: 1.1 x52.deja.com:80 (Squid/1.1.22) for client 130.213.203.87 X-MyDeja-Info: XMYDJUIDmark_lundquist Xref: supernews.google.com comp.lang.ada:4310 Date: 2001-01-22T16:18:42+00:00 List-Id: In article <94g3tf$gb9$1@nnrp1.deja.com>, Robert Dewar wrote: > In article <94fv9d$cjt$1@nnrp1.deja.com>, > mark_lundquist@my-deja.com wrote: > > > > When a careful Ada programmer writes 'Integer', he's saying > > that he understands the things about Integer that are > > implementation-defined and that those things are "don't > > cares" for him in this instance. It's not careless to say > > that and mean it. > > It is never actively *useful* to be able to do this, since > you certainly have *some* requirements on any type you supply, > and you may as well make them explicit. Couldn't it be that my only requirement is that this be (using the example of integer types) the "whatever integer"? If that's my only requirement, then I'm being explicit about it when I write "Integer", because that's what Integer is supposed to be -- the "whatever integer". Anything else that I might specify is in fact *not* a requirement for me. (Let's see, just for integer types, what can the programmer specify? There's base range, size, alignment, stream I/O attributes... anything else?) > > The trouble is that 90% of programmers writing Integer > explicitly do NOT know what they are saying, and make a mess. > That is why most coding standards wisely suggest not using > type Integer. Well that's just it... it seems like if the programmer is sharp enough to specify all this stuff, then he also ought to be sharp enough to know when he means the "whatever" types and to use them when that's what he means. I suppose if it were a choice between the programmer blindly using Integer for everything (considerations of scalar abstraction aside), and blindly specifying everything because a style guide told him to do so, then I guess I'd prefer the latter (but not by much; see below...) However, that is a truly bonehead operating level and if these were really the only alternatives I doubt I'd want that programmer writing code for anything I cared about! :-) I mean, if you're going to go to the trouble to make a style guide that tells them to specify down to the gn@t'$ @$$ whether they depend on it or not, and expect them to follow it, then is it really that hard to teach them what Integer means? Then give advice with some substance, like "don't write a record component of type Integer if you're going to apply a representation clause" -- in which case you know your code will still compile if it's ported to another platform. You may or may not care about slightly different behavior, but you do care that it compile! :-) Is it OK to use the predefined Float type? :-) Suppose I nail down the precision and/or range to something I think makes sense for a particular architecture... might that not result in less-than-optimal performance if my code is ported to joe random architecture? So that's the whole point of having the "whatever" types. You need to be able to say "whatever". The issue is that people know when they're saying "whatever" and that they don't say it when they don't mean it. There was a thread here last year, in which someone was lamenting that Ada's integer types were not as "portable" as Java's because the language doesn't nail standardize the sizes/ranges. I argued that (a) there are different kinds of portability, and (b) of the two kinds relevant to the argument, Java provides one, and Ada provides both, but that (c) the objector was looking in the wrong place in Ada for the Java-style portable integer types -- the right place is not the Standard integer types but the ones in package Interfaces. Once again, you want to be able to say "whatever". Now, I do have a beef with overspecification, because it obscures. I'm always looking for communication of design intent. So if I see an integer type declared, and there's no abstraction involved, and we're nailing down the size, then I say "OK, what intent is being captured here -- where are the bits that depend on this?" It's quite annoying when the answer is "Nothing really depends on it, we just specified because it's bad not to specify everything". > There are some exceptions, e.g. as the subscript > of the standard type String, and you cannot get away from this > built in type, because of library usage. > > P.S. Jean Ichbiah feels it was a bad mistake to have had the > type Standard.String depend on Integer in this way, but it was > too late to change. Changing the subject, speaking of strings... it seems a little unfortunate that Ada95 has 3 kinds of strings (not counting the dimension of standard vs. wide), all with essentially the same interface, and no abstraction of that interface. As a result, generic programming across the string types doesn't come naturally, although I guess this can be more-or-less fixed outside the language with wrapper classes. Best Regards, mark Sent via Deja.com http://www.deja.com/