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

[dmitry6243@my-deja.com]

In article <93vonj$3td$1@nnrp1.deja.com>,
  mark_lundquist@my-deja.com wrote:

> Ada95 defined a new kind of access type, the access-to-subprogram
> type.  It's a real object type with real object values, even if the
> value is a pointer that denotes something other than an object.  You
> propose an altogether new kind of type that is unprecendented in that
> it does not describe objects, but subprograms.  It is so unrelated to
> the concept of an object type that it doesn't seem legitimate to even
> call it a type, except to make the nice syntax for declaring
> subprogram parameters!  The tail wagging the dog, in other words.

What if I'd formally say, imagine objects of subprogram type as
tasks. Each time the subprogram is called, the caller is stopped
and the task continues, upon return task is stopped and the caller
is resumed. Tasks are "true" Ada objects, right?

> The concepts of type and object are inseparable.  To have subprogram
> types make sense, as a starting point you would have to make
> subprograms be first-class objects (not just a new kind of parameter),
> and that would be a much different language than Ada.

If I correctly understand your concern, the problem is to find a
suitable reason to make:

X : A_Subprogram_Type;

illegal (without any reference to the fact that A_Subprogram_Type is
a subprogram type). Well, we could make subprogram types unconstrained.

... and what do you think about:

Y : UNIVERSAL_INTEGER;

Subprogram types seems to be very similar to the universal types.

> Well, access-to-subprogram is here to stay in Ada, whether you like it
> theoretically or not :-) :-) :-). "limited access", at least, would be
> a mild extension of what we already have in Ada95.

I am not against "limited access". Especially if it could be applied
to all pointers. We do sometimes need pointers to subprograms. My
wish is to make this necessity as marginal as possible.

> In terms of the machine model, pointer to a subprogram makes sense
> even if subprograms are not objects (and hence not instances of a
> type). Subprograms have an address -- or a descriptor, or something
> that can be used as an aliasing reference.  If they don't, then they
> certainly cannot be passed as a closure!  (For instance, you couldn't
> pass an inline subprogram or an intrinsic subprogram as a closure).

Potentially, I could pass an inline subprogram by copy! (:-)) Actually
this is an argument against pointers (:-)).

--
Regards,
Dmitry Kazakov


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