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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,83d7c4caadb45100 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: DECAda/VMS - calling GETJPI Date: 1996/06/04 Message-ID: #1/1 X-Deja-AN: 158426385 references: <31B2AF74.668E@dial.eunet.ch> <4ouo97$pe8@gcsin3.geccs.gecm.com> <4ouuuv$6hd@linus.mitre.org> <4p183b$2vs@linus.mitre.org> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-06-04T00:00:00+00:00 List-Id: Mike Brenner says "That's quite right, GNAT gives the error message below, but in doing so it violates the Ada 95 Reference Manual and Rationale. Specifically, (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) Conversion from modular to signed integer types works in a useful manner so that overflow does not occur. (3.3.2 sixth paragraph) We can think" Yes, that's right GNAT violates the Rationale here. That's because the Rationale is wrong. TO be fair, the problem is that it reflects the language design as it was prior to the meeting in England. Mike, always read the RM, not the Rationale, when they disagree, the Ratoinale has no official status whatsoever. You cannot violate the Rationale really, since it is not an official document. You can disagree with it, and most certainly should, when the Rationale is incorrect. The RM is quite clear on this point (I notice you did not try to quote the RM to back up your incorrect interpretation, though it is certainly understandable that you would assume that what you read in the Rationale was correct). The conversion raises constraint error because the value in question is outside the range of the target type. Nowhere in the RM can you find a suggestion that modular types are treated specially in such conversions because there is no such special treatment. There are not many technical errors in the Rationale of this type. All the ones I know about are in this category, they reflect a change to the language made late on, where the Rationale did not track the change. It would be quite useful to have a comprehensive errata list for the Rationale, but I do not know of one. Anyway, bottom line, GNAT is right, Mike is wrong! P.S. for the RM archeologists, the most obvious reference is in section 4.6 28 For the evaluation of a type_conversion that is a value conversion, the operand is evaluated, and then the value of the operand is converted to a corresponding value of the target type, if any. If there is no value of the target type that corresponds to the operand value, Constraint_Error is raised; this can only happen on conversion to a modular type, and only when the operand value is outside the base range of the modular type. Additional rules follow: [seems clear enough to me!]