Re: 'Protected' abstract subprograms

[Robert A Duff <bobduff@shell01.TheWorld.com>]

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

> Of course, I know this, but I don't really think that this is relevant. You 
> ("you" meaning Ada 9x team here since I don't know for sure who did what) 

I did most of the work on chapter 13.  I did the initial work on
freezing rules, and I think I'm responsible for the term "freezing".
We modified them over and over, trying to fix bugs, and trying to
clarify.  At some point, I got frustrated, and told Tucker I'm
sick of those rules, you (Tucker) please work on them, and I'll
finish up chapter 3 (which Tucker had been working on at the time).
So Tucker is responsible for the final wording of the freezing
rules in Ada 95.

> could have changed the language more (since you guys had already decided to 
> change the wording drastically), but you didn't. I would say that was mainly 
> because it wasn't really possible to change the language further without 
> changing it's philosphosy.

Not philosophy, so much as compatibility.

>...After all, you did make a number of cases illegal 
> that were legal in Ada 83.

Yes, but pretty obscure cases.  I don't remember the details, and I'm
too lazy to look them up, but I recall cases in Ada 83 where ARG had
ruled "X is legal" for some feature X.  But if you do X it's guaranteed
to raise an exception during elaboration (so for a library package, the
program is guaranteed to fail every time).  Also, in order to generate
correct code for X, the compiler has to KNOW that it's going to raise an
exception; otherwise it would generate code that would follow dangling
pointers and the like.

Clearly, making such an X illegal is an acceptable incompatibility.

> Right. Aspect clauses eliminate quite a bit of the need for freezing rules. 

Yeah, too bad they weren't invented in the late 1970's, in time for Ada 83.

> (Although we ended up using them to describe the semantics of aspect 
> clauses, that was mainly historical in nature -- it would have been better 
> to wait until the end of the unit for those determinations, but that would 
> have not allowed various things legal in Ada.)
>
> I believe your point that a purely compile-time description would eliminate 
> freezing. I'm not convinced that such a restriction would really be 
> usable -- I suppose it depends on what could actually be described that way. 

I'm convinced.  ;-)  In fact, my language design allows some useful things
that Ada does not.  For example, in Ada:

    package Sequences is
        type Sequence is private;
        function Make_Sequence(Length: Natural) return Sequence;
        Empty_Sequence : constant := Make_Sequence(Length => 0); -- Wrong!
        ...
    private
        ...
    end Sequences;

That won't work, and it's annoying.  In my language, it works fine,
because Make_Sequence is called during elaboration of the BODY of Sequences.

But that's not Ada, and it's not even possible to compatibly change
Ada in this way, so I should stop talking about off-topic stuff.  ;-)

> (Personally, I find Ada interfaces useless; I much prefer package 
> specifications for abstraction. I'm not sure if that carries over to your 
> idea.)
> 
> Anyway, not particularly relevant for Ada, since we're surely not reducing 
> what is allowed in a package specification.

In any case, you're right that SOME sort of rules are needed.  You need
to prevent circular things like X is of type T, and the Size of T
depends on the value of X.  I just don't think it needs to be
anywhere near as complicated as the freezing rules.

- Bob