Re: Standard library and distributed systems

[stt@houdini.camb.inmet.com (Tucker Taft)]

Andre Spiegel (spiegel@inf.fu-berlin.de) wrote:

: Thanks, Tucker, for your detailed reply.  You wrote:

: > Rather than removing things from these packages (which could be very
: > disruptive to existing Ada 95 code), we could envision
: > additional pragmas or rules to make them "safe."    The simplest
: > would be to have a pragma Not_Remote_Type(type); which could
: > simply mark a given type that happens to be declared in a 
: > Remote_Types package as not being allowed as a formal parameter type
: > in a remotely callable subprogram.

: The operations declared in a Remote_Types package are not "remotely
: callable subprograms", are they?  (Each partition that withes such a
: package gets its own copy; the only thing that's passed across
: partition boundaries are values of _types_ declared in such a
: package.)

: That means, for example, that Ada.Strings.Bounded doesn't make any
: "problematic" use of Ada.Strings.Maps.Character_Mapping_Function (it's
: only used as a parameter for some of the subprograms).  It would only
: be "problematic" if a Character_Mapping_Function were part of a _type_
: declared in Ada.Strings.Bounded.

: So how about this rule: a Remote_Types package may "with" a package
: that is not pure (and not Remote_Types), _provided_ that it doesn't
: make "problematic" use of it.

That would make some sense, since the body of a Remote_Types package
is completely unrestricted.  Essentially you would have to ensure
that it doesn't "reexport" evil things in its spec from some evil 
"with"ed unit.

: Maybe such a rule could enhance distributability of general Ada
: applications?  The additional rule would be even less expensive (or,
: intrusive) than an additional pragma.  (But of course it couldn't solve
: the problem of String_Access, so we'd need the pragma also.)

In general the Distributed Systems Annex was breaking new ground,
and I at least saw it as an initial cut at providing distribution
in the language.  Using the Ada/Corba bindings is another good way.
Defining a different set of pragmas is yet a third way.

Of course, the goal is to have something that is supported by
a critical mass of Ada 95 compilers, independent of whether it
is in the "official" ISO reference manual.  If you consider Annex E
as a "proof of concept" rather than as a finished product, then
identifying a small set of additional rules and pragmas to augment its
functionality seems completely appropriate, IMHO.  Getting them 
implemented by that "critical mass" is the next challenge...

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA