Re: Two ideas for the next Ada Standard

[jsa@alexandria (Jon S Anthony)]

In article <Dx7M7F.8vF@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> >If you are really this concerned about this why not just make the type
> >limited private?  Clients can't access the state (except through the
> >interface) and they can't assign the things.  For _clients_, it is
> >strictly _in_ mode.
> 
> But limited is not the same thing as constant.  An 'in' parameter is
> constant -- it cannot be modified.  An 'in out' parameter of a limited
> type is NOT constant -- it can be changed.

Yes, that is true.  I was refering to having access type to a limited
type, since "constant" access parameters were the context.  But, I
agree that I was not too clear:

    type T is ...limited private;

    procedure P ( x : access T );

Clients can't change T things unless you (interface provider) give them
the ability to do so.  If you do, then you should not be too surprised
when they do.


> Saying clients can't change it (except blah blah blah) isn't much
> help -- the fact is it *can* be changed, and it's easy for the
> client to change it -- just call something in the package that owns
> the type.

Well, sure, if you supply accessors to change the thing then of course
you can change them.  What could possibly be the point of such a
comment?

The real issue being discussed though is whether the _"owner"_ of the
type should be allowed to change such instances in the _implementation_
of the interface when it does not explicitly say it will WITHIN THE
LANGUAGE.  That is, whether the client should be able to look at the
interface and say with _absolute certainty_ that the given operation
does _not_ change the parameter.  That is a little odd to say the
least, as that requires "real" (aka, mathematical) functions.  And I
don't know of any programming language that does that (not even
"functional" languages).  That doesn't mean they don't exist (actually
they do exist as I designed one with this once - but never
implemented), I just don't know of any you can go out and use.


> Also, what about the primitive operations of the type?  The whole
> point of parameter modes is so that you can tell by looking at the
> spec, whether or not a given parameter can be changed.
                                         ^^^ 

What about primitive operations?  As for the "whole point..." bit,
this will never be sufficient.  If I want to, I can change an in mode
parameter just fine.  Behind your back.  Sure, you can say that I have
violated the contract, but so?  The point is, the modes do _not_
_guarantee_ anything.

 
> So, I don't buy the advice "use limited instead of access constant".

Well, you don't even have "access constant" so certainly _can't_ use
limited _instead_ of this.  The idea was to provide an equivalent
level of functionality.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com