What's Pure for Dist Sytems?

What's Pure for Dist Sytems?

[Dale Stanbrough]

After playing with Gnatdist and wanting to use it as a basis for some 
assignment work, I was struck by the extent of the restriction of only
Pragma Pure for "Remote Call Interface" packages.

I was especially upset at the restriction of no {un}bounded strings.

Is there anything that i'm missing here?


Dale

Re: What's Pure for Dist Sytems?

[Andre Spiegel]

Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes:

> After playing with Gnatdist and wanting to use it as a basis for some 
> assignment work, I was struck by the extent of the restriction of only
> Pragma Pure for "Remote Call Interface" packages.

> I was especially upset at the restriction of no {un}bounded strings.

> Is there anything that i'm missing here?

There is a proposal to add pragma Remote_Types to some of the
predefined packages (see Ada Issue ai-00126, at
http://sw-eng.falls-church.va.us/AdaIC/standards/95com/ada-issues/).

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

Andre Spiegel
Free University of Berlin

Re: What's Pure for Dist Sytems?

[Jon S Anthony]

In article <x2pvtianx1.fsf@inf.fu-berlin.de> Andre Spiegel <spiegel@inf.fu-berlin.de> writes:

> > I was especially upset at the restriction of no {un}bounded strings.
> 
> > Is there anything that i'm missing here?
> 
> There is a proposal to add pragma Remote_Types to some of the
> predefined packages (see Ada Issue ai-00126, at
> http://sw-eng.falls-church.va.us/AdaIC/standards/95com/ada-issues/).
> 
> 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...

Use CORBA?  The Ada=>IDL mapping fully supports this sort of thing.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: What's Pure for Dist Sytems?

[Andre Spiegel]

jsa@alexandria.organon.com (Jon S Anthony) writes:

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

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

> Use CORBA?  The Ada=>IDL mapping fully supports this sort of thing.

The nice thing about the Distributed Systems Annex is that it allows
to distribute existing applications that were developed without
distribution in mind.  With CORBA it's usually different: you have to
start by writing IDL for (at least) those objects that you want to
distribute, and in your Ada code, you have to adhere to a programming
style that is dictated by CORBA.  I would rather use Ada only, and not
care about distribution issues until very late in the development
process.

But you said "Ada=>IDL mapping"?  Do you mean there's a reverse
mapping that allows CORBA to be used for distributing existing Ada
applications?  That might be a different story.

Andre Spiegel
Free University of Berlin

Re: What's Pure for Dist Sytems?

[Jon S Anthony]

In article <x2bu51302t.fsf@inf.fu-berlin.de> Andre Spiegel <spiegel@inf.fu-berlin.de> writes:

> jsa@alexandria.organon.com (Jon S Anthony) writes:
> 
> > Use CORBA?  The Ada=>IDL mapping fully supports this sort of thing.
> 
> The nice thing about the Distributed Systems Annex is that it allows
> to distribute existing applications that were developed without
> distribution in mind.  With CORBA it's usually different: you have to
> start by writing IDL for (at least) those objects that you want to
> distribute, and in your Ada code, you have to adhere to a programming
> style that is dictated by CORBA.

I don't think it forces that much.  I mean it is pretty simple to put
a CORBA wrapper around an existing set of capabilities.  But you do
have to write the IDL for the interface(s)...


> I would rather use Ada only, and not care about distribution issues
> until very late in the development process.

Check.


> But you said "Ada=>IDL mapping"?  Do you mean there's a reverse
> mapping that allows CORBA to be used for distributing existing Ada
> applications?  That might be a different story.

No, I just fumbled the order...  There was talk at one point for doing
the Ada => IDL direction but nothing has come of it.  Yet.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: What's Pure for Dist Sytems?

[Robert Dewar]

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

Re: What's Pure for Dist Sytems?

[Andre Spiegel]

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