CVS difference for ais/ai-00195.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00195.txt

--- ais/ai-00195.txt	1999/03/05 00:59:41	1.8
+++ ais/ai-00195.txt	1999/03/13 01:36:22	1.9
@@ -1,4 +1,4 @@
-!standard 13.13.1 (00)                                99-02-23  AI95-00195/03
+!standard 13.13.1 (00)                                99-03-12  AI95-00195/04
 !class binding interpretation 98-03-27
 !status work item 98-04-04
 !status received 98-03-27
@@ -7,14 +7,15 @@
 !priority High
 !difficulty Hard
 !subject Streams
-!summary 99-02-23
+!summary 99-03-12
 
 1 - When the predefined Input attribute creates an object, this object
 undergoes default initialization and finalization.
 
 2 - In determining whether a stream-oriented attribute has been specified for
 a limited type, the normal visibility rules are applied to the
-attribute_definition_clause.
+attribute_definition_clause.  A stream-oriented attribute may be specified
+before the type has been fully defined.
 
 3 - For a derived type which is limited (tagged or not), the attributes Read
 and Write are inherited, and the attributes Input and Output revert to their
@@ -149,7 +150,7 @@
 
 See summary.
 
-!discussion 99-02-23
+!discussion 99-03-12
 
 1 - It seems logical to make Input follow as closely as possible the semantics
 of code that could be written by a user, so the implementation of S'Input
@@ -198,6 +199,18 @@
 Read above were moved to the visible part of P, a reference to P.T'Read would
 still be illegal (but a reference to P.Read wouldn't).
 
+For limited types, this rule creates another problem: RM95 13.1(9) states
+that a representation item shall only appear after the type has been
+completely defined.  This would require the attribute_definition_clause to
+appear in the private part, thus being invisible to clients of the package.
+
+RM95 13.1(9) is in fact unnecessary for stream attributes: to quote AI-00137
+(which states that RM95 13.1(10) doesn't apply to stream-oriented attributes)
+"the stream-oriented attributes, although they are formally defined to be
+"representation attributes", do not actually affect the representation of the
+type."  Therefore, we must amend RM95 13.1(9) so that it doesn't apply to the
+stream-oriented attributes.
+
 3 - AI95-00108 states that "for a type extension, the predefined Read
 attribute is defined to call the Read of the parent type, followed by
 the Read of the non-inherited components, if any, in canonical order."
@@ -635,10 +648,6 @@
 
 ****************************************************************
 
-From: 	Stephen Leake
-Sent: 	Tuesday, March 17, 1998 8:45 PM
-Subject: 	Ada Issue; 16 bit integers in streams
-
 !topic Stream size of 16 bit integers
 !reference 13.13.2 (17)
 !from Stephen Leake 98-03-14
@@ -746,8 +755,8 @@
 chosen to be a 32-bit range because that is the kind of arithmetic
 that is efficient.  On many RISC architectures, that is the only
 kind of arithmetic, yet even on those architectures, one would presumably
-want types whose first subtype range fits easily in 16 bits to 
-occupy no mor than 16 bits in the stream.  
+want types whose first subtype range fits easily in 16 bits to
+occupy no mor than 16 bits in the stream.
 
 So the real problem seems to be the connection between base range
 and stream representation.
@@ -758,7 +767,7 @@
 if you go outside the base range.  For such a type it turns out that
 the base range would be pretty meaningless, except as it determines
 the number of stream elements per item written to the stream.
-Or equivalently, the "pretend" 16-bit base range would be checked 
+Or equivalently, the "pretend" 16-bit base range would be checked
 by T'Write on output, and result in a Constraint_Error if exceeded,
 but the base range would be irrelevant pretty much everywhere else.
 
@@ -810,7 +819,7 @@
 'Size, rounded up to some multiple of the stream element size in bits.
 
 This seems to me like a good solution to the problem that int-type'Base'Size
-might always be 32-bits on modern RISC machines, even though users 
+might always be 32-bits on modern RISC machines, even though users
 expect integer types with first subtype 'Size of 9..16 or 1..8 bits to
 be represented in the stream with 16 or 8 bits per item, respectively.
 
@@ -862,13 +871,13 @@
 
 For essentially all modern RISC machines, all arithmetic is done in
 32 bits, and the only overflow bit or signal available relates
-to overflowing 32 bits.  Presuming 'Base'Size reflects the size of 
-arithmetic intermediates, 'Base'Size might very well be 32 for all integer 
+to overflowing 32 bits.  Presuming 'Base'Size reflects the size of
+arithmetic intermediates, 'Base'Size might very well be 32 for all integer
 types, even for integer types declared with tiny ranges.
 
 > I am a bit dubious about this change ...
 
-Please elaborate.  
+Please elaborate.
 
 Note that this is a real problem now, because some Ada 95 compilers
 are using 32 bits per item for all integer types in streams, even for
@@ -910,7 +919,7 @@
 it is a bad choice to have a single 32-bit base type.
 
 The statement about CISC machines is incorrect, the x86 provides the
-same efficiency for 8-bit arithmetic with overflow detection as for 
+same efficiency for 8-bit arithmetic with overflow detection as for
 32-bit arithmetic with overflow detection, and 16-bit ariythemtic
 with overflow detection is only very slightly less efficient.
 
@@ -940,7 +949,7 @@
 sounds like just a wrong decision in choice of base types. That is why I
 am dubious about the need for the extra complexity.
 
-Tuck, can you be more clear on why it ever makes sense to follow this 
+Tuck, can you be more clear on why it ever makes sense to follow this
 approach of having a single 32-bit base type.
 
 ****************************************************************
@@ -958,7 +967,7 @@
 only 8 bits to be used for "8-bit" integer types.  Nevertheless,
 'base'size is definitely 24 bits for such machines.
 
-On many RISC machines, loading, storing, and passing objects of less 
+On many RISC machines, loading, storing, and passing objects of less
 than 32-bits can be less inefficient.  For such machines, it makes
 sense for 'Base'Size to be 32 bits even for tiny ranges.
 
@@ -1035,7 +1044,7 @@
 -- that was certainly the intent.
 >>
 
-It is not surprising that Bob Duff is surprised by this, because it is 
+It is not surprising that Bob Duff is surprised by this, because it is
 closely related to the whole business of the "wrong" size stuff in the RM.
 
 It is a significant mistake in an implementation to by default have objects
@@ -1162,7 +1171,7 @@
 
 In Ada 95, it was specifically defined with respect to type sizes, in a
 manner that was incompatible with most Ada 83 compilers and which causes
-a lot of problems. 
+a lot of problems.
 
 Ada 95 copied Ada 83 in not providing a way to specify default object
 sizes, but the problem is suddenly much worse in Ada 95. This is because
@@ -1193,8 +1202,8 @@
       to the properties of the first subtype.
 
 Choosing (1) above means specifying the algorithm for choosing
-the base range in terms of the first subtype size relative to the size 
-of the storage element, the word size, etc.  
+the base range in terms of the first subtype size relative to the size
+of the storage element, the word size, etc.
 
 Choosing (2) means specifying the algorithm for choosing the
 stream representation in terms of the first subtype size relative to
@@ -1310,7 +1319,7 @@
 all interesting machines have 32 bit integers.
 
 I would expect Bob Duff's particular set of declarations to be aiming at
-an efficient 16-bit type if anything, although after learning of the 
+an efficient 16-bit type if anything, although after learning of the
 peculiar choice of some compilers to fail to provide a 16-bit base type
 on machines where I would have expected it to be present (e.g. SPARC), it
 is clear that this is a highly non-portable idiom.
@@ -1411,22 +1420,22 @@
 > although it is a pity that there is so much implementation dependence
 > here. For interest what do other compilers do between the two following
 > choices on e.g. the SPARC:
-> 
+>
 >   1) Multiple integer base types, 8,16,32 bits
 >   2) Single integer base type 32 bits
-> 
+>
 > (just ignore the presence of absence of a 64-bit integer type for this
 > purpose).
