Re: FAQ and string functions

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

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 
> > "Randy Brukardt" <randy@rrsoftware.com> writes:
> > 
> > > I think your missing the Ada philosophy that something expensive should
> > > look expensive. An unbounded array (as you put it) is going to be
> > > expensive, and that expensive shouldn't be covered up in glossy syntax.
> > 
> > IMHO, that philosophy is exactly the opposite of what high-level
> > languages are all about.  The parts of Ada that disobey this philosophy
> > are the better parts.
> > 
> > Here's an example: In Ada, one can write "A := B;".  If they are
> > integers, it's fast.  If they are gigantic arrays, it could be a million
> > times slower, or more.  That's good -- assignment uses a single notation
> > no matter how fast or slow.  Contrast with C, where copying arrays uses
> > a different syntax from copying ints.
> 
> That's not a fair example. For assignment, the cost is clearly
> proportional to the size of the data, which is easily visible in the
> source.

Not necessarily:

    procedure P(X: String) is
        Y: String_Ptr := new String'(1..X'Length);
    begin
        Y.all := X; -- How fast is this?

The amount of data copied is probably a run-time calculated value (not
"easily visible in the source"), and is different for each call to P.
In fact, one call to P might take a million times longer than another.

But anyway, what do you think is a fair example?  My claim is that the
philosophy Randy mentioned above is *not* a good language-design
philosophy, and that Ada doesn't follow it very much.  The cases where
Ada follows that philosophy tend to be ugly, and the cases where that
philosophy is disobeyed tend to be nice and clean.

In fact, the only languages that truly obey the philosophy are assembly
languages.  To get the benefits of a high level language, I claim that
you must give up the obvious correspondence between source code and
efficiency that comes with low level languages.

> Hidden memory allocation is not clearly visible (because it's hidden
> :), but is expensive.

I think the issue of memory allocation is not efficiency, but
predictability of efficiency -- heap allocation/deallocation tends to be
less predictable than stack allocation/deallocation.  So it does make
sense to avoid hidden memory allocation in a language for real-time
systems.

> A more valid example of hidden expense for assignment is a Controlled
> type; Finalize and Adjust could be expensive. But even there, the
> definition of the type clearly says "Controlled", so you are warned
> that it might be expensive.

I suppose, although you have to look into private parts to find that
information, and at all the component types.  And you have to know how
your compiler does it -- compilers differ wildly in the cost of
finalization.  That's unfortunate, but I don't see how to avoid that
problem in a high-level language.

- Bob