Re: Access types as parameters

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
> news:uprb1epp8.fsf@stephe-leake.org...
>
>> To be convincing, I'd have to post an example from Gtk or OpenToken
>> written both ways; maybe later I'll find time for that.
>
> Yeah, I know that we are both talking rather hypothetically, and we may have 
> rather different examples in mind.

I've now written a small example of the two styles; see
http://www.stephe-leake.org/ada/access_vs_object.html

The problem domain of this example is grammars; the goal of the
application is to allow the user to build a data structure that
represents a grammar, so the application can then use that structure
to parse input strings.

Typical grammars have recursion in them. This requires pointers of
some form in the data structure. The access_style package tree in this
example uses explicit access types as the pointers, and access
parameters in the relevant grammar constructing functions. The
object_style package tree uses Ada.Containers Cursors as the pointers.

The object style contains a significant kludge; there is a global (but
private, in Object_Style.Pointers spec) List object that holds all the
tokens needed for the grammar. That was the only way I could see to
get a Cursor for each. AI05-0069-1
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0069-1.txt)
defines holder containers that should eliminate this kludge in Ada
201z.

In addition, in Object_Style.Sequence "&" body, we must examine the
tag of the arguments, rather than using dispatching to achieve the
same result. This doesn't happen in the access style, because we can
define two "&" functions with different type profiles; one takes a
token object, the other an access to class-wide.

Finally, some type information is lost with this style. Compare
object_style-run.adb to access_style-run.adb; there are more precise
types in the access style version. In the full OpenToken application,
this becomes even more significant.

There are two main objections to the access style:

1) Users must manage memory
  
2) If users pass in access values with nested accessibility, they will
   get Program_Error at run-time.

The first objection can be mitigated by realizing that there is never
any need (in this application) to deallocate any of the grammar
structures. This could be made explicit with a new pragma
No_Deallocation, applied to the access types.

The second objection can be eliminated by adding preconditions to the
subprograms that take access parameters, as defined by ai05-0145-1 and
ai05-0024-1:

pragma Inherited_Precondition ("&", Left in Access_Style.Token_Access_Type);

A reasonably smart compiler can then report the accessibility errors
at compile time rather than runtime.

A third style would be a modification of the access style; define the
access type storage_size to be zero, so that no allocations (or
deallocations) can be done. This forces the user to define aliased
grammar objects on the stack at library level, and then reference them
in other grammar objects via 'access. That is significantly more
awkward than allowing allocation, but not deallocation.

With the facilities of Ada 201z, I believe using explicit access types
and access parameters is the best fit to the problem domain. Using
container Cursors as the pointers is awkward, loses type information,
and doesn't gain enough to be worth it.

This thread originally started discussing Gtk, which also uses access
parameters. In my (few, small) Gtk applications, I don't deallocate
Gtk widgets; I create them all at the start, and then show and hide
them as appropriate. So I could live with a Gtk that had pragma
No_Deallocations on the access types. Other people might object to
that, though :).

-- 
-- Stephe