Version 1.4 of ais/ai-00208.txt

Unformatted version of ais/ai-00208.txt version 1.4
Other versions for file ais/ai-00208.txt

!standard E.2 (13)          98-10-14 AI95-00208/02
!class binding interpretation 98-10-10
!status work item 98-10-13
!status received 98-10-01
!priority Medium
!difficulty Hard
!subject What is the meaning of "same representation" in all partitions?
!summary 98-10-14
For the purposes of this AI, we introduce the term "shareable library package". Such a package is a Declared Pure or Shared Passive library package, or the definition of a Remote Types or Remote Call Interface library package.
Paragraph E.2(13) is replaced with a much weaker requirement that each type used in a shareable library package must have identical definitions.
!question 98-10-10
E.2(13) says:
"Implementation Requirements:
For a given library-level type declared in a preelaborated library unit or in the declaration of a remote types or remote call interface library unit, the implementation shall choose the same representation for the type upon each elaboration of the type's declaration for different partitions of the same program."
First, is it intentional that an implementation has to choose identical representations even for units mentioned in a pragma Preelaborate (which is not a categorization pragma as far as distribution is concerned)? Wouldn't it be better to spell out that types declared in pure or shared passive library units are meant? (Yes.)
Second, E.2(13) seems overly restrictive. It means that Ada 95 supports heterogeneous distributed systems only if the implementation manages to use the same representation for a type on all nodes. Is this intended? (No.)
!recommendation 98-10-10
(See summary.)
!wording 98-10-14
Replace E.2(13) by:
The definition of each type used in a declared pure or shared passive library unit, or in the declaration of a remote types or remote call interface library unit shall not differ in a semantically significant way. This means that each type must have the same bounds, digits value, etc. (Note: This constrains standard types to have identical definitions in a heterogenous distributed system; other types must always have identical definitions.)
!discussion 98-10-14
The requirement for the same representation for types in preelaborated packages which do not participate in distribution (that is, if the package is not a shareable library package) has no possible need. There can be no reason for the distribution annex to constrain anything which is not distributed.
Similarly, the requirement for the same representation for types in shareable library packages is over-specification. What is required is that the types have identical semantics and have consistent values when remotely accessed. While requiring the same representation insures that the requirement is met, it prevents many possible heterogeneous systems. For instance, the byte order of integer types may be different on different processors, but this has no effect on the semantics of the types.
If an implementation uses a representation independent format for its communication between partitions, heterogeneous distributed systems on processors with differing numeric formats can be supported. (Note that the storage element stream for a scalar type is implementation defined). Such an implementation could correctly support all of the semantics of Annex E.
Such heterogeneous systems have been used in avionics to insure that answers calculated are independent of implementation and processor errors. This is done by calculating answers on several different processors (each with its own executable code), and comparing them. Ada should support the construction of such systems with each processor running one or more active partitions.
Completely striking the rule goes too far, however. We need to require that all shareable types in a distributed program have the same semantics. This is trivially true in a homogeneous system and for user-defined types, but for a heterogeneous system, the implementation-defined standard types could vary without this rule. For instance, if Integer has a different range in two partitions of the same program, the value sets for a shared passive object could be different. That means that a value assigned in one partition without error could actually cause a bounded error if read on a different partition. The problem is especially serious if the precision of a float or fixed point type is different in each partition.
The Pure standard packages which contain implementation-defined definitions are Standard, Interfaces, Interfaces.C, Interfaces.Fortran. These are the only packages affected by the rule.
We only include types used by the distributed program in the requirement, so that an implementation can allow the use of some predefined types while rejecting others. For instance, float types may not be able to meet this rule on a particular pair of processors, while integer types can. (This would occur, for example, on distributed system including a VAX and Intel Pentium processor.) An implementation for such a heterogeneous system could allow the use of integer types in shareable library packages, while rejecting the use of floating point types in those packages. (It can do this by invoking 1.1.3(6)).
!appendix

!topic     Ada 95 and Heterogeneous Distributed Systems
!reference RM95-E(6), RM-95-E.2(13)
!from      Thomas Wolf 1998-08-06
<<reference as: 1998-15886.a Thomas Wolf 1998-8-18>>
!discussion

Why does the RM require same representations of types used in remote
communications?

After all, the RM also allows execution of a distributed Ada 95
application on a heterogeneous distributed system, for E(6) states:

  "Implementation Permissions:
   An implementation may require that the set of processing nodes of a
   distributed system be homogeneous."

This implies clearly that the annex itself is open enough to allow
execution of an application in a heterogeneous distributed system.
Otherwise, this implementation permission would be superfluous, and
instead there should be a requirement somewhere that only homogeneous
nodes may be used.

However, E.2(13) says:

  "Implementation Requirements:
   For a given library-level type declared in a preelaborated library
   unit or in the declaration of a remote types or remote call
   interface library unit, the implementation shall choose the same
   representation for the type upon each elaboration of the type's
   declaration for different partitions of the same program."

First, is it intentional that an implementation has to choose identical
representations even for units mentioned in a pragma Preelaborate (which
is not a categorization pragma as far as distribution is concerned)?
Wouldn't it be better to spell out that types declared in pure or
shared passive library units are meant?

Second, E.2(13) seems overly restrictive to me. It means that Ada 95
supports heterogeneous distributed systems only if the implementation
manages to use the same representation for a type on all nodes.

What exactly is the meaning of "representation" here? If it means
"external, marshaled representation", then the paragraph is ok, but
this interpretation of "representation" in this context should be
clearly mentioned in the RM. If it means "bit-by-bit identity" (and
I think this is the case), then the requirement is too strong: it
would even take endian-ness into account, but that has no effect
on the semantics of the type!

I think it would be sufficient to require only that an implementation
use the same *declarations* for all types in package Standard or in any
of the other standard library units that are declared pure.

This makes sure that all aspects left "implementation-defined" in the
standard library are identical on all partitions in the distributed
application. If an implementation *can* actually provide equal
representations on all platforms in a heterogeneous distributed
system, fine, then it can save some conversion overhead; but if it
can't, it still has the freedom to insert conversions between
representations as needed.

What was the reason for the requirement in E.2(13)? I can only
speculate, as neither the RM, nor the Rationale, nor the Annotated
RM give any hints. I don't see any compelling reason for it.
In what follows, I try to show that the much weaker requirement
of equal type definitions for standard types is sufficient and
considerably widens the applicability of Ada 95 to heterogenous
distributed systems.

Some possible rationales for E.2(13) I could come up with:

(1) Standard is a pure package, and we want the standard types to have
    the same representation.

    I don't think this is necessary. What I'd really want in a hetero-
    geneous system is that the standard types have the same definition,
    i.e., the same *ranges and precisions*. If that is given, their
    semantics will be the same even on different platforms! What bit
    patterns, alignments, and so on are used on different platforms is
    immaterial as long as the stream atrtributes ('Read, 'Write, 'Input,
    'Output) on all platforms in the heterogeneous distributed system
    agree on a machine-independent encoding. Such encodings exist, and
    even though they may not be standardized by an ISO standard, an
    implementation can use them for marshaling/unmarshaling.

(2) If a user declares a type in a pure package for instance, we want
    to be able to use that type in remote communications (as a formal
    parameter type of a remotely callable subprogram, perhaps), so
    representations must be identical.

    Not true in my opinion. The semantics of a type is defined by its
    declaration, not by its representation. If I declare a type

       type My_Integer is range -Something .. +Something;

    I don't care about its representation as far as remote communication
    is concerned. Again, all that is needed is that the stream
    attributes for the type agree on a common marshaled format, from
    which they can reproduce the value at both ends of the line. It
    would therefore be sufficient to require only that the types have
    identical definitions (ranges/precisions). This is trivially true
    for any application-defined type, as the same source is used.
    Therefore, the requirement that all standard types have the same
    definition on all partitions would be good enough.

(3) Identical representations are needed because of shared passive
    packages because several active partitions may exchange data through
    a shared passive package.

    I don't think this needs identical representations. There are two
    case to consider:

    (a) Shared passive packages implemented using true, hardware-
        shared memory. In this case, I think all partitions that will
        ever access the shared passive package will execute on homo-
        geneous nodes. Or is there any real system where heterogeneous
        nodes have access to a true, hardware-shared memory? I don't
        know of any. If there isn't any, there's no need to *require*
        "same representations": this will be always true anyway.

        Even if such a shared memory system existed, it would be
        sufficient to require that an implementation choose the same
        representation for types used in a shared passive library unit
        on all partitions that access that shared passive library unit.
        There's no need to require this for all partitions, nor is it
        necessary to require it for all types in active partitions, nor
        is it necessary to require it for types declared in remote types
        or remote call interfacelibrary units.

    (b) Shared passive packages implemented using a (distributed) shared
        memory system, i.e., software that makes the memory appear
        shared. In this case, accesses to the shared passive partition
        can easily be translated by the compiler to include marshaling
        upon writing and unmarshaling upon reading. The stream attributes
        can perform any necessary conversions of representations provided
        that types have the same definitions (range/precision) on all
        partitions involved.

(4) Identical representations are needed for remote access values.

    Again, I do not agree. For these types, there always happens
    marshaling/unmarshaling, where any necessary conversions can be
    done. (This, by the way, is true for any library-level type declared
    in the specifications of remote types or remote call interface
    units. Requiring identical representations for types in RT or RCI
    units seems to me as overspecification even regardless of shared
    passive packages.) The absence of a standard for a machine-indepen-
    dent encoding doesn't matter. Such encodings exist, and an imple-
    mentation can use them.

    Remote access types and remote dispatching can be implemented even
    if remote types have different representations on different
    partitions.

    I'll try to illustrate this with the following example: consider
    three partitions A, B, and C. B gets a remote access to some object
    on A (necessarily by invoking a remotely callable subprogram on A)
    and later passes this remote access value on to C. C then makes a
    remote dispatching call on this remote access value. A uses the
    pair (Partition_ID, 64bit address) for a remote access, B uses a
    different format (Partition_ID, 32bit address), and C may or may
    not use yet another representation. Consider the following steps:

    B gets the remote access from A:

     Partition B:                      Partition A:
          |                                 |
        1. Makes remote call -------------->|
          |                            2. Executes remote call,
          |                               computing the remote access
          |                               (A.PID, A.Adress64).
          |                                 |
          |                            3. Marshals (A.PID, A.Adress64).
          |                                 |
          |<---------------------------4. Sends back answer message
          |                               containing the marshaled remote
          |                               access value.
        5. Unmarshals the remote            |
           access by doing the              |
           following:                       |
           - Store the *marshaled* remote   |
             access in some data structure. |
           - Set the 32bit address of the   |
             remote access to the address of|
             the stored marshaled remote    |
             access value.                  |
           |                                |
         6. Pass on this value to the       |
            application.                    |

    B passes the remote access value on to C:

     Partition B:                       Partition C:
          |                                  |
        7. Marshals the remote access        |
           value by:                         |
           - Using the 32bit address to      |
             retrieve the stored marshaled   |
             representation originally       |
             received from A.                |
          |                                  |
        8. Makes remote call containing      |
           the original marshaled remote     |
           access value as received from     |
           A.------------------------------->|
          |                             9. Unmarshals the remote access
          |                                value in the same manner as
          |                                in 5 above, i.e., keeping the
          |                                marshaled version!
          |                                  |
          |                            10. Pass on local representative
          |                                value to the application.

    C makes dispatching call on the remote access value:

     Partition C:                       Partition A:
          |                                  |
       11. Make remote call request          |
           using the stored marshaled        |
           version of the remote access----->|
          |                                  |
          |                             9. Unmarshals the remote access
          |                                value, obtaining A.Address64
          |                                  |
          |                            10. Uses A.Address64 to make the
                                           dispatching call.

    Note that neither B nor C need to know that A uses a 64bit local
    address. They can represent a remote access value locally using a
    simple hashing scheme even though their own representation cannot
    hold a 64bit address. The partitions must only agree on the
    definition of partition IDs and their marshaled representation,
    just like for any other numeric type. Whenever a remote operation
    is done with a remote access, the original marshaled version
    created by A is passed around, not the local representative value.
    Thus, when the value comes back to A, e.g., in a dispatching call,
    A can unmarshal it and recreate its own 64bit address despite the
    value having passed through numerous partitions where it could not
    be represented in unmarshaled form.

(5) An application may use representation items for types declared in
    pure, shared passive, remote types, or remote call interface units.
    Since the same sources (except possibly for the standard packages)
    are used on all nodes, these types must have the same representa-
    tions.

    Well, yes. But in this case, the application developer is respons-
    ible. He should know what he's doing. If he specifies a certain
    representation, and the implementation cannot implement it,
    compilation will fail. Therefore, this case doesn't matter at all
    for heterogeneous distributed systems.

In summary, I see no compelling reason to require identical
representations for library-level types declared in preelaborated
library units or in the declarations of remote types or remote call
interface library units.

I think it is sufficient to require that all types declared in the
standard library units declared pure have the same declaration on all
nodes in the distributed system. (For application-defined types, this
is trivially true for any type declared in a pure, shared passive,
remote types, or remote call interface unit, as the same source is used
on any node.) Thus the semantics of the types are the same on all nodes,
and the overall behavior will be consistent.

Is there some other reason for E.2(13)? If so, I'd like to know. If not,
I'd very much like to see the issue of representation cleared up, maybe
in the way I proposed above.

Best regards,

  Thomas Wolf

-- 
----------------------------------------------------------------------
Thomas Wolf - Swiss Federal Institute of Technology - CH-1015 Lausanne
e-mail: wolf@di.epfl.ch              www: http://lglwww.epfl.ch/~wolf/

***********************************************************

!topic     Ada 95 and Heterogeneous Distributed Systems
!reference RM95-E(6), RM-95-E.2(13)
!from      Anthony Gargaro 1998-08-19
!reference 1998-15886.a Thomas Wolf 1998-8-18
<<reference as: 1998-15890.a Anthony Gargaro  1998-8-19>>
!discussion

>Second, E.2(13) seems overly restrictive to me. It means that Ada 95
>supports heterogeneous distributed systems only if the implementation
>manages to use the same representation for a type on all nodes.

I agree that such an interpretation does appear overly restrictive.
For a distributed system comprising heterogeneous processing nodes,
it seems reasonable that "same representation" should be interpreted as
pertaining to "same stream representation."

***********************************************************

!from Randy Brukardt

At the St. Quentin meeting, we discussed this issue at length.  The discussion
eventually converged on the idea that the paragraph in question is over-
specification. The requirement is that shared and remote types work, not that
any particular method be used to cause them to work.

For homogeneous systems, it probably is easier for an implementation to follow
this rule, while for a heterogeneous system, this may be required (in a shared
memory system, such as a VME bus with two different processors) or
impossible (such as floating point on a VAX and PC).

Note that the stream representation of scalar types is implementation-defined.
This gives the implementation freedom to use an architecture-neutral format if
required for a distributed implementation.

Robert Dewar offered an example of a similar over-specification:
	"For the operation "+", the implementation should emit a Add
instruction if one exists for the target."

While this obviously makes sense, it would prevent some optimizations
(such as using a Subtract operation if the operand was always negative).
The language should only be concerned that the feature works as specified,
not that it be implemented in specific ways.

After meeting aside:

I wonder if the standard includes enough information to define "correct
behavior" without some form of this paragraph. The intent is that the
value of an object in a shared passive package, or of a remote type, is
interpreted the same way in each partition. The old paragraph provided that
via over-specification - is saying it still necessary??

The author of the original question suggested that requiring that all
standard types (in Pure packages) have the same definition in all partitions.
Is this needed?  It seems to be needed to prevent different partitions having
different semantics for shared types.

An alternative wording for the rule would be:

The implementation shall support remote access of each type used in a declared
pure or shared passive library unit, or in the declaration of a remote types or
remote call interface library unit. Such access must insure consistent values
in each partition.

I didn't use this because "consistent values" is too hard to define. In
addition, the actual requirement on the implementation (that the standard
types used have the same semantics, implying identical definitions) is hard
to see.

***********************************************************

From: 	Jean-Pierre Rosen[SMTP:rosen.adalog@WANADOO.FR]
Sent: 	Tuesday, October 13, 1998 2:13 AM
Subject: 	Re: AI-0208

>!summary 98-10-10
>
>For the purposes of this AI, we introduce the term "shareable
>library package".  Such a package is a Declared Pure or Shared Passive library
>package, or the definition of a Remote Types or Remote Call Interface library
>package.
I don't think this term is correct. We are not talking about packages, but types. A declared pure package is not shared, but can declare types that can be shared.
Moreover, I didn't see where this term was used in the rest of the AI...

>!wording 98-10-10
>
>Replace E.2(13) by:
>
>The definition of each type used in a declared pure or shared passive library
>unit, or in the declaration of a remote types or remote call interface library
>unit shall be the same. This means that each type must have the same bounds,
>digits value, etc. (Note: This constrains standard types to have identical
>definitions in a heterogenous distributed system; other types must always
>have identical definitions, as they .)

This is already ensured by normal rules of the language. In the annex E model,
we are talking only of a single *program*, therefore each package, including
Standard, is present only once (although possibly duplicated at run time). This
may require some magic in the case of heterogeneous systems.

The conclusion we reached, as far as I remember, was to keep E.2(13) almost as
is, with a statement that "representation" addressed the implementation-defined
representation of elementary types in a stream.

>Such heterogeneous systems have been used in avionics to insure that answers
>calculated are independent of implementation and processor errors. This is
>done by calculating answers on several different processors (each with its
>own program), and comparing them. Ada should support the construction of
>such systems.

Note that if they are different *programs*, we are out of the scope of annex E.

>Completely striking the rule goes too far, however. We need to require that
>all sharable types in a distributed program have the same semantics.  This is
>trivially true in a homogeneous system and for user-defined types, but for a
>heterogeneous system, the implementation-defined standard types could
>vary without this rule. For instance, if Integer has a different range in two
>partitions of the same program, the value sets for a shared passive object
>could be different. 
Not under current rules.

>The Pure standard packages which contain implementation-defined definitions
>are Standard, Interfaces, Interfaces.C, Interfaces.Fortran. These are the only
>packages affected by the rule.

Id.

***********************************************************

From: 	Pascal Leroy[SMTP:phl@Rational.Com]
Sent: 	Tuesday, October 13, 1998 7:34 AM
Subject: 	Re: AI-0208

> Here is my write up for AI-208. Note that the "standard type" issue wasn't
> discussed at the meeting, but I believe that the original questioner was
> correct on this issue.

The conclusion of the discussion during the meeting was to remove paragraph
E.2(13) entirely.  I still think it was the right decision.  I certainly
disagree with most of the new write-up.

The wording has: "The definition of each type ... shall be the same."  How do
you define "the same"?  If you try to define this term, you run into the issue
of which differencs are acceptable and which aren't.  We carefully avoided
this issue by using the vague phrase "semantically significant" in E.3(5).
 The wording could/should be phrased in terms of "semantically significant"
differences, but since this is an unspecified notion, it doesn't guarantee
much.

More importantly, I think that the restriction on standard types is neither
necessary nor sufficient.

The AI as written precludes an heterogeneous implementation with a 32-bit
Integer on one node and a 64-bit Integer on another node.  I am not sure why
we need this restriction.  Since the exchange of data is phrased in terms of
streams, an attempt to pass a value larger than 2 ** 31 - 1 from the 64-bit
machine to the 32-bit machine will raise C_E as per 13.13.2(35).  The
discussion section states that this could cause bounding errors, but I think
that's incorrect.  It just means that the implementation has to perform extra
work: it cannot just dump bytes in shared memory without checking.  That may
be expensive/complex to implement, but that's not a reason to disallow such an
 implementation.

The requirement that the types be "the same" does not achieve the intended
effect in the case of floating-point types.  The fact that two types have the
same digits and bounds does not guarantee that they have the same physical
representation: they could have different Machine_Radix, one could have denorm
numbers and the other not, etc.

I propose to strike out E.2(13) and assume that implementors will do the right
thing.

Pascal

***********************************************************

From: 	Robert Dewar[SMTP:dewar@GNAT.COM]
Sent: 	Tuesday, October 13, 1998 7:45 AM
Subject: 	Re: AI-0208

<<The wording has: "The definition of each type ... shall be the same."  How do
you define "the same"?  If you try to define this term, you run into the issue
of which differencs are acceptable and which aren't.  We carefully avoided
this issue by using the vague phrase "semantically significant" in E.3(5).
 The wording could/should be phrased in terms of "semantically significant"
differences, but since this is an unspecified notion, it doesn't guarantee
much.
>>

I think the change to semantically significant is reasonable

<<The AI as written precludes an heterogeneous implementation with a 32-bit
Integer on one node and a 64-bit Integer on another node.  I am not sure why
we need this restriction.  Since the exchange of data is phrased in terms of
streams, an attempt to pass a value larger than 2 ** 31 - 1 from the 64-bit
machine to the 32-bit machine will raise C_E as per 13.13.2(35).  The
discussion section states that this could cause bounding errors, but I think
that's incorrect.  It just means that the implementation has to perform extra
work: it cannot just dump bytes in shared memory without checking.  That may
be expensive/complex to implement, but that's not a reason to disallow such an
 implementation.
>>

I think it is reasonable to preclude such an implementation. It is bad
enough to use unspecified standard types *at all*, but to use them in
the context of heterogenous implementations of distribution where the
types have "semantically significant" differences seems complete nonsense
to me, and I see no reason for the RM to encourage or permit such usage.

Furthermore, even a slight encouragement to implement this will add a layer
of inefficiency to heterogenous distribution. Note that you have to use
something like XDR to write out data for heterogensou stuff, fair enough,
but you can still assume to know *what* you are reading, i.e. is it a
4-byte or 16-byte integer. If you are not allowed to know that, you need
an even more heroic format for data interchange, and it is not worth
it simply to allow these predefined types.

Which all acts as a reminder, I am going to put in a warning in our
implementation of shared passive if people use standard types in the shared
passive package :-)

