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-Thread: 103376,5c3042563529d4f3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.73.229 with SMTP id o5mr2166637pbv.7.1326499794887; Fri, 13 Jan 2012 16:09:54 -0800 (PST) MIME-Version: 1.0 Path: lh20ni179168pbb.0!nntp.google.com!news1.google.com!feed-C.news.volia.net!volia.net!news2.volia.net!feed-A.news.volia.net!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Data_Error and Enumeration_IO Date: Fri, 13 Jan 2012 18:09:48 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3f3d626a-1b8c-49af-aa85-9e586029a817@z12g2000yqm.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1326499793 26072 69.95.181.76 (14 Jan 2012 00:09:53 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 14 Jan 2012 00:09:53 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-01-13T18:09:48-06:00 List-Id: "Jeffrey Carter" wrote in message news:jeq9ib$1ouu$1@adenine.netfront.net... > On 01/13/2012 02:30 PM, John McCormick wrote: >> >> Never be surprised about another's ignorance. I wasn't in the Ada >> world during the discussions in the 1980s. The only thing in Jeff's >> and Georg's notes of which I had not known was the reference to the >> material on Data_Error and real types. From that it seems that the >> parsing of a potential floating point number uses knowledge of >> previously entered characters. For example, if you enter "1.2E." it >> recognizes that the second decimal point is an error. Yet when you >> enter "abc" in my original example for enumeration IO, it cannot >> recognize that no valid enumeration literal starts with an a. It has >> to process the entire identifier before it can see that. So the crux >> of my question is why doesn't the consumption of characters for >> enumeration input behave like that of real input. It doesn't really >> matter other than to satisfy my curiosity. > > The consumption of characters is the same in both case: they consume > characters as long as the characters follow the syntax of a literal for > the type class (the class of floating-point types in one case, of > enumeration types in the other). For floating-point types, that's anything > that's a valid real literal, even if it's outside the range of the type. > For an enumeration it's anything that's a valid identifier or character > literal. Equivalent examples to "1.2E." for an enumeration type are "'ab" > or "a_*". Note that enumeration input will consume all of "'a'" even if > the enumeration type has no character literals. Right. The important point here is that the consumption of characters is not related in any way to the actual subtype being read; it only depends on the syntax of the appropriate literals. When you ask why "abc" is read even if there is no literal that begins with 'a', imagine a similar case for a real number: subtype Nines is Float range 9.0 .. 9.9; If a Get for Nines is given "1.2", this will be completely read even though no legal value of subtype Nines could start with '1'. As to why it is done this way, it's hard to imagine how else it could be done. To reject the "abc" example at the 'a', for instance, we would have to do a brute force search in a table of potentially hundreds of enumeration literals to see if any start with 'a', then repeat that to see if any start with "ab", and so on. If the literals are long and the number of literals is high, this is going to be a N**2 algorithm -- and I don't think I want my input to do that (there is a built-in denial of service possibility). Randy.