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=0.2 required=5.0 tests=BAYES_00,HK_NAME_MR_MRS, INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-ada From: griest@MITRE.ARPA (Mr. Griest) Newsgroups: net.lang.ada Subject: package SYSTEM Message-ID: <8511272210.AA16870@mitre.ARPA> Date: Wed, 27-Nov-85 17:10:29 EST Article-I.D.: mitre.8511272210.AA16870 Posted: Wed Nov 27 17:10:29 1985 Date-Received: Fri, 29-Nov-85 00:11:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: In the past year or so, I have heard various interpretations (by language experts) of what can be implemented in package "SYSTEM". The informal 'ruling' that I have been given recently is that the implementor is free to place anything they desire in SYSTEM. I would like to encourage a little more discussion about this matter, since I feel the general Ada community may not be aware of this issue. What brought this issue to my attention was the "dynamic priorities" problem in Ada. That is, how can dynamic priorities be supported without violating the Standard. It has been explained that this is not a problem at all, and that an implementor is free to restrict the range of 'PRIORITY' to null and implement their own 'DYNAMIC_PRIORITY' type that can be manipulated with procedures provided in SYSTEM. I think it is safe to say that many, if not most programmers using Ada would say that Ada does not support dynamic priorities. Surprise! You say you want semaphores and signal & wait operations for tasking? Just ask your friendly compiler implementor to put it in SYSTEM. As long as the syntax and semantics fit, here is the place to extend the language! The questions are: Is this really allowable? If so, what is the likely impact on transportability (including the education problem)? RM 13.7(1) states: "For each implementation there is a predefined library package called SYSTEM which includes the definitions of certain configuration-dependent characteristics. The specification of the package SYSTEM is implementation-dependent and must be given in Appendix F. The visible part of the package must contain at least the following declarations...." My impression is that the operative word is CHARACTERISTICS. This implies to me that package SYSTEM is there to provide information about the configuration, not functionality! Secondly, if this is allowed, I am convinced users are going to demand that implementors provide all kinds of strange routines that permit user access to the run-time. I fear the 'Ada' tasking model will be replaced by what programmers are familiar with (which is different for each development lab). Well, I'll flame off and see if I stirred any interest. Tom Griest, LabTek Corporation GRIEST@MITRE