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,16e3a8dd4f3ab3f3 X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Elaboration order Date: 1996/03/22 Message-ID: #1/1 X-Deja-AN: 143620277 references: <314701A1.469D@lfwc.lockheed.com> organization: The Mitre Corp., Bedford, MA. newsgroups: comp.lang.ada Date: 1996-03-22T00:00:00+00:00 List-Id: In article emery@grebyn.com (David Emery) writes: > Of course, there wasn't time to type in the program so Eachus scribbled > it down on the side of an old printout, which he has subsequently > lost :-) :-) I did NOT, I actually threw it at a couple of Ada 80 compilers to see what happened, but the compiles never finished. :-( When Ada 83 compilers came along, they produced code which just sat there burning cycles, and never got to the main program. (If there was a non-trivial solution to A**N + B**N = C**N for N > 2, the program would eventually raise Program_Error. Since it was using an arbitrary precision arithmetic package, it would probably have raised Storage_Error eventually, but I never ran it that long.) However, the Ada 80 program that really got me in trouble was the one that showed a flaw in one implementor's approach to elaboration of accept entries. With a pair of nested accepts for the same entry with an unconstrained array parameter, I showed just what a bad an idea that implemetation was. Ada 83 and Ada 95 both have a prohibition of nested accept statements for the same entry as a result. As a result I made a vow NEVER to put code on a blackboard or overhead if I don't want people actually compiling it. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...