***********************************************************

From: 	David Emery[SMTP:emery@MITRE.ORG]
Sent: 	Tuesday, October 13, 1998 8:20 AM
Subject: 	Re: AI-0208

From a naive user's perspective, I have a few questions:
        1.  what type should I use for "a convenient integer"?  A good example
            is the index for a string.  I don't need to constrain the range of values,
            but I just want an efficient integral type.
        2.  What will be the effect of all this on passing strings?

                        dave

David Emery, The MITRE Corp, emery@mitre.org
Reston: +1 703 883 7606, fax: 883-6143;
Pentagon: +1 703 695-9999, fax 695-5213

***********************************************************

From: 	Robert Dewar[SMTP:dewar@GNAT.COM]
Sent: 	Tuesday, October 13, 1998 8:52 AM
Subject: 	Re: AI-0208

For shared data in a heterogenous environment, you definitely need to
say WHAT integer, and the idea of an integer that is convenient on all
possible architectures is dubious!

For strings, in GNAT, we assume that bounds are always 32-bits regardless.
That will always be true for GNAT implementations, but you are right, it is
potentially troublesome for any implementation that is inconsistent here.

***********************************************************

From: 	Randy Brukardt[SMTP:Randy@RRSOFTWARE.COM]
Sent: 	Tuesday, October 13, 1998 12:31 PM
Subject: 	Re: AI-0208

