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:wcctxknt2r7.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>> 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.

It's unclear to me that inlining makes enough difference for the 
implementation earthquake that it would have represented in Janus/Ada 
(several man-years of work). Since Janus/Ada compiles statements directly 
from their syntax, the largest program structure that it can store is an 
expression tree (and that was a later change, necessitated by the 
requirements of Ada resolution - the original design was purely 
syntax-driven). That would allow inlining of expression functions (and 
functions that are similar to expression functions), but little larger. (One 
could imagine converting if statements into if expressions to allow a bit 
more 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.

Doing this at bind-time allows inlining stuff that neither the user nor the 
compiler really know might be inlined, and it also allows partial evaluation 
of calls based on what is actually present in the program (think about the 
second parameter to New_Line -- it's hardly ever used; code shared generics 
have a similar parameter for sharing information, of course). (It also 
allows other cross-procedural optimizations.)

Final code generation obviously has to occur after those optimizations, so 
it would always be done at bind-time in that scenario. So there wouldn't be 
any incremental cost to inlining (other than the cost of actually doing it). 
This wasn't a practical implementation in 1995 (which is why we didn't do it 
then), but it was always the intended end-game for Janus/Ada. (That code 
generation can be parallelized, and much of the cost of binding disappears 
if the code generation is delayed, so on a modern multi-core I wouldn't 
expect the binding time to grow that much.)

Anyway, if I spent less time writing about this implementation and more time 
creating it, we could see how well it works. ;-)

                                       Randy.