From kst@alsys.com Fri May 5 08:07:23 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA20664; Fri, 5 May 95 08:07:23 EDT Received: from gw.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA26040; Fri, 5 May 95 08:07:19 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA16439; Fri, 5 May 95 05:07:00 PDT Received: from pulsar.telesoft by rasht.alsys.com (4.1/TS-1.2b) id AA24473; Fri, 5 May 95 05:06:58 PDT Received: by pulsar.telesoft (5.x/SMI-SVR4) id AA17687; Fri, 5 May 1995 05:06:58 -0700 Message-Id: <9505051206.AA17687@pulsar.telesoft> From: kst@thomsoft.com (Keith Thompson) Date: Fri, 5 May 1995 05:06:57 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ada9x-mrt@inmet.com Subject: Reserved_128, etc. !topic Reserved_128, etc. !reference RM95-A.1(35) !keywords character, ISO 8859-1 !from Keith Thompson 95-05-05 <> !discussion Several of the control characters in type Character have (italicized) names starting with "Reserved", namely: Reserved_128 Reserved_129 Reserved_132 Reserved_153 If I understand correctly, these strings (mapped to upper case) are required to be the results returned by Character'Image; e.g., Character'Image(Character'Val(128)) = "RESERVED_128". I've seen a document that gives shorter names for these characters: 128 => PAD 129 => HOP 132 => IND 153 => SGCI (Sorry, I don't know where I saw these.) If these shorter names are valid, are implementations allowed/encouraged/required to use them instead of the longer names? It seems a pity to have Character'Width = 12 -- though inconsistency between implementations is probably worse. Note that the set of "Reserved" character names changed between draft 5.0 and the final version 6.0: 5.0 6.0 --- --- Reserved_130 --> BPH Reserved_131 --> NBH IND --> Reserved_132 Reserved_152 --> SOS Reserved_154 --> SCI If the names of the ISO 8859-1 characters are a moving target, how can Ada 95 best follow that target over the next Y+5 years (Y as in Ada 200Y)? My suggestion: Find out the "real" names of these characters and issue a ruling requiring these names to be used instead of Reserved_128, etc. -- *before* validated Ada 95 compilers start hitting the streets. From stt@dsd.camb.inmet.com Fri May 5 11:56:06 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA24437; Fri, 5 May 95 11:56:06 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA00706; Fri, 5 May 95 11:56:05 EDT Received: from spock.camb.inmet.com.i2ada by dsd.camb.inmet.com (4.1/SMI-4.1) id AA24434; Fri, 5 May 95 11:56:04 EDT Date: Fri, 5 May 95 11:56:04 EDT From: stt@dsd.camb.inmet.com (Tucker Taft) Message-Id: <9505051556.AA24434@dsd.camb.inmet.com> To: ada9x-mrt@inmet.com, ncohen@watson.ibm.com Subject: Re: Distribution questions !topic Ambiguous "only"; please clarify intent !reference RM95-E.2.2(14);6.0 !reference 95-5134.a Norman Cohen 95-05-04 !from Tucker Taft 95-05-05 <> !discussion > For a remote access-to-classwide type, "The primitive subprograms of the > corresponding specific limited private type shall only have access > parameters if they are controlling formal parameters...." > > This can be interpreted two ways: > > 1. Every controlling parameter of a primitive subprogram must be an > access parameter. > > 2. Every access parameter of a primitive subprogram must be a controlling > parameter. > > Which do you mean? Number 2. You generally aren't allowed to pass non-remote access values between partitions. However, when the access value is a controlling access parameter for a remote access-to-class-wide type, the caller passes in a remote access type, but by the time you get to the "real" body, it is guaranteed that the access parameter designates a local object. !topic {user-defined} Read and Write attributes !reference RM95-E.2.2(14);6.0 !reference 95-5134.b Norman Cohen 95-05-04 !from Tucker Taft 95-05-05 <> !discussion > "... the types of all the noncontrolling formal parameters shall have > Read and Write attributes." > > By 13.13.2(2), this is vacuously true. The wording of 13.13.2(2) is misleading. Limited types don't have a default implementation for the Read and Write attributes, per 13.13.2(36). Clearly 13.13.2(2) should be reworded to make it clear that although the attributes are in some sense "defined," it is illegal to evaluate them for limited types unless the user specifies them. > ... Do you mean USER-SPECIFIED > Read and Write attributes, as suggested by the note in E.2.2(18)? > (That would be a strange requirement for, say, a parameter of type > Integer, but the obvious alternative interpretation also seems strange.) No. The intention was to disallow limited types unless they have user-specified 'Read/'Write. !topic Can an RCI unit be a library subprogram? !reference RM95-E.2.3(7);6.0 !reference 95-5134.c Norman Cohen 95-05-04 !from Tucker Taft 95-05-05 <> !discussion > Is it intended that an RCI unit can only be a package? I cannot find > any such restriction in the RM. In particular, given the definition of > the visible part of a callable entity in 8.2(6), a subprogram is > "declared in the visible part of" a library subprogram, thus qualifying > as a remote subprogram according to E.2.3(7). Yes, a single library subprogram can be an RCI unit, as can a generic library unit. -Tuck From kst@alsys.com Fri May 5 20:57:41 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA19620; Fri, 5 May 95 20:57:41 EDT Received: from gw.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA11997; Fri, 5 May 95 20:57:34 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA22762; Fri, 5 May 95 17:57:34 PDT Received: from pulsar.telesoft by rasht.alsys.com (4.1/TS-1.2b) id AA15879; Fri, 5 May 95 17:57:32 PDT Received: by pulsar.telesoft (5.x/SMI-SVR4) id AA09799; Fri, 5 May 1995 17:57:31 -0700 Message-Id: <9505060057.AA09799@pulsar.telesoft> From: kst@thomsoft.com (Keith Thompson) Date: Fri, 5 May 1995 17:57:30 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ada9x-mrt@inmet.com Subject: File sharing, Standard_Input, Standard_Output !topic Reserved_128, etc. !reference RM95-A.7(1) !reference RM95-A.14 !from Keith Thompson 95-05-05 <> !discussion A.14(3) says that "Standard_Input and Standard_Output are associated with distinct external files". This is not necessarily true. For example, in a typical Unix-based implementation, both Standard_Input and Standard_Output may be associated with the same tty device and have the same name ("/dev/pts/23" or whatever). In particular, A.7(1) says that "An external file is identified by a string (the name)", implying that two external files cannot have the same name, an unreasonable (and I presume unintended) requirement for Standard_Input and Standard_Output. Furthermore, the statement that they are associated with distinct external files is not necessary to support the remainder of the paragraph, which refers to effects on page, line, and column numbers. These are presumably properties of the file objects, not of the external file(s). There should probably also be some mention of Standard_Error here.