>>For the purposes of this AI, we introduce the term "shareable
>>library package".  Such a package is a Declared Pure or Shared Passive
library
>>package, or the definition of a Remote Types or Remote Call Interface
library
>>package.
>I don't think this term is correct. We are not talking about packages, but
types. A declared >pure package is not shared, but can declare types that
can be shared.
>Moreover, I didn't see where this term was used in the rest of the AI...

It's used in several places in the discussion. Without it, the discussion
is either
unreadable or technically incorrect.  We use it to talk about the places
where the
rule applies (the original rule, or the revised rule). Note that it is NOT
used in the
revised wording. If you have a better suggestion, please make it.

>The conclusion we reached, as far as I remember, was to keep E.2(13)
almost as is, with a >statement that "representation" addressed the
implementation-defined representation of >elementary types in a stream.

Your memory is faulty. See the minutes.

                                Randy.

***********************************************************

From: 	Jean-Pierre Rosen[SMTP:rosen.adalog@WANADOO.FR]
Sent: 	Wednesday, October 14, 1998 3:22 AM
Subject: 	Re: AI-0208

>>>For the purposes of this AI, we introduce the term "shareable
>>>library package".  Such a package is a Declared Pure or Shared Passive
>library
>>>package, or the definition of a Remote Types or Remote Call Interface
>library
>>>package.
>>I don't think this term is correct. We are not talking about packages, but
>types. A declared >pure package is not shared, but can declare types that
>can be shared.
>>Moreover, I didn't see where this term was used in the rest of the AI...
>
>It's used in several places in the discussion. Without it, the discussion
>is either
>unreadable or technically incorrect.  We use it to talk about the places
>where the
>rule applies (the original rule, or the revised rule). Note that it is NOT
>used in the
>revised wording. If you have a better suggestion, please make it.

