Re: Ada202X: Easy to use "UML private"-like components

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 13-06-24 23:20 , Randy Brukardt wrote:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccr4ftko44.fsf@shell01.TheWorld.com...
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>> Maybe my post was unclear: I tried to contradict Bob Duff's recollection
>>> that an opaque type in Modula-2 is more like an Ada private type than
>>> like an "stt access type". I think that a Modula-2 opaque type is very
>>> similar to an "stt access type". Do you agree with me?
>>
>> Yes, given your quotes from Wirth, I agree that Modula-2 opaque types
>> are much like stt access types.

Good (but I don't know if my quote is from Wirth; it was from the web
page I cited).

>> I had remembered the restriction
>> differently:  the type was required to fit in the size of a pointer,
>> which included integers and enums and small records.

That seems likely to create program-portability problems - on a 64-bit
machine, a 64-bit record could be opaque, but it could not be opaque on
a 32-bit machine (unless all pointers are artificially made 64 bits
wide, too).

>> Probably the
>> Modula-2 compiler I used had a nonstandard extension -- or else I am
>> misremembering.
> 
> My recollection matches yours, Bob. Perhaps the rule was changed in later 
> versions of the language.

The Wikipedia entry on Modula-2 refers to several dialects of Modula-2,
of which the "PIM" dialect (from the book "Programming in Modula-2") is one.

The rules for opaque types do seem to vary between dialects; for
example, the site
http://freepages.modula2.org/report4/modula-2.html#SEC43 says: "Opaque
export is restricted to pointers and to subranges of standard types."

> In any case, the Modula-2 obaque type is *not* a 
> pointer type, so in that sense it is much more like an Ada private type than 
> an access type of any sort.

I can agree, if we consider only the user's point of view. Both opaque
types and stt-access-types are declared as private -- the user (client)
does not see their structure or nature.

However, even for the more permissive Modula-2 dialects, for example the
one quoted earlier in this post, I would guess that most cases of opaque
types in practice use pointers, to avoid the size restrictions.

The main difference is that in Ada, the unknown underlying type is named
-- what you call the stt-incomplete type. This type is of course
invisible to the users (clients) of the private type. Off hand, it does
not seem to me that such named-but-incomplete types should cause hard
problems for the compiler, but it appears that you have experienced such
problems. Perhaps they did not exist in Ada 83, but came about because
of other extensions such as controlled types?

> (I.e., I don't buy this analogy, especially as 
> there isn't any such thing as an stt-access-type -- the operative thing is 
> an stt-incomplete-type, which is nothing like a Modula-2 opaque type. The 
> access type is completely normal, its the designated object that's special.)

As I have understood it, the private definition of the stt-access-type
as an access to the stt-incomplete-type is simply an idiom, or trick, to
achieve the same effect as a Modula-2 opaque type, without introducing
the new concept "opaque" into Ada. That it gives a name to the
stt-incomplete-type is perhaps unfortunate, from the compiler-writer's
point of view.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .