[net.lang.ada] package SYSTEM

griest@MITRE.ARPA (Mr. Griest) (11/28/85)

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

Bakin@MIT-MULTICS.ARPA ("David S. Bakin") (11/28/85)

1)  Just for information, DEC Ada puts in system functions dealing
with manipulations on type ADDRESS, PEEK and POKE type routines,
definitions of the 4 VAX floating point types, definitions related
to VMS stuff like ASTs (asynchronous system traps) and non-Ada
exceptions, and operations on unsigned bytes and arrays of bits.

2)  Just for information Alsys Ada puts in SYSTEM functions
dealing with manipulations on type ADDRESS, PEEK and POKE type routines,
and (depending on the particular target) convenient declarations on
other types such as unsigned bytes.

3)  What do other compilers have in package SYSTEM?

4)  I don't understand why the "dynamic priority" problem is a problem
of package SYSTEM.  Although SYSTEM seems a place for it at the implementor's
choice, if forbidden to put such a thing in SYSTEM why can't he put it
somewhere else (i.e., a different library package, or a different
pragma)?

5)  Lets say you'd like your Ada compiler to offer 'freebies' (that is
features not mandated by the language) such as convenient operations on
packed arrays of bits (e.g., "and", "or" operators).  Then do you prefer
to have them in package SYSTEM or in some other library package?  I'm
asking because I'd really like to know the opinion of user's.  To me
it doesn't seem to make any difference because its not portable to use
such features anyway, the only thing I could say is that having them
in SYSTEM is a convenient "flag" to the reader when he sees the context
clause at the top of the module -- the same argument which was first
applied to the use of UNCHECKED_CONVERSION, UNCHECKED_DEALLOCATION.

6)  Does anyone think an implementor is going to put hooks in to the
run-time system to allow non-Ada tasking?  Does anyone think an implementor
is going to be asked by a user to do such a thing?  Does any user PLAN to
ask such a thing?  I think it much more likely that an implementor will be
asked to adapt his run-time system to implement Ada tasking semantics on
top of an existing OS or monitor program than be asked to implement non-Ada
tasking semantics.

-- Dave

(Normal disclaimer about me and my big mouth vs. Alsys and its corporate
policy.)