In the discussion, "shareable" is spelled "sharable", which explains why a quick
search didn't find it... Note that in one occurrence (in a total of three), you
are talking about sharable *types*, which is better in my view. Anyway, I don't
think we need this notion anyway (see below).

>>The conclusion we reached, as far as I remember, was to keep E.2(13)
>almost as is, with a >statement that "representation" addressed the
>implementation-defined representation of >elementary types in a stream.
>
>Your memory is faulty. See the minutes.

The minutes say the agreement was to remove the paragraph, not to change it. I
reread the AI, and now I see why you want to rephrase it this way. The question
actually assumes that in an heterogeneous implementation, each partition gets a
*different* Standard package. However, I don't think this is correct. The model
is that there is only one set of packages for the whole *program* (i.e. for all
partitions). Standard is a pure package, therefore it is duplicated in each
partition. Since each partition is elaborated independantly, types defined in
Standard (as well as in any other duplicated package) can have different
representations; however, there is only one *definition* of the standard types,
and therefore no risk of discrepancies.

We decided to remove the paragraph completely on the ground that an
implementation was required to work, and that it automatically implied that
stream representations had to be consistent. Saying that "representation" means
"stream representation" is just an enforcement of this, which answers the
question as stated.

***********************************************************

From: 	Robert Dewar
Sent: 	Wednesday, October 14, 1998 6:50 AM
Subject: 	Re: AI-0208

<<I reread the AI, and now I see why you want to rephrase it this way. The =
question actually assumes that in an heterogeneous implementation, each =
partition gets a *different* Standard package. However, I don't think =
this is correct. The model is that there is only one set of packages for =
the whole *program* (i.e. for all partitions). Standard is a pure =
package, therefore it is duplicated in each partition. Since each =
partition is elaborated independantly, types defined in Standard (as =
well as in any other duplicated package) can have different =
representations; however, there is only one *definition* of the standard =
types, and therefore no risk of discrepancies.
>>

That has got to be wrong, if you are on a heterogenous network, different
platforms will have different definitions of the float types, in terms of
range precision, and representation. This works just fine right now, and
there is no point in having any language in the RM that suggests that it
should not!

***********************************************************

Questions? Ask the ACAA Technical Agent