Standard library and distributed systems

Standard library and distributed systems

[Andre Spiegel]

Last week I posted an article concerning distributability of types in
Ada's standard library.  There were no replies, so here is a second
try, hopefully a bit clearer.

The problem: Ada.Strings.Bounded and Ada.Strings.Unbounded are not
Remote_Types packages, which means that you cannot use bounded or
unbounded strings for interpartition communications in a distributed
system.  Since these types are very important, I find this a severe
restriction for distributed programming in Ada, and I wonder whether
this could be changed.

There is a proposal, documented in Ada Issue ai-00126 to make all
standard packages Remote_Types for which it is possible.  But even
under this proposal, Ada.Strings.Bounded and Ada.Strings.Unbounded
remain non-remote.

  (1) Ada.Strings.Bounded cannot be Remote_Types because it depends
      on Ada.Strings.Maps, which, according to ai-00126, cannot be 
      Remote_Types because it declares an access-to-subprogram type, 
      Character_Mapping_Function.

      I don't understand this.  According to RM95 E.2.2(9), a 
      Remote_Types package _may_ declare access-to-subprogram types.
      So I think that both Ada.Strings.Maps and Ada.Strings.Bounded
      could be Remote_Types.

  (2) Ada.Strings.Unbounded cannot be Remote_Types for an additional 
      reason: it declares type String_Access.  

      But this type is not used anywhere else in the visible part, and 
      I recall that people have been discussing whether this declaration 
      should be removed.  If it were removed, and Ada.Strings.Unbounded 
      privately defined Read and Write attributes for Unbounded_String, 
      then the type could be used for interpartition communications.

  (3) If, for example, Ada.Strings.Bounded were Remote_Types, I cannot
      imagine a scenario where Ada.Strings.Maps.Character_Mapping_Function
      would actually be used remotely (so that the function being pointed
      to would actually be called across partitions).  If this is correct,
      could it be that the language rules are too restrictive in this area?
      They forbid something which actually wouldn't cause any problems?

Please let me know whether the above reasoning is correct.  If not,
please tell me why not.  If it _is_ correct, is it planned to change
the standard library and/or the language rules?

Thanks,

Andre Spiegel
Free University of Berlin

Re: Standard library and distributed systems

[Samuel Tardieu]

>>>>> "Andre" == Andre Spiegel <spiegel@inf.fu-berlin.de> writes:

[...]

Andre> The problem: Ada.Strings.Bounded and Ada.Strings.Unbounded are
Andre> not Remote_Types packages, which means that you cannot use
Andre> bounded or unbounded strings for interpartition communications
Andre> in a distributed system.  Since these types are very important,
Andre> I find this a severe restriction for distributed programming in
Andre> Ada, and I wonder whether this could be changed.

Andre> There is a proposal, documented in Ada Issue ai-00126 to make
Andre> all standard packages Remote_Types for which it is possible.
Andre> But even under this proposal, Ada.Strings.Bounded and
Andre> Ada.Strings.Unbounded remain non-remote.

[...]

Andre> Please let me know whether the above reasoning is correct.  If
Andre> not, please tell me why not.  If it _is_ correct, is it planned
Andre> to change the standard library and/or the language rules?

Andre, I agree with most of your points, but I really wonder why you
want *so hard* to make these packages Remote_Types? Why don't you
define your own types in such a package? You have shown in your
multiple posts that it was not possible to use bounded and unbounded
strings as defined by the Annex A as remote types without changing
some standard's library specifications. This looks like a blocking
problem for you, and that I cannot understand.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Standard library and distributed systems

[Andre Spiegel]

Samuel Tardieu <sam@ada.eu.org> writes:

> Andre, I agree with most of your points, but I really wonder why you
> want *so hard* to make these packages Remote_Types? Why don't you
> define your own types in such a package? You have shown in your
> multiple posts that it was not possible to use bounded and unbounded
> strings as defined by the Annex A as remote types without changing
> some standard's library specifications. This looks like a blocking
> problem for you, and that I cannot understand.

Sorry, I didn't intend to become a nuisance ;-).  I only repeated my
question because I didn't get any answers at all.  And I did post to
the newsgroup because I saw my own question asked by somebody else
here, so it seems that I'm not the only person who considers the above
problem as a, well, "unfortunate" restriction.

Besides, I do think it's an important issue.  The features of Annex E
achieve a very high degree of distribution transparency -- Ada is much
better than other existing technologies like Java/RMI or CORBA in this
respect.  This allows you to develop applications without thinking
about distribution issues until very late in the development process.
Given this high transparency, one could also distribute existing,
non-distributed applications with very little or no changes to the
code.

Bounded_String and Unbounded_String are very important types that some
programmers use all over the place.  But in the current form of the
library, that means you cannot distribute such programs (or
components).  This is odd.  Especially if it could be achieved easily
-- and this is how it appears to me.

Sure I could write my own replacements for those packages.  But that
seems only a second-best guess if all that's required is a slight
change to the standard library that many other programmers would
also benefit from.

Finally, if my impression is correct that the language rules are
overly restrictive in this area, that is a lack of transparency which
will also affect the distributability of other programs and
components, not just those in the standard library.  It may not be
realistic to aim at 100 percent transparency -- but I wouldn't be
satisfied if, while writing a program, I had to think about
distributability all the time because Annex E is so restrictive.  As
far as I understand it, this is not the way it was meant to be.

Re: Standard library and distributed systems

[Tucker Taft]

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

: Last week I posted an article concerning distributability of types in
: Ada's standard library.  There were no replies, so here is a second
: try, hopefully a bit clearer.

: The problem: Ada.Strings.Bounded and Ada.Strings.Unbounded are not
: Remote_Types packages, which means that you cannot use bounded or
: unbounded strings for interpartition communications in a distributed
: system.  Since these types are very important, I find this a severe
: restriction for distributed programming in Ada, and I wonder whether
: this could be changed.
: ... 

I basically agree that we should endeavor to make all "interesting"
standard packages compatible either with pragma Pure or Remote_Types.
For Remote_Types, the package spec has to be preelaborable, and
any access types declared in the visible part of the package spec
are considered "remote" access types.  There are a number of restrictions
on the declaration and use of remote access types, and the 
Character_Mapping_Function in Ada.Strings.Maps and the String_Access
in Ada.Strings.Unbounded just don't cut it.

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.  For String_Access, an alternative
is to allow such a visible access type declaration to exist so long 
as there are 'Write and 'Read attributes specified that can safely 
transport such a value between partitions.  

For String_Access, it seems pretty obvious what 'Write/'Read would do,
namely have 'Write convert the access value into a stream representation 
of the designated string, and then have 'Read re-allocate the string in 
the heap on the receiving end.  Of course, this could end up as a 
horrible storage leak, so better might be to simply disallow String_Access
as a parameter type in remote calls.

In any case, I agree it would be nice to push Remote_Types further.
However, in the interim, using type String (or your own type) as the 
parameter type for a remote call, and doing the conversion to/from 
Unbounded_String manually does not seem excessively painful, since that 
is essentially what the 'Write/'Read for Unbounded_String must be doing 
anyway.

: Andre Spiegel
: Free University of Berlin

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

Re: Standard library and distributed systems

[Robert Dewar]

I like Tuck's proposal for the additional pragma, that sounds like the
best approach.

Re: Standard library and distributed systems

[Andre Spiegel]

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.

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.)

Re: Standard library and distributed systems

[Robert Dewar]

Andre said

<<Sure I could write my own replacements for those packages.  But that
seems only a second-best guess if all that's required is a slight
change to the standard library that many other programmers would
also benefit from.
>>


I trust you would not start from scratch, minor surgery to the GNAT 
versions of these packages would probably be sufficient :-)

Re: Standard library and distributed systems

[Andre Spiegel]

Robert said

> I trust you would not start from scratch, minor surgery to the GNAT 
> versions of these packages would probably be sufficient :-)

Of course :-).  As I hopefully made clear, I was only insisting on the
problems with bounded and unbounded strings because they seem examples
for a more general problem concerning the rules of Annex E, which
might be a bit over-restrictive altogether.

If my only problem was how to pass unbounded strings between
partitions, well, that is of course trivially solved using a slightly
adapted version of the GNAT packages.

Re: Standard library and distributed systems

[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