-> 
+>
 > I underdstand the answers to be:
-> 
+>
 >   GNAT: 1)
 >   Intermetrics: 2)
-> 
+>
 > But what do other compilers do?
 
-The Intermetrics front end is happy to support either choice for 
-base types.  I believe Aonix and Green Hills both chose to have 
+The Intermetrics front end is happy to support either choice for
+base types.  I believe Aonix and Green Hills both chose to have
 only 32-bit base types.
 
 The Raytheon "Patriot" compiler has only one 24-bit base integer
@@ -1531,7 +1540,7 @@
 Subject: 	Re: AI-195; Stream representation for scalar types
 
 I forget the name of the encoding scheme that DCE RPC uses, but it's much
-better than XDR, particularly in homogenous networks.  In fact, I argued to 
+better than XDR, particularly in homogenous networks.  In fact, I argued to
 Anthony Gargaro that the DS Annex should take a 'minimalist' approach and
 consist of binding methods to RPC and associated data encoding schemes such
 as XDR.   I'm still sorry that the DS Annex didn't provide this simplistic
@@ -1554,11 +1563,11 @@
 since it's proven to be very useful.
 >>
 
-It's quite trivial in GNAT to provide a plugin replacement unit that 
+It's quite trivial in GNAT to provide a plugin replacement unit that
 specifies what protocol you want. I think this is a design that is
 very attractive (see s-stratt.adb in the GNAT library).
 
-Incidentally we use XDR *precisely* to deal with heterogenous networks. 
+Incidentally we use XDR *precisely* to deal with heterogenous networks.
 THe default encodings work perfectly well on homogenous networks. I
 suppose one could worry about different compilers being used on a
 homogenous network, but that seems somewhat theoretical so far.
@@ -1573,12 +1582,12 @@
 
 From: 	Anthony Gargaro[SMTP:abg@SEI.CMU.EDU]
 Sent: 	Wednesday, April 15, 1998 7:43 AM
-Subject: 	Re: AI-195; Stream representation for scalar types 
+Subject: 	Re: AI-195; Stream representation for scalar types
 
 Dear David-
 
 >I forget the name of the encoding scheme that DCE RPC uses, but it's much
->better than XDR, particularly in homogenous networks.  
+>better than XDR, particularly in homogenous networks.
 
 It is called Network Data Representation (NDR) transfer syntax (refer
 X/Open DCE: Remote Procedure Call, Chapter 14) and is the default transfer
@@ -1611,7 +1620,7 @@
 
 I've forgotten who was working on AI-195, but a news thread
 on comp.lang.ada illustrates that we need to address this sooner
-rather than later.    
+rather than later.
 
 In the comp.lang.ada posting, someone was quite confused by the
 fact that a type declared via:
@@ -1621,7 +1630,7 @@
 ended up taking 16 bits per item when written out using 'Write,
 even though Byte'Size is clearly 8.
 
-In my earlier note, I noted that 'Base'Size might be 32 in some 
+In my earlier note, I noted that 'Base'Size might be 32 in some
 implementations for a type declared via:
 
    type Signed_Byte is range -128 .. 127;
@@ -1629,7 +1638,7 @@
 resulting in 32 bits per stream item, while for other implementations,
 you might have just 8 bits per stream item.
 
-The "comp.lang.ada" case reflects a different problem, because we know 
+The "comp.lang.ada" case reflects a different problem, because we know
 that for all Ada 95 compilers, Byte'Base'Size is at least 9,
 even though Byte'Size is clearly 8.
 
@@ -1638,7 +1647,7 @@
 'Base'Size rather than <first_subtype>'Size.
 
 As I have suggested, I think we should propose to change the rule so that
-the default stream representation for scalar types is based on the 
+the default stream representation for scalar types is based on the
 'Size of the first subtype, rather than the base subtype 'Size.
 
 There is still the question of whether something such as:
@@ -1648,10 +1657,10 @@
 should occupy three (presumably 8-bit) stream elements or 4.
 
 I would tentatively suggest 4, based on a desire to limit representations
