Re: Subverting 'Access for Sub-programs

[Robert Dewar <robert_dewar@my-deja.com>]

In article <37B1A8B5.219C9FE6@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> I understood the point about not worrying about "display"
> difficulties for *checked* language mechanisms.  But for
> something called "Unchecked_Access" I have always presumed
> this is a mechanism that does the "obvious" thing, but just
> doesn't perform any legality checks.

Well it is clear that Unchecked_Access has to have clean clear
semantics, as it does for variables. Who knows what this means
in an implementation. For example, it is easy to imagine that
Unchecked_Access might be very hard to implement and require
lots of extra apparatus in an underlying environment that went
out of its way to ensure safety (e.g. something like a JVM).

> What you are proposing is that the "official" semantics
> for Unchecked_Access impose a requirement that it "work"
> whenever you are *dynamically* within the
> scope of the called routine.  This implies a significant
> amount of mechanism on the part of display-based
> implementations to implement this, as opposed to simply
> eliminating the legality checks at the point of
> 'Unchecked_Access.

Yes indeed, but then I think if you allow general downward
funargs you will need this extra mechanism in any case, and
the proper implementation approach is probably to switch to
static links.

> In other words, *all* access-to-subp values might have
> been produced by 'Unchecked_Access, so *all* calls
> through such values in a display-based implementation
> must take that into account.  By adding 'Unchecked_Access, you
> would be imposing a distributed overhead on all uses of
> access-to-subp values, even if there is no 'Unchecked_Access
> in the whole program, in the display-based implementation.
> *That* is why I wouldn't want to call
> this feature simply "Unchecked_Access."

Once again, I am simply putting this proposal on the table I
don't necessarily favor it. If you look back at my previous
messages, I was simply laying out the solution space, not
choosing a point in it!) I definitely agree that if the language
was designed this way, i.e. in the way that gives a natural
flexible, powerful, and efficient behavior if you use static
links, then precisely it would be the case that implementations
would pretty much be forced to use static links.

The issue here is whether you want to continue to cripple the
language (if you think the restrictions on procedure pointers
to be crippling as many do) just to make it easier for old
implementations using what is now a bad choice.

One viewpoint that could be taken is that such limitations were
appropriate early on in Ada 95, to increase the ease of
transition, but now that transition is complete, it is not
unreasonable to consider improvements that would cause some
implementation difficulties in some compilers. After all almost
any extension proposal will be harder for some compilers than
others.
>
> I can see forcing implementors using displays to support a
> more expensive mechanism under "new" circumstances, but I
> can't see dramatically slowing down all uses of existing
> access-to-subp values to support some additional feature.
> That kind of distributed overhead of a feature is quite
> unpleasant, especially as part of a language revision.  We
> made major efforts during the Ada 9X process to minimize new
> features that imposed distributed overhead on old features.

We are not talking about that here, we are talking about the
limited case of old compilers not adapting to the more
appropriate implementation strategy.

The language should in abstract be designed so that there
exists (at least one) efficient implementation strategy.
That's quite a reasonable framework.

In the case of the display issue, we went further, and decided
to accomodate what, in the context of our language design
effort, was very definitely a bad choice of implementation
strategies.

The question is whether you want to insist on this much more
limited approach for ever.

There are many other places in the language where changes in
Ada 95 made things MUCH harder for some implementations (e.g.
making sharing of generics much harder).

> If we want an access-to-subp value that works any time you are
> still within the "dynamic" scope of a subprogram, I believe we
> should
> make it a different kind of access type.  Perhaps
>    type T is access all procedure ...
>                     ^^^
> or some kind of pragma Unrestricted, or something.  Even with
> the static link approach, supporting Unchecked_Access on
> access-to-subp
> values requires doubling the size of all "top-level"
> access-to-subp
> values, or using some sort of "trampoline" trick.  Creating a
> trampoline that has the right lifetime is a fair amount of
> work
> as well, since the place of the 'Unchecked_Access is a bit
> late.
> I realize that GNAT has solved this, but I believe it takes
> significant advantage of work already performed as part of the
> GCC
> nested procedure support.  And all this makes the
> 'Unchecked_Access
> a significantly more "heavyweight" feature than is implied by
> the name.  It is far from being simply the moral equivalent of
> an unchecked-conversion.

I must say I really dislike the idea of procedure pointers being
a different length at the top level and nested levels, sounds
like a really nasty non-uniformity, so I would definitely avoid
that.

Note that the unchecked in unchecked_access to me is about
lack of checks at run time, and indeed no checks are required
at run time.

As I noted earlier, I can easily imagine environments in which
unchecked_access imposes a distributed overhead on all uses
of access values!

Really what we need to do at this stage is to try to get some
idea of what the Ada user community wants. GNAT users are not
the best source of help here, since the problem is already
completely solved in GNAT (although of course not in a portable
manner!)

For users of other compilers, how much of a restriction is it
to have access-to-procedure have the limitations of the current
Ada 95 design, that is the question.

I certainly know, as I have previously noted, that we make
extensive use of Unrestricted_Access in the GNAT runtime (there
are well over 100 instances in gnatlib). This is certainly not
typical. First, a lot of it is low level system type code,
second, you tend to use features that are available if it is
the easiest way of doing things, and it does not always mean
that you couldn't manage OK without them :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.