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

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

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

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccmwqhkm22.fsf@shell01.TheWorld.com...
> ...
>> 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.

Perhaps I should have said "reasonably efficient implementation".
You can't implement generics efficiently (I'm talking about
run-time efficiency) without doing at least some macro expansion.

>... (We were fanatical about minimizing compilation dependencies, 
> because when a single compilation took 2-4 minutes, building anything 
> significant took hours.)

Yes, no-macro-expansion favors efficiency at compile time.

But you're going against the grain there -- your compiler design should
be dead easy, but it's quite complicated because the semantics are
defined in terms of macro expansion.  (Consider an exception declared in
a generic package body -- each instance must have a different exception.)

> Janus/Ada doesn't do inlining at all, ...

Well, there goes (run-time) efficiency.  Seriously, I don't see how
"don't do inlining" is a reasonable implementation of inlining.

>...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).

"mostly automatically" is good.

But I don't see how bind time (i.e. link time) helps.  It's a reasonable
approach, but it takes just as long to generate code at link time as it
does at compile time, for the same generated code.  If you modify the
procedure body being inlined, you have to regenerate code at all call
sites, either way.

> 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).

I was suggesting that Ada 83 should have been different.  (And in fact,
somebody pointed out that Ichbiah's language LIS was in fact different
in that way!)  If that had been the case, you (and others) would have
designed your compiler differently.  It would not have been rocket
surgery.  (Yes, modifying a compiler after the fact could easily be
rocket surgery.

> 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.

Yes, Tucker made a virtue out of necessity.  Private parts are a kludge.
The fact that child units can see into parent private parts is useful,
but it's not how I would design a language from scratch.

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

Right, an Ada-83-like language.  Today, my suggestion makes no sense.

- Bob