-to numbers of stream elements that are factors and multiples of the word 
-size, so that implementations like GNAT which already have 'Base'Size 
-being the smallest number of storage elements that is a factor/multiple of 
-the word size would not have to change for most cases (though the "0..255" 
+to numbers of stream elements that are factors and multiples of the word
+size, so that implementations like GNAT which already have 'Base'Size
+being the smallest number of storage elements that is a factor/multiple of
+the word size would not have to change for most cases (though the "0..255"
 Byte case would still require a change in GNAT).
 
 So who is doing AI-195, and where does it stand now?
@@ -1715,10 +1724,10 @@
 Subject: 	Re: AI-195 redux; stream rep for scalars
 
 > > So who is doing AI-195, and where does it stand now?
-> 
+>
 > According to the minutes, one Tucker Taft has an action item for AI-195.
 > ;-)
-> 
+>
 > The current status is that the AI is not written at all -- it just
 > contains the !appendix, containing 2 e-mails (from Pascal Leroy and
 > Randy Brukardt).  Randy raises the question you're interested in here;
@@ -1735,7 +1744,7 @@
 > From: "Pascal Leroy" <phl@Rational.COM>
 > Date: Thu, 7 May 1998 12:20:15 +0000
 > Subject: AI95-00195/02
-> 
+>
 > !standard 13.13.1 (00)                                98-04-04  AI95-00195/02
 > !class binding interpretation 98-03-27
 > !status received 98-03-27
@@ -1759,8 +1768,8 @@
 Sent: 	Friday, May 15, 1998 7:17 PM
 Subject: 	Re: AI-195 redux; stream rep for scalars
 
-> Pascal sent a rewrite of that AI to this list on 5/7/98; I remember reading 
-> it (and I found it on my saved mail).  His version was further along than 
+> Pascal sent a rewrite of that AI to this list on 5/7/98; I remember reading
+> it (and I found it on my saved mail).  His version was further along than
 > what Bob remembers...
 
 "I have a good memory -- it's just short."  ;-)
@@ -1773,11 +1782,11 @@
 The current AI on sw-eng is as I reported -- nothing there but the two
 e-mails in the !appendix.
 
-> Personally, I think Pascal's questions and the really important one that 
-> Tucker just reraised should be handled in separate Ais, since the priority 
-> of answers are quite different.  The 'Size question is going to a binding 
-> interpretation which is going to change the behavior of some 
-> implementations (and require an ACVC test to check compliance to) - that is 
+> Personally, I think Pascal's questions and the really important one that
+> Tucker just reraised should be handled in separate Ais, since the priority
+> of answers are quite different.  The 'Size question is going to a binding
+> interpretation which is going to change the behavior of some
+> implementations (and require an ACVC test to check compliance to) - that is
 > the most important kind of AI to get settled quickly.
 
 I tend to agree.  If we can agree (quickly) on the whole AI as is, then
@@ -1838,7 +1847,7 @@
 Subject: 	Re: more on the streams AI
 
 Robert Dewar wrote:
-> 
+>
 > (I have forgotten the proper ARG address, feel free to forward this if
 > it is useful to do so, and do not forward it if I am confused)
 
@@ -1846,11 +1855,11 @@
 
 > First, saying that the number of bytes written will correspond to the
 > size of objects of the first subtype may INCREASE non-portability!
-> 
+>
 > Consider
-> 
+>
 > 	type x is new integer range 1 .. 10;
-> 
+>
 > Currently both GNAT and Intermetrics read/write four bytes. Under the
 > proposed change, GNAT will still read/write 4 bytes, but Intermetrics
 > will read/write one byte.
@@ -1876,17 +1885,17 @@
 a good indication.
 
 But in some ways, agreeing on the size for stream representation
-is more important than agreeing about the default sizes chosen for 
-objects in memory, since interoperability is more dependent on 
+is more important than agreeing about the default sizes chosen for
+objects in memory, since interoperability is more dependent on
 stream representation than on in-memory representation.
 
 > 17   If a stream element is the same size as a storage element, then the
 > normal in-memory representation should be used by Read and Write for scalar
 > objects.  Otherwise, Read and Write should use the smallest number of stream
 > elements needed to represent all values in the base range of the scalar type.
