Subprogram types vs. "limited access" (was Re: Do we need "Mission-Critical" software? Was: What to Do?

[mark_lundquist@my-deja.com]

In article <93mqhh$4gl$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <93l6ut$pvf$1@nnrp1.deja.com>,
>   mark_lundquist@my-deja.com wrote:

> > Java wanted to get rid of pointer-related bugs.  Unfortunately, you
> > kind of have to have pointers!
>
> Yes, but rare.

I meant for linked data structures... you need by-reference semantics,
or in a by-value language you need pointers.  It's hard to believe
Gosling et al would not see past the C conception of
pointer=address=integer.  For whatever reasons they went with a by-
reference design.  Who can say...

> BTW (if Robert does not hear us (:-)) I think that Ada
> shuld have true subroutine types (not only pointers).  The values are
> passed by reference (always IN),
> so in may cases the clusy trick
> with generics will be not required.

The downward closure thing again, huh?

You have to define this idea of a procedure type to be limited (like a
task) in order to really solve the problem, right?  Note that that
makes anything but an IN parameter illegal, so you also solve that
problem without having to create essentially a new kind of parameter
(as access parameters were).

The first problem with subprogram parameters is a syntactic one -- what
syntax do you use to establish its profile?  Subprogram types as you
suggest are one way to solve that problem, and they seem consistent
with the "Ada way" (every parameter is of a named subtype).

e.g.,

    type Action is procedure (This : in Something);
    type Predicate is function (This : in Something) return Boolean;

Is that the idea?

The conformance rules for parameters of these types would then have to
be more like the matching rules for generic formal subprograms, or
subprogram renamings.  That is, you don't declare a function to be of
type Predicate (per the example), you declare a function in the normal
way and then it matches a subprogram of type Predicate.  Right?

That _is_ a bit of a stretch to the philosophy of the type system.  The
essential idea of a type is that it's a template for the creation of
objects.  Every type in Ada is an object type; this breaks that
regularity.  This would be a type that not only doesn't have objects as
its instances, it doesn't have instances at all!  It's just a vehicle
for carrying around a profile.  So from that perspective it's a little
bizarre.

Another idea that went around, I think during the Ada9x process, was
that of a "limited access" type.  This is a real object type, so it's
more consistent with the rest of the Ada type system.  Limitedness
solves the accessibility problem for downward closures.

Bob Duff wrote an AI on this.  The verdict was that the ramifications
were negligible for implementations that used static links, but would
be quite burdensome for implementations that use displays, so the idea
was rejected.

I wonder, are there any (current) Ada implementations out there that
use displays for nested context?  I'm not a compiler expert; what
factors constrain the choice of static link vs. display?  Are there
aspects of the target that favor one or the other?  I just don't know...

Other access types could be limited as well, not just access-to-
subprogram, and limited access is useful for other things besides
downward closure.  I'd like to see this feature added.

-- mark


Sent via Deja.com
http://www.deja.com/