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

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccmwqhkm22.fsf@shell01.TheWorld.com...
...
> The compilation model is that when compiling something, the compiler
> looks at information coming from the specs of imported things, but not
> their bodies.  Modula-2 compilers actually work that way, and this
> is the reason for the must-be-pointer (or must be the same size as
> a pointer, or smaller, as I had (mis?)remembered it).
>
> It is also the reason for the private part kludge: the compiler sees
> the size of the full type for a private type (assuming it is known
> at compile time).  But this reasoning makes no sense to me, because
> that's not how Ada compilers work.  Any reasonable implementation
> of generics and inlining needs to look at bodies.  So full types
> should be in bodies, and compilers should look there (at least
> in optimizing mode) to find out their size.

Baloney. Maybe *most* Ada compilers work this way, but certainly not all: 
Janus/Ada works exactly like your description of Modula-2 compilers. 
Generics are implemented with universal code sharing in Janus/Ada for 
precisely this reason -- our compiler never looks in a body other than to 
compile it. (We were fanatical about minimizing compilation dependencies, 
because when a single compilation took 2-4 minutes, building anything 
significant took hours.)

Janus/Ada doesn't do inlining at all, other than of things visible in 
specifications (expression functions make a significant expansion of what 
can be inlined -- one of the reasons the idea was invented in the first 
place, many years ago). If it ever does do inlining of subprograms, it would 
do it at bind-time, (and mostly automatically).

I think Ada's allowing of those extra compilation dependencies caused most 
compilers to have insanely long build cycles in the early days of Ada, and 
probably caused a lot of damage to Ada's reputation. As such, this was one 
of the worst decisions of Ada. (I have to agree it doesn't matter so much 
anymore, but no one is building Ada compilers from scratch.)

> On the other hand, the private part kludge wouldn't be so bad if
> the syntax were different:  The private part should be a separate
> syntactic compilation_unit, with its own with clauses, and should
> normally be stored in a separate source file from the visible part.
> There's an awful lot of horrible code duplication caused by the
> fact that the private part is in the same file as the visible part.
> Separating it out into a different file would not prevent the
> compiler from looking at it!

I still think this is a horrible idea; it certainly would be a complete 
earthquake for Janus/Ada, which only knows how to process one source file at 
a time. There would be no way to "look at" such a file when compiling the 
specification, and thus we'd end up having to create a "specification" file 
containing no useful information. It would be a total mess (especially as I 
can't imagine how compilation ordering could be made to work in such a 
scenario).

And this doesn't make any sense when combined with child packages. Once one 
allows visibility into the private part in some other unit (like a child 
unit), it's no longer really separate in any way.

Perhaps this would make sense in some Ada-like language, but not for Ada.

                                     Randy.