comp.lang.ada
 help / color / mirror / Atom feed
From: griest@MITRE.ARPA (Mr. Griest)
Subject: package SYSTEM
Date: Wed, 27-Nov-85 17:10:29 EST	[thread overview]
Date: Wed Nov 27 17:10:29 1985
Message-ID: <8511272210.AA16870@mitre.ARPA> (raw)




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

             reply	other threads:[~1985-11-27 22:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1985-11-27 22:10 Mr. Griest [this message]
  -- strict thread matches above, loose matches on Subject: below --
1985-11-28  1:38 package SYSTEM "David S. Bakin"
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox