Re: What's Pure for Dist Sytems?

[Andre Spiegel <spiegel@inf.fu-berlin.de>]

Robert Dewar writes:

> Andre says
> 
> <<However, even under this proposal, Ada.Strings.Bounded and
> Ada.Strings.Unbounded are still non-remote.  I find this an
> intolerable restriction, too, and I wonder if anyone sets out to
> remedy this...>>

> Finding something intolerable does not constitute a solution. I assume you
> understand *why* this rule is there. What is your proposal to "remedy this".

As a matter of fact, I don't fully understand why these packages
cannot be Remote_Types.  This is how far I can follow the reasoning
(please correct me if I'm wrong on any of this)

  - Ada.Strings.Unbounded cannot be remote, because

    (a) it depends on Ada.Strings.Maps, which cannot be pure because
        it declares an access-to-subprogram type
        (Character_Mapping_Function).  But I don't see why this
        package cannot be Remote_Types.

    (b) Ada.Strings.Unbounded declares type String_Access, which is
        however not needed in the rest of the spec, and I recall that
        some people wondered if this type should be removed from the
        visible part of the specification.

    (c) if these two problems weren't there, one only would have to
        make sure that the package privately defines Read and Write
        attributes for Unbounded_String -- something that the GNAT
        version of the package already seems to do, judging from
        what I saw last time I looked.

   - Ada.Strings.Bounded cannot be remote, because it depends on 
     Ada.Strings.Maps -- same reason as above.  I don't see any other
     obstacles for Ada.Strings.Bounded.

But what is the problem with Character_Mapping_Function anyway?  If
the string packages were Remote_Types, and Ada.Strings.Maps wasn't,
how could a Character_Mapping_Function be used remotely then -- except
by withing Ada.Strings.Maps _directly_ in the spec of a
Remote_Call_Interface?

RM95 E.2.2(6) says that a Remote_Types unit may only depend
semantically on declared pure, remote types, or shared passive units.
As far as I understand, this rule ensures that no remote variable
reference, remote rendezvous, or unwanted remote access to anything is
possible in a program.  However, the predefined string packages use
Ada.Strings.Maps only in such a way that no problems could arise from
this, even if Ada.Strings.Maps had something in it that couldn't be
made remote.

So maybe the package categorization rules forbid more than they would
have to?  Could this be helped by different, possibly more complex
rules that only forbid things that really cause problems?

Andre Spiegel
Free University of Berlin