Re: [announcement] SYSAPI and SYSSVC for Windows

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Robert A Duff wrote:
>> 
>> > We should, instead, have allowed the "aliased" keyword on parameters.
>> 
>> No, I think that "aliased" should better be used as a type qualifier:
>> 
>> type X is aliased tagged ...; -- This is a by-reference type
>> type X is tagged ...; -- The compiler is free to choose
>>                       -- (with all the consequences)
> 
> We're not (just) talking about whether parameters are passed by
> reference.  We're (also) talking about whether regular variables are
> aliased.  It seems to me somewhat dangerous, and deserving of a special
> mark on the variable declaration.  (It wasn't allowed at all in Ada 83.)

Yes of course. There should be a choice: either to make all objects aliased
by declaring the whole type aliased (so by-reference), or to allow the
compiler to choose, but also to have an ability to apply "aliased" to an
object or to a subtype:

declare
   subtype Aliased_Integer is aliased Integer;
   X : Aliased_Integer; -- Same as aliased Integer

To have "aliased" in the parameter profile, would mean an anonymous aliased
subtype. This is OK, but then we should probably to make the consequent
steps allowing anonymous subtypes of all sorts:

procedure Get_Line (Line : in out String (1..Get_Line_Width));

That could be poblematic.

>> For parameters there are access types. IMO it is a bad idea to get
>> pointers to parameters, if that is really needed one should pass a
>> pointer instead.
> 
> I think I agree with that, but then you trip over another design mistake
> -- there's no such thing as an "access constant" parameter.

Yes.

>> A good example is Finalize. There is a nasty problem to get a pointer to
>> the parameter of Finalize, because there is no way to figure out which
>> pool it should be. For by-reference types it should be sort of:
>> 
>> procedure Finalize (Object : access not all Object_Type); -- (:-))
> 
> I'm not sure what you mean.  How does this tell you what pool Object is
> in (maybe none!)?

That was a joke! Though seriosly, there should be some way to work with pool
objects. Presently, pool is decoupled from the object type. It makes sense,
but quite often one wishes to allocate controlled objects in a specific
pool. Maybe we should allow:

type Object_Type is
   new Ada.Finalization.Limited_Pool_Specific with private;
for Object_Type'Storage use Pool;
type Ptr is access Object_Type;
   -- Implies for Ptr'Storage_Pool use Pool;

A : Object_Type; -- Compile error

procedure Foo (A : access Object_Type); -- A is specific to Pool
procedure Finalize (Object : access Object_Type);

With MD we could make Finalize dispatching on both Object and Pool:

procedure Finalize
(  Object : access Object_Type; -- Object is specific to Pool
   Pool   : in out Root_Storage_Pool
);

But this would require too much work.

>> Then I would disallow overloading like this:
>> 
>> procedure Foo (Object : access Object_Type);
>> procedure Foo (Object : in out Object_Type);
>> 
>> Instead of this I would make access types transparent to primitive
>> operations, as they are to array indexing and record member extraction.
> 
> We proposed something like that (implicit .all) in the early stages of
> the Ada 9X project.
> 
> I actually don't like implicit dereference at all, even for selected
> components.  But the problem is that .all is so verbose and ugly, it
> *needs* to be implicit.  If it were up to me, the syntax for dereference
> would be Pointer^ (from Pascal), which is unobtrusive, but still makes
> the dereference explicit.  Following a pointer and selecting a record
> component is semantically much different from just selecting a record
> component -- the syntax should convey that.

I see it completely different. To me an access type should be just a subtype
of the target type, so it would inherit all operations of the "base". To do
it I would allow user-defined subtypes privately implemented in this case
by a hard-wired access type:

   type Object is ...;
   subtype Handle is private Object;
private
   type Handle is access Object;

This would mean that all operations would be transparent, what one indeed
expects from a handle. With appopriate constructors and destructors it
could be made dangling-pointer safe. It would probably make 'Access
attribute and anonymous access types superfluos in most cases. Though there
would definitely be a problem with recursive types to solve.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de