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

[mark_lundquist@my-deja.com]

In article <93q393$opo$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <93npfn$13d$1@nnrp1.deja.com>,
>   mark_lundquist@my-deja.com wrote:
> > 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:
> >
> > > 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?
>
> Yep
>
> > 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),
>
> Well, something like
>
>    Foo : constant Action :=
>       declare
>          ...
>       begin
>          ...
>       end Action; -- or end Foo; ?
>
> looks a bit indigestibe.

A lot indigestible.

> Something in the package instantiation / type
> extension style:
>
>    procedure Foo is new Action with
>       ...
>    begin
>       ...
>    end Foo;
>
> seems also clumsy.

No, what I had in mind was a contract model with matching rules, e.g.

   procedure Foo (X: Something);

would match a formal of type Action in 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.
>
> Such kind of argumentation seems to be valid against T'Class too.

Kind of, but not really :-).  Objects of T'Class really are _objects_,
even if you can't declare an object to be of type T'Class.  Classwide
types are formally defined to be indefinite, as are unconstrained
types.  So you can't declare an object of type T'Class, for the same
reason that you cannot declare an object of type String.  That doesn't
make String any less of a real object type.

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.

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.

I guess you could make the same argument for the concept of "pointer",
but I think empirically Ada95 shows that there's enough wiggle-room in
the idea of "pointer" to accommodate access-to-subpgrogram types.

>
> > 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.
>
> The idea is interesting but, IMO, it is generally inconsistent to have
> pointers and have no types they point to.

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'm suprised you
object to "pointer denoting something other than an object" (which, I
repeat, we already have) more than you object to "type describing
something other than an object".  And access-to-subprogram types are
useful for more than just passing as parameters (precisely because they
are real object types).

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

Cheers,
Mark


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