CVS difference for ais/ai-00195.txt

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

--- ais/ai-00195.txt	1998/10/01 03:20:23	1.3
+++ ais/ai-00195.txt	1998/10/01 19:10:50	1.4
@@ -1465,3 +1465,1297 @@
 
 ****************************************************************
 
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Friday, May 15, 1998 4:43 PM
+Subject: 	AI-195 redux; stream rep for scalars
+
+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.    
+
+In the comp.lang.ada posting, someone was quite confused by the
+fact that a type declared via:
+
+   type Byte is range 0..255;
+
+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 
+implementations for a type declared via:
+
+   type Signed_Byte is range -128 .. 127;
+
+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 
+that for all Ada 95 compilers, Byte'Base'Size is at least 9,
+even though Byte'Size is clearly 8.
+
+Both cases, however, seem to reflect the confusing nature of
+the current RM rule, where the stream representation is based on
+'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 
+'Size of the first subtype, rather than the base subtype 'Size.
+
+There is still the question of whether something such as:
+
+    type Three_Bytes is range 0..2**24-1;
+
+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" 
+Byte case would still require a change in GNAT).
+
+So who is doing AI-195, and where does it stand now?
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Friday, May 15, 1998 5:10 PM
+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;
+Pascal raises a whole truckload of other stream-related questions.
+
+I agree with your technical comments: Use the first subtype's 'Size.  I
+guess that means 'Write raises an exception for values outside the base
+range?  And a 3-byte value should get 4 bytes on a "typical" machine.
+(I'm not completely convinced of the last, but I think it makes the most
+sense.)
+
+There is perhaps a danger that the AI as a whole will get stalled on one
+of the more obscure questions.
+
+- Bob
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Friday, May 15, 1998 5:33 PM
+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. ;-)
+
+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.
+
+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.
+
+				Randy.
+
+****************************************************************
+
+From: 	Gary Dismukes[SMTP:dismukes@gnat.com]
+Sent: 	Friday, May 15, 1998 5:23 PM
+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;
+> Pascal raises a whole truckload of other stream-related questions.
+
+But Pascal sent out a revised version of AI-195 a week ago,
+didn't you receive it?  Below is the portion from the summary
+pertaining to the scalar size issue (further detail is in the
+discussion section):
+
+
+> From phl@sorbonne.rational.com Thu May  7 06:21 EDT 1998
+> Return-Path: <phl@sorbonne.rational.com>
+> 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
+> !reference AI95-00108
+> !reference AI95-00145
+> !priority High
+> !difficulty Hard
+> !subject Streams
+> !summary 98-04-04
+>
+> ...
+>
+> The predefined stream-oriented attributes for a scalar type shall only read or
+> write the minimum number of stream elements required by the first subtype of
+> the type.  Constraint_Error is raised if such an attribute is passed (or would
+> return) a value outside the range of the first subtype.
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+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 
+> what Bob remembers...
+
+"I have a good memory -- it's just short."  ;-)
+
+It's not a matter of my memory; all my e-mail is automatically saved,
+and I grepped it all for the message in question, and it's not there.
+I've had problems in the past getting e-mail from Pascal.  I don't know
+why, but I sure don't like it.
+
+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 
+> 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
+let's do it, but if there's some doubt about some obscure point, let's
+split out the important point, and officially approve that as a separate
+AI.  Then we can chat at leisure about the obscure stuff.  This
+particular issue is in the 5% or less of AI material that real users
+actual care about!
+
+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.  This is an
+important area where Java wins strongly over Ada 95, and it didn't have
+to be that way.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, May 15, 1998 8:18 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<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
+'Size of the first subtype, rather than the base subtype 'Size.
+>>
+
+This is a nasty incompatibility. I obnject to changes in the language
+which force us to introduce incompatibilities, so at best this should
+be a matter of *aqllowing* implementations to do this, not requiring
+them to do it.
+
+We would object STRONGLY to being forced to make incompatible changes which
+could negatively affect our cusomters.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Friday, May 15, 1998 8:23 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<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.  This is an
+important area where Java wins strongly over Ada 95, and it didn't have
+to be that way.
+>>
+
+Why do you feel Java wins strongly over Ada 95 here?
+
+****************************************************************
+
+From: 	Tucker Taft[SMTP:stt@inmet.com]
+Sent: 	Friday, May 15, 1998 9:27 PM
+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)
+
+I have "cc"ed the ARG.
+
+> 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.
+
+Perhaps types defined by a derived type definition should follow
+a different rule -- they should inherit 'Read/'Write from the parent type,
+at least in the absence of an explicit Size clause on the derived type.
+
+In general my hope is to minimize the number of cases where GNAT's
+current representation will differ from the AI's recommendation.
+Mostly I want to have some set of recommendations that are independent
+of implementation decisions about base type selection, stand-alone
+object representation, etc.
+
+> Second, if a SIze clause is given, then surely the AI says that you
+> do indeed read/write the amount of space allocated for objects of
+> the first subtype:
+
+I don't think the size of stand-alone objects is relevant, since
+they might live in registers, etc.
+
+Perhaps the 'Component_Size of an unpacked array would be
+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 
+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
+> byte.
+
+Remember that this is in the context of the definition of 'Read and
+'Write as operations of the *unconstrained* (base) subtype, as implied
+by the italicized T.  So this is saying that the in-memory representation
+for S'Base should be used, whereas it seems it is more useful if
+the in-memory representatin of the first subtype should be more relevant.
+
+> But neither GNAT nor Intermetrics seem to do this, they implement only
+> the second sentence, which does not apply to normal implementations.
+
+Both worry about the base subtype, which is consistent with both
+sentence (1) and (2).
+
+> I am *very* confused!
+
+Something about section 13.13 confuses everyone...
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Saturday, May 16, 1998 5:12 AM
+Subject: 	Re: more on the streams AI
+
+<<Remember that this is in the context of the definition of 'Read and
+'Write as operations of the *unconstrained* (base) subtype, as implied
+by the italicized T.  So this is saying that the in-memory representation
+for S'Base should be used, whereas it seems it is more useful if
+the in-memory representatin of the first subtype should be more relevant.
+
+> But neither GNAT nor Intermetrics seem to do this, they implement only
+> the second sentence, which does not apply to normal implementations.
+
+Both worry about the base subtype, which is consistent with both
+sentence (1) and (2).
+
+> I am *very* confused!
+
+Something about section 13.13 confuses everyone...
+>>
+
+I disagree, to talk about the "in-memory" representation surely *is*
+talking about objects. If you look at the recent CLA confusion, the
+problem was precisely that the person expected the stream size to be
+related to the size of objects.
+
+In GNAT terms, I would expect the size of stream elements to be related
+to the Object_Size, not the Value_Size. This is consistent with the fact
+that we agree that they should, like objects, be padded to a natural
+boundary.
+
+I strongly object to the 24-bit case generating three bytes for an object
+with four byte alignment. This ppotentially introduces a *third* concept
+of size and is very confusing.
+
+The wording in the RM very clearly expects stream element size to be related
+to object size. Let's look at the para again:
+
+                            Implementation Advice
+
+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.
+
+
+
+First, I must say, I have NO idea what the thinking of the designers is
+behind the conditional, perhaps they would care to clarify ...
+
+Tuck seems to say that the first sentence assumes the base range. But I
+find that dubious, since why mention the base range in the second sentence
+and not the first.
+
+I think almost anyone would read the first sentence to mean what it says,
+namely if you do Stream_IO on "junks", then the representation used is
+the representation of junks in memory, period.
+
+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. 
+
+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
+correspondence is *forced* to be broken. As a result, the RM has pretty
+much nothing to say about object sizes, and for example, leavs quite
+open the question of whethre:
+
+type x is record
+   a,b : integer range -128 .. +127;
+end record;
+
+occupies two bytes or eight bytes (this is even clearer in the simple case)
+
+   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 
+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! 
+
+So the AI cannot in any case legislate interchnagability!
+
+I think that the best thing is to pin attention on the reasonable informal
+understanding of the important phrase in para 17:
+
+"the normal in-memory representation should be used by Read and Write for
+ scalar objects [of the subtype in question]"
+
+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 
+interpretations of what this means in the default case, there is not
+much that can be done in the default case.
+
+However, it certainly would be nice if
+
+	type bla is ...
+        for bla'size use ...
+
+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.
+
+One thing of interest here is that in practice, many of our customers use
+the stream stuff extensively, and none has ever complained that they got
+unexpected results.
+
+Marcus Kuhn is not a customers, so he is not included in this paragraph,
+but I think there is some justification to his suprise that
+
+	type bla is range 0 .. 255;
+ 	for bla'size use 8;
+
+results in 16-bit stream elements rather than 8-bit elements.
+
+I am very worried about making an incompatible change here, and of course
+we would have to introudce it under a switch and leave an option for ever
+which is arduous, but I must say it makes sense to use subtype'Object_Size
+in the GNAT context.
+
+****************************************************************
+
+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 
+
+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. 
+
+I agree. In fact there was a strong sentiment prior to the Frankfurt
+workshop to remove it from the revision (along with Annex E).
+
+Anthony.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Saturday, May 16, 1998 7:49 AM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<I agree. In fact there was a strong sentiment prior to the Frankfurt
+workshop to remove it from the revision (along with Annex E).
+>>
+
+First: I remember no such suggestion, certainly people were unusre about
+annex E, but streams are critically useful in many other contexts.
+
+Second, although there have been problems with the Intermetrics implementation
+due to the clash in using only one base type and the probably wrong RM
+requirements in this area, it is important to note that generally it is
+working out VERY well, we have LOTS of customers using this capability,
+and we have essentially no reported problems with it.
+
+Note that I am not saying that the Intermetrics implementation is wrong here,
+although I think havcing only one 32-bit base type is definitely a mistake
+for many reasons (only one of which is that it screws up the stream stuff).
+
+As I have said before, I think of base types as corresponding to the types
+that can be loaded and stored, NOT to the types on which computations in
+registers are possible. The clear indication of this is that there are
+many machines, e.g. Power and Intel x86, where all register computations
+are at maximukm precision (80 bits in x86 and 64 bits on power) and this
+will be an increasinvgly commong approach (Merced is the same way). Yet
+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. 
+
+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
+a manner not coresponding to the storage layout. I don't see why
+Intermetrics just doesn't decided that given its decision to have only
+one 32-bit base type, it should ignore the implementation advice and
+do the right thing.
+
+Voila, problem solved.
+
+Implementation advice should not be taken too seriously, especially whenm
+it is plain wrong.
+
+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 
+
+   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
+       corresponding to the Ada type T.
+
+In retrospect, I think the C_Pass_By_Copy was a horrible kludge, and
+I regret GNAT deciding to go along with this approach. No wonder WG9
+is having heartburn accepting the kludgy AI that tries to justify this
+incorrect approach.
+
+I am afraid that the AI here is headed for similar messy times. I think
+we should just completely abandon this AI. It is unnecessary.
+
+****************************************************************
+
+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 
+
+Dear Robert-
+
+>First: I remember no such suggestion, certainly people were unusre about
+>annex E, but streams are critically useful in many other contexts.
+
+I believe that if you refer to the Zero-based budget proposal that
+preceded the Frankfurt workshop you will find that streams had been
+removed from the core language.
+
+Anthony.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Saturday, May 16, 1998 8:42 AM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<I believe that if you refer to the Zero-based budget proposal that
+preceded the Frankfurt workshop you will find that streams had been
+removed from the core language.
+>>
+
+Yes, but many things were left out of the ZBB proposal. As in real life
+with ZBB in the political arena, this represents a negotiating position
+that was an extreme. After all remember that child units also came under
+pretty strong attack at one point.
+
+My objection here is in linking Annex E and streams together in this
+discussion. The concners about Annex E were of a very different nature,
+and there were, as you say lots of people who worried that putting in
+Annex E stuff was premature in the sense we were not sure what we wanted.
+
+In contrast I think the streams had strong support and the reason for
+even suggesting taken them out was very different, namely a concern
+that their utility did not justify their complexity. In practice I
+think streams came out pretty well. I tis particularly interesting that
+in the GNAT context, we have found it VERYT easyt to plug in an XDR
+implementation on an optional basis that in practice provides complete
+stream portability in a heterogenous environment.
+
+I do understand the current problem with streams, but it is a very small
+glitch in the implemenmtation advice, and can trivially be fixed for
+the compiler in which trouble arises by simply "re-interpreting" the
+IA appropriately.
+
+I continue to think that an AI is not needed here.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Saturday, May 16, 1998 8:46 AM
+Subject: 	streams for scalars
+
+
+Note that the RM is defintiely NOT in the business of trying to ensure
+that streams are compatible across compilers, or of in any way specifying
+the exact representation to be used in streams.
+
+Part of the reason that I find this AI suspicious is that it moves a tiny
+little bit in this direction. I find the movement either too small to be
+relevant, or far too little if you really decide that this kind of
+interoperation is important.
+
+I do think that a compiler that generates more than one byte for
+
+  type x is range -128 .. +127;
+
+in streams is broken. I think that any such compiler should be fixed.
+No AI is needed in order to do this fix!
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 11:59 AM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+> <<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
+> 'Size of the first subtype, rather than the base subtype 'Size.
+> >>
+
+I was under the impression that the above means 'Size, but rounded up to
+some reasonable number (8,16,32,64 bits, on typical machines).  Given
+that, I don't understand:
+
+> This is a nasty incompatibility.
+
+Why is it incompatible?  I thought that's what GNAT was already doing.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 12:02 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+> Why do you feel Java wins strongly over Ada 95 here?
+
+Because Java nails down representations so much (at least in theory)
+that one can pass data across Java implementations, and across machines,
+more portably than in Ada.  In Java, there's never any question about
+how many bits in a given integer type, whereas that's what we're arguing
+about, for Ada, in this discussion.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 12:10 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<Because Java nails down representations so much (at least in theory)
+that one can pass data across Java implementations, and across machines,
+more portably than in Ada.  In Java, there's never any question about
+how many bits in a given integer type, whereas that's what we're arguing
+about, for Ada, in this discussion.
+>>
+
+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 
+independence than Java, e.g. we do not need to depend on IEEE floating-point
+representation).
+
+
+I think you will find that ALL Ada representations behave as follows:
+
+modular type with range 0..255  1 byte
+32-bit integer type  4 bytes
+character  1 byte
+wide-character 2 bytes
+
+of course we have the capability in Ada, which does not exist in Java
+of defining various types and that is where the most problems exist.
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 12:07 PM
+Subject: 	Re: streams for scalars
+
+> Note that the RM is defintiely NOT in the business of trying to ensure
+> that streams are compatible across compilers, or of in any way specifying
+> the exact representation to be used in streams.
+
+Quite true.  I think that was probably a mistake -- we *should* have
+tried for that more ambitious goal.
+
+> Part of the reason that I find this AI suspicious is that it moves a tiny
+> little bit in this direction. I find the movement either too small to be
+> relevant, or far too little if you really decide that this kind of
+> interoperation is important.
+
+Good point.  But I don't find this particular issue so "tiny".
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 12:06 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<Why is it incompatible?  I thought that's what GNAT was already doing.
+>>
+
+No, we use the Object_Size of the base type.
+
+However, we have 8, 16, and 32 bit base types
+
+(so we don't get peculiar behavior as often as Intermetrics does, who has
+only a 32-bit base type).
+
+However, GNAT for:
+
+   type x is range 0 .. 255;
+
+will read and write 16-bits regardless of a size clause on type x, since
+it will go to x'base which is 16-bits for us.
+
+That was the CLA case that was discussed.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 12:07 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<I was under the impression that the above means 'Size, but rounded up to
+some reasonable number (8,16,32,64 bits, on typical machines).  Given
+that, I don't understand:
+>>
+
+I thought we were trying to eliminate target dependencies here, what does
+reasonable mean, is 8-bits reasonable on the old Alphas and the AMD 29K
+for instance, I can see one compiler saying yes, and another no.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 12:21 PM
+Subject: 	Re: streams for scalars
+
+<<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 
+impolementation), they are consistent with the current RM, and can
+be agreed on separately.
+
+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.
+
+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).
+
+In fact right now, this type gives 2-byte elements for GNAT and 4-byte
+elements for IM.
+
+I am thinking of chnaging the GNAT implementation, but a bit worried about
+incompatibilities with existing data. The decision of whether or not to make
+this change will not be influeneced at all by an AI which does or does not
+change the implementation advice. We always ignore IA if we think it is wrong,
+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. 
+Unchecked_Union!
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 12:49 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+> I thought we were trying to eliminate target dependencies here, what does
+> reasonable mean, is 8-bits reasonable on the old Alphas and the AMD 29K
+> for instance, I can see one compiler saying yes, and another no.
+
+"Reasonable" on a typical 32- or 64-bit machine should mean 8,16,32, and
+64 bits.  So yes, I think 8 bits is "reasonable" on an old alpha.  (I
+don't know anything about the AMD chip.)  All of this stuff is defined
+in terms of stream elements, which are impl def, but I presume all
+impl's on "typical" machines will choose 8 bit stream elements.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 1:13 PM
+Subject: 	Re: streams for scalars
+
+> <<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 
+> impolementation), they are consistent with the current RM, and can
+> be agreed on separately.
+
+But no user can portably count on having XDR support on all Ada
+implementations.
+
+> 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
+be the base range of x.  That would be fine, if streams weren't so
+closely tied to in-memory representations.)
+
+> 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).
+
+I agree that the above should result in one-byte stream elements.  But I
+think that's currently forbidden by the RM.  Not just by the impl
+advice, but by the fact that we require the ability to read/write -1 of
+that type to a stream.  Even if you ignore the impl advice, you still
+need at least 9 bits.
+
+> For example, the IA says not to provide pragmas that affect legality, ...
+
+That's not what it says, but I agree that the pragma advice is
+questionable.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 3:23 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<"Reasonable" on a typical 32- or 64-bit machine should mean 8,16,32, and
+64 bits.  So yes, I think 8 bits is "reasonable" on an old alpha.  (I
+don't know anything about the AMD chip.)  All of this stuff is defined
+in terms of stream elements, which are impl def, but I presume all
+impl's on "typical" machines will choose 8 bit stream elements.
+>>
+
+THe reason that this is questionable on the alpha is that the object
+size is probably 32 bits, since this machine has no 8-bit load/store
+instructions. So the old Alpha is NOT a typical 32-bit or 64-bit machine
+(all the others, *and* the new alpha) do have byte load/store instructions.
+
+The AMD29K is exactly like the old Alpha, byte addressable, but no
+byte load/store instructions.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 3:26 PM
+Subject: 	Re: streams for scalars
+
+<<I agree that the above should result in one-byte stream elements.  But I
+think that's currently forbidden by the RM.  Not just by the impl
+advice, but by the fact that we require the ability to read/write -1 of
+that type to a stream.  Even if you ignore the impl advice, you still
+need at least 9 bits.
+>>
+
+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.
+
+Or is the intent to change the language here.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 9:05 PM
+Subject: 	Re: streams for scalars
+
+I find it too big a change in the language to disallow values outside
+the declared range (but in the base rnage) if they are currently allowed.
+
+Note that if people write type x is mod 2**8, they will presumably get
+8 bits on all architectures, so there is a path to interoperatbility.
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 9:03 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<Yes, I understand how the old alpha works, and that would definitely
+affect my decisions about how to represent in-memory variables, but my
+claim is that it shouldn't have such a strong affect on stream
+representations.  I realize this isn't what the RM says.  I'm not sure
+if I'm suggesting a language change, or merely wishing we had done
+differently in the past.
+>>
+
+What about the Patriot, with its 24-bit words, does your attitude change
+here, or is the fact that 24 = 3 * 8 enough to convince you to use
+8-bit stream elements (this seems to be the reasoning for the old
+Alpha, right, this is a 32-bit word machine, but 32 = 4 * 8).
+Presumably on a 36-bit machine you would not expect 8-bit stream
+elenments (this is a reminder that short of things like XDR, you
+cannot guarantee inter-architecture commonality. Also what is your
+position on endianness (both bit and byte).
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 9:05 PM
+Subject: 	Re: streams for scalars
+
+> 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.
+   ^^^^^^^^^^^^^^^^^^^
+Mea Culpa, at least in part.
+
+> Or is the intent to change the language here.
+
+I think that's the intent of at least some folks in this discussion!
+
+I'm inclined to agree, but I'm not sure, and unfortunately my main
+feeling when faced with all these stream-related issues is to throw up
+my hands in despair.  Sigh.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 9:02 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+> THe reason that this is questionable on the alpha is that the object
+> size is probably 32 bits, since this machine has no 8-bit load/store
+> instructions. So the old Alpha is NOT a typical 32-bit or 64-bit machine
+> (all the others, *and* the new alpha) do have byte load/store instructions.
+
+Yes, I understand how the old alpha works, and that would definitely
+affect my decisions about how to represent in-memory variables, but my
+claim is that it shouldn't have such a strong affect on stream
+representations.  I realize this isn't what the RM says.  I'm not sure
+if I'm suggesting a language change, or merely wishing we had done
+differently in the past.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert A Duff[SMTP:bobduff@world.std.com]
+Sent: 	Sunday, May 17, 1998 9:25 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+> What about the Patriot, with its 24-bit words, does your attitude change
+> here, ...
+
+Well, I'm afraid I can't comment on the Patriot, since I don't know the
+machine (despite my current employer!).  I know it's got 24-bit words,
+but I don't know if addresses point at 24-bit words, or 8-bit storage
+units, 3-per-word.  Anyway, who cares?  There are no Patriot machines on
+the networks that most folks care about.
+
+>...or is the fact that 24 = 3 * 8 enough to convince you to use
+> 8-bit stream elements (this seems to be the reasoning for the old
+> Alpha, right, this is a 32-bit word machine, but 32 = 4 * 8).
+
+The old alpha can address 8-bit bytes (although it can't load and store
+them, directly).
+
+> Presumably on a 36-bit machine you would not expect 8-bit stream
+> elenments (this is a reminder that short of things like XDR, you
+> cannot guarantee inter-architecture commonality.
+
+I don't know.  I would like to at least have the option of inter-arch
+commonality.  Short of that, I'd like commonality among 16/32/64-bit
+machines, which isn't as hard to achieve.  I suppose on a network of
+PDP-10's (that's the only 36-bit machine I know) the "natural" stream
+element would be 36 bits.  On the other hand, one might use 8 bits, just
+to "fit in".  On the third hand, I haven't seen any PDP-10's lately.
+
+>...Also what is your
+> positionb on endianness (both bit and byte).
+
+Good question.  ;-)
+
+My position is that bit- and byte-endianness need to be the same.
+(Isn't that what you say in your microprocessor book -- you gripe about
+the confusion of 68000, but it's really a documentation issue?)  And my
+other position is that it's a shame that we have both types of
+computers.  It's also a shame that some countries want you to drive and
+the right-hand side of the road, and others, on the left.  But there's
+not much one can do about it.  Sigh.
+
+What's *your* position?  It seems to be that commonality is hopeless, so
+let's not bother.  Is that a correct reading?
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 9:27 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<What's *your* position?  It seems to be that commonality is hopeless, so
+let's not bother.  Is that a correct reading?
+>>
+
+YOu need different levels of commonality for different purposes:
+
+1. same compiler, different but similar machines
+2. different compilers, different but similar machines
+3. different compilers, same machines
+4. very different machines
+
+is an approximate categorization.
+
+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. 
+
+The XDR solution in GNAT is a solution to 4, but is too inefficient to use
+for some of the other cases.
+
+I would not be opposed to some secondary standards here.
+
+But I don't see how the RM can solve all these problems.
+
+I do really like the way GNAT does things which is to hgave a single
+easily replacable library unit that describes the format used for all
+primitive types. Inlining from this unit avoids excessive inefficiency
+from using a library routine.
+
+This means that GNAT can trivially be adapted *by a user* to meet any
+variation in protocol that you want.
+
+(although the base type issue is of course above this level)
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Sunday, May 17, 1998 9:28 PM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<The old alpha can address 8-bit bytes
+>>
+
+No, it can't when you address memory on the alpha, you are using the
+first 30-bits of the address as a word address, and for certain instructions,
+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 
+the old Alpha having byte addressability.
+
+****************************************************************
+
+From: 	Robert I. Eachus[SMTP:eachus@mitre.org]
+Sent: 	Monday, May 18, 1998 6:06 AM
+Subject: 	Re: streams for scalars
+
+At 01:21 PM 5/17/98 EDT, Robert Dewar wrote:
+>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.
+
+    I think that an AI is needed, but otherwise I agree with Robert Dewar.
+The AI is required to define which exceptions are raised by default 'Read
+and 'Write operations, and under what conditions.  I certainly think that
+given
+
+   type Foo is range 1..10;
+
+   Foo'Read should raise Constraint_Error if it reads a value of 11.
+Foo'Base'Read should not do constraint checks, but Foo'Base'Write should
+raise constraint error when confronted with a value outside the base range
+of Foo, and Foo'Write should raise Constraint_Error for values outside the
+subtype.
+
+   Note that even though these are all expressed as advice, since the only
+conditions where they can be checked border on pathological, the AI is
+needed to allow implementations to "do the right thing" for
+
+   type Byte is range 0..255;
+
+   even though I think that type should be defined as:
+
+   type Byte is mod 256;
+
+
+
+                                        Robert I. Eachus
+
+with Standard_Disclaimer;
+use  Standard_Disclaimer;
+function Message (Text: in Clever_Ideas) return Better_Ideas is...
+
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Monday, May 18, 1998 6:40 AM
+Subject: 	Re: streams for scalars
+
+Robert Eachus says
+
+<<   Foo'Read should raise Constraint_Error if it reads a value of 11.
+Foo'Base'Read should not do constraint checks, but Foo'Base'Write should
+raise constraint error when confronted with a value outside the base range
+of Foo, and Foo'Write should raise Constraint_Error for values outside the
+subtype.
+
+   Note that even though these are all expressed as advice, since the only
+conditions where they can be checked border on pathological, the AI is
+needed to allow implementations to "do the right thing" for
+>>
+
+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. 
+
+This is a definite change in the language as far as I can tell.
+
+****************************************************************
+
+From: 	ncohen@us.ibm.com[SMTP:ncohen@us.ibm.com]
+Sent: 	Monday, May 18, 1998 9:34 AM
+Subject: 	Re: more on the streams AI
+
+Robert Dewar writes:
+
+<<I strongly object to the 24-bit case generating three bytes for an object
+with four byte alignment. This ppotentially introduces a *third* concept of
+size and is very confusing.>>
+
+I strongly object to enforcing alignment within streams.  The most common
+streams correspond to communication channels (typically sockets) and files.
+There is certainly no hardware reason for enforcing alignment in these
+contexts.  However, in the case of communication channels, it is frequently
+important to conserve bandwidth, so stuffing gratuitous padding bytes into
+the stream is the last thing we want to do.  (I am thinking especially of
+distributed applications that involve mobile devices, connected by slow and
+wireless links with high per-byte costs.)
+
+-- Norman
+
+****************************************************************
+
+From: 	Robert Dewar[SMTP:dewar@gnat.com]
+Sent: 	Monday, May 18, 1998 9:48 AM
+Subject: 	Re: more on the streams AI
+
+<<I strongly object to enforcing alignment within streams.  The most common
+streams correspond to communication channels (typically sockets) and files.
+There is certainly no hardware reason for enforcing alignment in these
+contexts.  However, in the case of communication channels, it is frequently
+important to conserve bandwidth, so stuffing gratuitous padding bytes into
+the stream is the last thing we want to do.  (I am thinking especially of
+distributed applications that involve mobile devices, connected by slow and
+wireless links with high per-byte costs.)
+>>
+
+I am not taqlking about enforcing alignment for streams, I am talking about
+stream elements being related to the size of the object as stored.
+
+If we have type x is range 0 .. 2**21-1;
+
+then typically x'size is 22
+x'object_size will be 32
+
+All current compilers will generate 32 bit stream ntries for this
+(note that C does not even begin to have an option to generate anythking
+other than 32-bits in a stream for such a type).
+
+But it appears that some are trying to create the concept of a stream size
+different from either of the value_size or Object_size (i.e. 24 in this case)
+
+I find that confusing.
+
+To understand clearly, the proposal is that the stream size be the
+size of the type, rounded up to an integral multiple of stream elements,
+right?
+
+I much prefer the size of stream elements being based on the size of
+objetcts of the first known subtype (althouhgh we have not really solved
+how
+to do that).
+
+These then are the three proposals
+
+1. Size = size of base type increased to natural boundary (8,16,32,64)
+
+2. Size = size of objects of first named subtype 
+
+3. Size of first named subtype rounded up to the nearest multiple of
+stream elements.
+
+I could tolerate 1 or 2 in GNAT (we currently do 1, but would consider
+changing to 2), but 3 isa radical chanbge that we would oppose strongly.
+
+****************************************************************
+
+From: 	ncohen@us.ibm.com[SMTP:ncohen@us.ibm.com]
+Sent: 	Monday, May 18, 1998 10:51 AM
+Subject: 	Re: AI-195 redux; stream rep for scalars
+
+<<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
+independence than Java, e.g. we do not need to depend on IEEE
+floating-point representation).>>
+
+Yes, the methods of java.io.DataInputStream/java.io.DataOutputStream are
+specified to read/write numeric data in big-endian format.  The default
+readObject and writeObject methods of java.io.Serializable use these
+methods to write primitive data.
+
+It is important to remember that Ada and Java have different philosophical
+bases.  The Ada philosophy is to support portability to the extent possible
+while providing efficient direct access to the underlying hardware.  It is
+recognized that a given type will have different representations on
+different machines.  The Java philosophy is to specify a virtual machine
+and to mandate how data is represented on that machine.
+
+The Java world view is that the "real data" in a distributed application
+consists not of bit patterns, but of Java objects; serialization of object
+graphs into bit patterns is a necessary evil to pump objects through
+communication channels and to interoperate with legacy non-Java code.
+
+The Ada view (or at least my view of the Ada view) is that if several
+programs are to use a common stream representation for data, that common
+representation must be specified (e.g. XDR), and each program must
+explicitly override the stream-oriented attributes to map its own
+target-dependent representation of the data to and from that common stream
+representation.  One cannot generally depend on the default 'Write and
+'Read to map to and from this common representation.  (Thus I believe that
+all this attention to the DEFAULT behavior of the stream attributes is a
+tempest in a teapot.  Any program that is writing to a stream with a
+required format will override the stream attributes to achieve that
+format.)
+
+In Java, part of the contract of readObject is that it be able to read from
+object streams written by writeObject, and reconstitute the data.  This
+contract applies both to the default methods and to overriding versions
+written by application programmers.  The current (JDK 1.1.x) documentation
+does not specify the format of object representations in the stream because
+the output of writeObject is meant to be written only by readObject, not by
+other, non-Java applications.*  JavaSoft reluctantly recognized that it
+would be necessary to allow independent implementors to build their own
+JREs (JRE = Java Runtime Environment = JVM + class libraries) without
+licensing the Sun code, and thus it would be necessary to specify the
+default serialized stream representation exactly.  JDK 1.2 specifies a
+"serialization protocol" and an API providing primitives for reading and
+writing objects in accordance with this protocol.
+
+-- Norman
+
+*--The default format includes a lot of self-describing data.  This allows
+an object of an unknown subclass to be read from the stream and
+reassembled, in the manner of T'Class'Input.  It also allows the code for a
+class's methods to be downloaded from a remote machine if that code was not
+previously available locally. The specification of object fields by name
+rather than offset also allows the reading of objects whose classes have
+evolved through the addition of new fields since the objects were written:
+The readObject method for the new version recognizes the old version and
+fills in the missing data in some appropriate way; the readObject method
+for the old version is oblivious to the presence of another field in the
+new version.  (Chapter 13 of the Java Language Specification is
+specifically devoted to the ways in which a package, interface, or class
+may evolve while preserving compatibility with previous versions.)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent