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,fd3a5ba6349a6060 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Semantic info pragmas (was: should I be interested in ada?) Date: 1999/03/01 Message-ID: #1/1 X-Deja-AN: 450012717 Sender: bobduff@world.std.com (Robert A Duff) References: <7a72e6$g55$1@probity.mcc.ac.uk> <36C93BB4.1429@ecs.soton.ac.uk> <7afc1o$3mi$2@plug.news.pipex.net> <7afttr$7v3$1@nnrp1.dejanews.com> <7aganu$qsc$1@plug.news.pipex.net> <36CC3AEA.59E2@lanl.gov> <7ai502$6an$1@nnrp1.dejanews.com> <36CD8DBA.237C@lanl.gov> <7b2545$4qd$2@plug.news.pipex.net> <7b8cv9$ii5$1@plug.news.pipex.net> <87hfs5juyx.fsf@zaphod.enst.fr> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-03-01T00:00:00+00:00 List-Id: Samuel Tardieu writes: > >>>>> "Nick" == Nick Roberts writes: > > Nick> RM95 2.8(16) states "Normally, implementation-defined pragmas > Nick> should have no semantic effect for error-free programs; ...," so > Nick> I should have said 'shouldn't' rather than 'can't'. I think > Nick> this is an area where there would be no good excuse for > Nick> introducing implementation-defined pragmas which did change the > Nick> semantics. There's an important difference between "shouldn't" and "can't". A bit of history: During the language design, Tucker wanted to put in a "shall" rule along the lines of the above. I wanted to leave it out, and rely on implementer's "good taste" to prevent really awful pragmas. We argued strongly, and eventually compromised on putting in the rule, but weakening it by labelling it "Implementation Advice", and using "should". That compromise was unusual -- for most design decisions, we either agreed, or kept arguing until we did agree. ;-) (I don't think you can capture "good taste" in a rule. But as a guideline, I think pragmas shouldn't have a "strong" effect on the semantics of working programs, whatever that means. A pragma that restricts is usually in good taste.) > "Normally" means "except where specified", right? Because pragma > Asynchronous certainly does change the semantics of a procedure call > in regard with exceptions. I wrote "Normally" deliberately to further weaken the rule. I meant it to indicate that there are perfectly reasonable pragmas that would violate the rule. Asynchronous is an interesting example: During the language design, we had a meta-rule: any feature we put in one of the optional annexes had to be something that a compiler vendor could have "legally" added to the language as an implementation-defined feature. So in the optional annexes, you will find pragmas, attributes, packages, and some nailing-down of semantics that is looser in the core language. You will certainly not find any new syntax. Anyway, given the meta-rule, we had to construct the rules about pragmas to allow us to do what we wanted in the optional annexes. Actually, I think pragma Asynchronous is kind of in bad taste. It has such a strong effect on procedure-call semantics that I think it deserves its own syntax. But we wanted to put it in the optional annex, so our hands were tied (by ourselves, to some extent!). - Bob -- Change robert to bob to get my real email address. Sorry.