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,b084786fb95b5938
X-Google-Attributes: gid103376,public
From: claveman@cod.nosc.mil (Charles H. Sampson)
Subject: Re: Adding Things to Package System
Date: 1999/02/26
Message-ID: <1999Feb26.202551.9334@nosc.mil>#1/1
X-Deja-AN: 449229956
Sender: news@nosc.mil
References: <1999Feb18.192159.18832@nosc.mil> <36D31FC0.A39BEBAA@averstar.com>
Organization: Computer Sciences Corporation
Newsgroups: comp.lang.ada
Date: 1999-02-26T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <36D31FC0.A39BEBAA@averstar.com>,
Tucker Taft  <stt@averstar.com> wrote:
>Charles H. Sampson wrote:
>> 
>> ... yet this is legal code that the
>> compiler can't handle, in violation of 1.1.3(2).
>
>It is not portably "legal" code, unfortunately.  It is
>code that is legal if there are no additions to package
>System, but as you point out, additions to package System
>are permitted.
>
>>      Am I correct in assuming that 1.1.3(2) rules?
>
>No.  Your code is not "universally" legal.  To
>minimize non-portabilities, remove any "use" for package System.
>Use a rename if you find "System." too painful an addition
>at every reference to some declaration in package System.
>
     While the discussion to date has been interesting, I was just 
about to post a followup noting that no one had responded to my pointing 
out that three paragraphs of the LRM are in conflict.  Then Tucker Taft 
took care of that, as he often does.

     I'm not really happy with Tucker's response, but I'm not too sur-
prised either.  I am a little surprised about a couple of terms that I'm 
not familiar with: "portably 'legal' code" and "'universally' legal".  
Other than that, I suppose that the demon Practicality is going to com-
mand that additions to System be allowed in the near term.  Perhaps in 
Ada 200X, ...

     Still, even though it's not surprising, saying that 1.1.3(2) is 
not a hard rule is disturbing.  Robert Dewar and I agree that additions 
to System are a poor idea.  Matthew Heaney has given an example of some 
spectacularly injudicious additions.  In spite of that, the rule that a 
conforming implementation must handle all legal Ada programs is "bent" 
to allow these additions.  (I haven't been able to find the definition 
of a legal Ada program, using the index of the LRM as my main tool.  My 
guess would be that it is a program written in the language as described 
in the LRM.  In that case, my program was legal.)

     I almost always write highly portable code.  I do it by being very 
careful of how I use those features that have implementation dependen-
cies and by not using implementation additions unless absolutely neces-
sary.  However, in the present example, I was tripped up by an addition 
that I wasn't using.  I guess I felt a little let down by the LRM.

     Yes, there are a number of ways of getting around the problem of 
additions to System, but I don't see why I should have to.  I would like 
to see some authority (is an ARG 95 in business?) come out very strongly 
in favor of the second sentence of 13.7(36): Any additions to System 
should be done in a child package rather than in System itself.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".