-> 
-> 
-> 
+>
+>
+>
 > This AI only says to use the base range in a case which does not apply to any
 > of the im[plementations we are talking about. The first sentence SURELY
 > says that we should read/write one byte if objects of the type are one
@@ -1973,7 +1982,7 @@
 Whether this is a good idea or not is certainly fair discussion. Ada 95
 left very open the representation and size of objects, much more open than
 in Ada 83, where the gneral understanding was that by default the size of
-objects was the same as the size of the type of objects. 
+objects was the same as the size of the type of objects.
 
 Ada 95 decided (in my opinion, as you well know, a mistake) to pin down the
 definition of the default 'Size for types in such a manner that this
@@ -1990,12 +1999,12 @@
    q : integer range -128 .. +127;
 
 for which GNAT wlil allocate four bytes and Intermetrics one byte. We have
-found that for compatibility with legacy Ada 83, it is essential that 
+found that for compatibility with legacy Ada 83, it is essential that
 subtypes like this by default have the same representation as the base type.
 
 We should remember that this paragraph is after all implementation advice.
 I hope the ARG is not considering trying to elevate it to the status of
-a requirement! 
+a requirement!
 
 So the AI cannot in any case legislate interchnagability!
 
@@ -2008,7 +2017,7 @@
 I add the [...] phrase to make clear what I mean by a reasonable informal
 understanding.
 
-Clearly since different Ada 95 compilers have such very different 
+Clearly since different Ada 95 compilers have such very different
 interpretations of what this means in the default case, there is not
 much that can be done in the default case.
 
@@ -2017,7 +2026,7 @@
 	type bla is ...
         for bla'size use ...
 
-Have a consistent effect of setting bla'size as the size of stream 
+Have a consistent effect of setting bla'size as the size of stream
 stuff in the case where the specified size is the "reasonable" size
 for objects of the type.
 
@@ -2042,14 +2051,14 @@
 
 From: 	Anthony Gargaro[SMTP:abg@SEI.CMU.EDU]
 Sent: 	Saturday, May 16, 1998 7:45 AM
-Subject: 	Re: AI-195 redux; stream rep for scalars 
+Subject: 	Re: AI-195 redux; stream rep for scalars
 
 Dear Bob-
 
 >I must say, the streams stuff didn't get the attention it deserved
 >during the 9X design -- neither from the MRT nor from the reviewers.
 >It's kind of boring stuff, but it's terribly *important* stuff, and I
->think we all ought to have paid more attention to it. 
+>think we all ought to have paid more attention to it.
 
 I agree. In fact there was a strong sentiment prior to the Frankfurt
 workshop to remove it from the revision (along with Annex E).
@@ -2088,7 +2097,7 @@
 no one proposes NOT having a 32-bit base type for floating-point.
 
 Note also that all the discussions about streams in this context are
-about implementation advice. 
+about implementation advice.
 
 It is very clear from the way the impleme3ntation advice is written that
 it does not envision the problems from having base types be chosen in
@@ -2104,7 +2113,7 @@
 
 I must say that I don't like giving IA as much force as we have in the
 past. It causes difficulties. Look at the toruble we are having trying to
-patch up the completely wrong advice in 
+patch up the completely wrong advice in
 
    69  An Ada parameter of a record type T, of any mode, is passed as a
        t* argument to a C function, where t is the C struct
@@ -2122,7 +2131,7 @@
 
 From: 	Anthony Gargaro[SMTP:abg@SEI.CMU.EDU]
 Sent: 	Saturday, May 16, 1998 8:25 AM
-Subject: 	Re: AI-195 redux; stream rep for scalars 
+Subject: 	Re: AI-195 redux; stream rep for scalars
 
 Dear Robert-
 
@@ -2247,7 +2256,7 @@
 Sure, but for the types that Java defines, any reasonable Ada compiler should
 do the right thing, and if you want endianness independence (does Java
 guarantee this for stream stuff), then you can of course implement this
-(we use XDR in GNAT to achieve a much greater degree of target 
+(we use XDR in GNAT to achieve a much greater degree of target
 independence than Java, e.g. we do not need to depend on IEEE floating-point
 representation).
 
@@ -2335,7 +2344,7 @@
 >>
 
 I disagree, the current spec allows compilers to do the reasonable thing.
-If target independnet forms are desiraqble (like the GNAT XDR 
+If target independnet forms are desiraqble (like the GNAT XDR
 impolementation), they are consistent with the current RM, and can
 be agreed on separately.
 
@@ -2372,7 +2381,7 @@
 which does not often happen, but there are cases
 
 For example, the IA says not to provide pragmas that affect legality, but
-we have found LOTS of useful pragmas that disobey this, e.g. 
+we have found LOTS of useful pragmas that disobey this, e.g.
 Unchecked_Union!
 
 ****************************************************************
@@ -2402,9 +2411,9 @@
 > <<Quite true.  I think that was probably a mistake -- we *should* have
 > tried for that more ambitious goal.
 > >>
-> 
+>
 > I disagree, the current spec allows compilers to do the reasonable thing.
-> If target independnet forms are desiraqble (like the GNAT XDR 
+> If target independnet forms are desiraqble (like the GNAT XDR
 > impolementation), they are consistent with the current RM, and can
 > be agreed on separately.
 
@@ -2414,11 +2423,11 @@
 > There is nothing in the RM that stops compilers doing the right thing
 > for streams. I remind again that the entire problem has arisen here
 > because of compilers simply making poor implementation choices.
-> 
+>
 > It sems obvious to me that
-> 
+>
 >   	type x is range - 128 .. +127;
-> 
+>
 > should result in one byte stream elements.
 
 Agreed.  (On the other hand, you and I probably disagree on what should
@@ -2428,12 +2437,12 @@
 > Since the AI we are discussing only affects implementation advice, it has
 > no force at all. Compilers are as free before or after this AI do do
 > the right or wrong thing.
-> 
+>
 > It also seems clear that
-> 
+>
 > 	type x is range 0 .. 255;
 > 	for x'size use 8;
-> 
+>
 > should result in one byte stream elements, but due to what in retrospect
 > I consider an error in the GNAT implementation it does not (and it also
 > does not in IM).
@@ -2536,7 +2545,7 @@
 
 > Oh, of course, so yes, absolutely this does require two bytes and that
 > is the end of it. In fact I now don't understand at all,
-> 
+>
 > If we are required to be able to write any element of the base type
 > (why is this so?....) then of course you need to use the base range.
    ^^^^^^^^^^^^^^^^^^^
@@ -2644,7 +2653,7 @@
 
 I think we can come up with disciplines that make sense in each case, but
 no one protocol can solve all these problems, since there is a trace off
-(oops trade off) between efficiency and portability. 
+(oops trade off) between efficiency and portability.
 
 The XDR solution in GNAT is a solution to 4, but is too inefficient to use
 for some of the other cases.
@@ -2677,7 +2686,7 @@
 but not for loads and stores, the low order 2-bits can select one of the
 four byutes in a register.
 
-But I cannot see by what stretch of imagination you could talk about 
+But I cannot see by what stretch of imagination you could talk about
 the old Alpha having byte addressability.
 
 ****************************************************************
@@ -2744,7 +2753,7 @@
 
 Nothing pathological at all about the test programs in question, it is
 easy to do a write with an "out of range" value, remember we are talking
-*values* here. 
+*values* here.
 
 This is a definite change in the language as far as I can tell.
 
@@ -2817,7 +2826,7 @@
 
 1. Size = size of base type increased to natural boundary (8,16,32,64)
 
-2. Size = size of objects of first named subtype 
+2. Size = size of objects of first named subtype
 
 3. Size of first named subtype rounded up to the nearest multiple of
 stream elements.
@@ -2934,6 +2943,105 @@
 > with the number of stream elements written/read for a scalar type.
 
 Okay, I will handle that part.
+
+-Tuck
+
+****************************************************************
+
+From: 	Pascal Leroy
+Sent: 	Monday, March 01, 1999 4:14 AM
+
+> There seem to be two solutions.  One
+> is to allow stream attributes to be specified before the
+> type is fully defined.  The other is to allow them to be specified
+> in the private part.
+
+I hate to open private parts.  In our compiler, this is a real nightmare (we
+have to do that for pragma Convention, and that's already a big pain in the
+neck).
+
+So my preference would be to allow the specification of stream attributes
+before the type is fully defined.  Remember that we already have an AI that
+says that 13.1(10) does not apply to stream attributes.  This would just be
+another oddity with stream-oriented attributes.  (In fact I believe the
+stream-oriented attributes should not be considered a representation item,
+since they do not affect the physical representation of the type; they should
+be "something else", with much more relaxed rules; but we are not going to
+rewrite chapter 13...)
+
+> I suppose another option is to have some
+> kind of "incomplete" stream attribute specification,
+> such as "for Lim_Type'Read use <>;" in the visible part,
+> and then complete the definition in the private part.  This is
+> rampant invention, of course, but it solves another problem.
+
+This would have been a nice idea in '93, but at this point I think the
+language is insufficiently broken to invent new syntax.
+
+> Types like Exception_Occurrence are required to have stream attributes,
+> but not have any other primitive operations declared in the
+> visible part.  However stream attributes can only be defined
+> in terms of some "normal" subprogram, which must necessarily also
+> be visible at the point of the stream attribute definition.
+> Another contradiction...
+
+If there is a problem with this package, then I'd rather see the ARG modify
+the specification of Ada.Exceptions to include the additional stuff needed for
+streaming, rather than adding new syntax for this cornercase.
+
+Pascal
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Monday, March 01, 1999 8:18 AM
+
+> > There seem to be two solutions.  One
+> > is to allow stream attributes to be specified before the
+> > type is fully defined.  The other is to allow them to be specified
+> > in the private part.
+>
+> I hate to open private parts.  In our compiler, this is a real nightmare (we
+> have to do that for pragma Convention, and that's already a big pain in the
+> neck).
+>
+> So my preference would be to allow the specification of stream attributes
+> before the type is fully defined.  Remember that we already have an AI that
+> says that 13.1(10) does not apply to stream attributes.  This would just be
+> another oddity with stream-oriented attributes.  (In fact I believe the
+> stream-oriented attributes should not be considered a representation item,
+> since they do not affect the physical representation of the type; they should
+> be "something else", with much more relaxed rules; but we are not going to
+> rewrite chapter 13...)
+
+Yes, I agree, since 13.1(10) does not apply to stream attributes, we
+should view them as a special category of attribute, and allow them
+to be specified on private types and other not-yet-completely-defined
+types.
+
+> > I suppose another option is to have some
+> > kind of "incomplete" stream attribute specification,
+> > such as "for Lim_Type'Read use <>;" in the visible part,
+> > and then complete the definition in the private part.  This is
+> > rampant invention, of course, but it solves another problem.
+>
+> This would have been a nice idea in '93, but at this point I think the
+> language is insufficiently broken to invent new syntax.
+>
+> > Types like Exception_Occurrence are required to have stream attributes,
+> > but not have any other primitive operations declared in the
+> > visible part.  However stream attributes can only be defined
+> > in terms of some "normal" subprogram, which must necessarily also
+> > be visible at the point of the stream attribute definition.
+> > Another contradiction...
+>
+> If there is a problem with this package, then I'd rather see the ARG modify
+> the specification of Ada.Exceptions to include the additional stuff needed for
+> streaming, rather than adding new syntax for this cornercase.
+
+If we allow specification of stream attributes on private types, that
+will probably simplify the solution enough to not justify adding any
+declarations to Ada.Exceptions.
 
 -Tuck
 

Questions? Ask the ACAA Technical Agent