Re: Composing tasks and protected objects

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

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

> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> news:87oe88bvse.fsf@mid.deneb.enyo.de...
> ....
> > This introduces overhead in terms of an additional task, and the
> > Forwarder and Server are strongly coupled (unless you manually write
> > wrappers, because access-to-entry types are missing).
> 
> Yes, but an implementation of the proposed feature probably would have to
> introduce that task anyway.

Are we still talking about multi-way calls?  I certainly don't believe
that their implementation requires the implicit introduction of hidden
tasks, or anything near that cost!

>... It would end up costing about the same, yet it
> would look cheap. That's generally bad language design.

Well, I disagree about the cost, but I also disagree with that language
design principle -- the principle that says inefficient things should
*look* inefficient in the source code.  That principle is exactly the
*opposite* of what high level languages ought to be about.

In most cases, Ada does *not* follow that principle, and that's a Good
Thing.  In the few cases where Ada does follow it, it's a Bad Thing.

Consider:

    X := Y;

If the type is Integer, it takes approximately 1 machine instruction.
If the type is array-of-a-million-integers, it takes millions of
instructions.  If the type is controlled, it invokes Adjust, which could
do all kinds of user-defined task locking and heap management.

We don't use a different syntax for fast and slow assignments!
Surely that's good.  (Contrast with C, where the array case uses
"memcpy" instead of "=", and the Adjust case requires calling Adjust
explicitly.)

Another example: array indexing uses the same syntax whether the thing
is bit-packed or not.  Contrast with C, where the bit-packed case
requires explicit shifting and masking.  The extra cost of bit-packed
array indexing is more apparent from the source code in C, which is
certainly an advantage, but it's outweighed by the loss in abstraction.
For example, in Ada, you can easily experiment to determine whether bit
packing is an efficiency win.

An example where Ada *does* follow this misguided principle: unbounded
strings are a huge pain to use in Ada.  It would be much nicer if they
supported array-indexing syntax, slicing, literals, etc.  That would
hide the inefficiency of these strings.

I say, if you want to see efficiency properties clearly in the source
code, you must program in assembly.  In higher level languages, you lose
that capability.  You must determine efficiency by measurement, and by
experience (knowing which features are efficient in typical
implementations).

- Bob