Version 1.4 of 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