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,d2c21e8238e985b5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-25 08:57:11 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Extended modal types Date: 25 May 2002 08:57:11 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0205250757.60c9715a@posting.google.com> References: <3CEDFF90.B94D7E32@yahoo.com> NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1022342231 28104 127.0.0.1 (25 May 2002 15:57:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 25 May 2002 15:57:11 GMT Xref: archiver1.google.com comp.lang.ada:24768 Date: 2002-05-25T15:57:11+00:00 List-Id: Anatoly Chernyshev wrote in message news:<3CEDFF90.B94D7E32@yahoo.com>... > and one cannot use arbitrary modular > range, > for example, like -100..345. I can't even guess what an arbitrary modular range might be. Modular refers to the fact that integer values are represented by their (positive) remainder value when divided by the modulus in use. Thus modular types can never have negative numbers. If you are talking about wrap around types, then sure you can get the effect you want. For example, in the above case, you can define a type that is type r is mod 446; Now you represent numbers in the range -100 .. 345 using this type, and for example if you say rr : r := -100; then the actual value would be 346. The only thing you might want is an output routine that understands this convention (which in fact is very similar to how twos complement works). But this is all a guess, since the term extended modular type is meaningless. Also I must say it is plain bizarre to get excited about the prospect of such a peculiar special purpose feature (to me even allowing non-binary modulus values is a mistake. Actually a bit of history as to how this mistake came to pass is of interest: The URG agreed to provide unsigned types using a modular type approach with binary modulus values that corresponded to natural word sizes of the machine (much as C does). We agreed to extend it to arbitrary powers of 2, since an AND instruction is cheap on all machines. Someone proposed (Bryce Bardin perhaps, apologies if that is a wrong memory) extending this to non-binary values. The vote in the URG was N-1 *against* this extension on the grounds that it was frivolous (you can always program this if you need it). The Ada 9X design team put in general modular types, and I and a couple of other people complained that it was a feature that could not be justified. Tuck and Bob responded that they had a commitment to implement the URG recommendations, and claimed that the URG had recommended this. As chair of the URG, I knew just how wrong this was :-) Turned out they had used as gospel the rejected proposal for general modular types, assuming that the URG had accepted it. By that time, the feature was out, and featuritis had set in and enough people were in favor that it stayed in. Since it was not that much of a pain to implement, it was not worth fighting. But I find it a bit of nonsense in the language (especially the weird semantics of NOT. For example: with Text_IO; use Text_IO; procedure q is type r is mod 446; x : r := 13; begin Put_Line (r'Image (not x)); end; prints 432, and I do not find anything reasonable or intuitive about that result :-) To me this is orthogonality in language design run amok!