Re: Function Calls by Address

[Robert A Duff <bobduff@world.std.com>]

"Robert I. Eachus" <eachus@mitre.org> writes:

>     The point is that, without context clauses on subunits, it is easy
> to syntactically remove all instances of the keyword separate from an
> Ada program.
> However, with the with clauses, not only do you have to do at least as
> much
> semantic analysis as is required to remove use clauses, but there are
> programs where you have to do significant restructuring to provide a
> legal elaboration
> order.  (You may also need to tell the compiler what that order is.) 
> This
> problem is, at a minimum NP hard, and it may in fact be impossible to
> determine
> if such an order exists.

You still haven't answered my question about what your imaginary tool is
supposed to transform the subunits into.  I'm guessing that you mean it
should insert the subunits in place of the stubs, and shuffle the
with_clauses around as necessary.  That is, you are not requiring that
the subunits still be separately compiled (ie transformed into child
units).

I don't understand the elaboration order issue.  The rules are that the
elaboration or is *exactly* as if you move all the with_clauses from the
subunits up to the containing library unit.  So that part is easy.

Of course, if you move with_clauses around, you need to do overload
resolution to figure out how to resolve any naming conflicts you've
introduced.  Yeah, that's kind of hard (but certainly no harder than
writing an Ada compiler).

But I *still* don't see how it proves that with_clauses on subunits are
useful or good.  I'm not disputing that they are useful or good -- I'm
just saying I don't see how the difficulty of this imaginary tool has
anything to do with it.  I mean, it's hard to parse C programs because
of the weird way typedefs work -- but that doesn't prove that the weird
way typedefs work is good.  In Ada, it's hard for the compiler to tell
the difference between "and" as an operator symbol, and "and" as a
normal string literal.  (That is, consider a tool that changed all
user-defined operators and their uses into identifier-named functions --
it would be hard to do in the general case.)  But that fact doesn't
prove there's some useful expressive power there -- in fact, in C++ it's
easy to find operator symbols lexically, and I would say that's one
thing about C++ that's *better* than Ada.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.