Re: Any research putting c above ada?

["John G. Volan" <johnvolan@sprintmail.com>]

Kevin Cline wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> wrote:

[referring to a "mutable" discriminated record with default constraint
on the discriminant]

> >Bottom line, if you declare one of these beasts in the ordinary way,
> >your Ada compiler can certainly allocate it on the stack, and pass it
> >back and forth on the stack.
> 
> Of course, that's trivial to do, and extremely impractical if the object is
> usually small but can occassionally be very large.   Remember the original
> problem that started this thread?  

Actually, no, sorry, jumped in late...

> The poster claimed that it was easy to
> write a program that read a file into an array of lines since Ada allowed
> arrays of size determined at run-time to be returned as function values.
> The I pointed out that:
> 
> 1. Most files do not begin with a line count.  That's certainly a ridiculous
> requirement for manually prepared input.
> 
> 2. Returning such an object is very inefficient because most compilers copy
> the entire object.
> 
> Now you tell me that variable-length arrays can easily be handled in Ada
> without dynamic storage allocation.  But then you indicate that the arrays are
> not truly variable in size, but are restricted to a compiled-in maximum size.

More precisely, they are, in fact, "variable" in size, but "bounded".  I
see now that you're looking for a solution that is "unbounded".  The
only alternatives are:

(1) Use an "indefinite" type and return and instance on the stack (but
this might involve extra copying):

   (a) The "indefinite" type could be an unconstrained array type, with
the bounds on the actual instance not determined until runtime.

   (b) The "indefinite" type could be a discriminated record type
(_without_ a default constraint), with the discriminant constraint on
the instance not determined until runtime.

(2) Develop an "unbounded" abstract data type (which, as you rightly
assert, must entail using some kind of storage pool, perhaps the global
"heap", perhaps some programmer-defined pool).

> That's fine for embedded applications where the amount of data to be handled
> is carefully defined ahead of time.  It's useless for desk-top applications,
> where the size of the data to be handled, and the physical resources available
> to handle it vary widely from user to user.  For those applications, you must
> resort to truly dynamic data structures, and Ada's arrays are of little use.

Of course, but what were you expecting? The semantic level of Ada95 is
comparable to that of C++, and neither language was designed to include
the kind of unbounded ADTs you're looking for -- at least, not as
built-in features of the language.  Rather, these languages provide the
raw materials from which such ADTs might be constructed.  A standard
library might contain such examples as Ada.Strings.Unbounded in Ada95
and the STL in C++, but these components are _written in_ the given
language, not _built into_ the language (i.e., implemented with compiler
support).

(Even in a language like Smalltalk, which routinely comes with unbounded
ADTs such as sets, bags, ordered collections, and the like, these ADTs
are not "built-in" any more than they are in Ada95 or C++. At least, not
in the sense that a Smalltalk compiler knows anything about them. 
Rather, they're part of the standard class library, and are written _in_
Smalltalk.)

> This is one of the biggest blind spots I observed in experienced Ada
> programmers in a shop a few years ago.  Ada programmers tend to use arrays
> instead of more dynamic data structures, resulting in inefficient and
> inflexible applications.  

This observation is not necessarily universal of all Ada programmers.

> OTOH, I have observed that the availability of the
> C++ STL containers is already expanding the toolkit of average C++ developers.

There's nothing about the STL containers that couldn't be done in Ada95
-- probably much more simply, and thus, IMHO, better. (I myself have
re-engineered the RBTree/Set/Map structures in Ada95 for my own
purposes, it really wasn't very hard to get the basic functionality.) 
The advantange of the STL in C++ is that someone has gone to the trouble
of working it up as a "standard" toolkit, and the general C++ user
community is accepting it as such.  It would be nice of someone could
produce a comparable library of such tools in Ada95 and make them widely
available.  There's no technical obstacle to this, only an
economic/cultural one: i.e., we need to get someone to actually do the
work, and the Ada95 community needs to recognize the result as some kind
of "standard,"  official or otherwise.
 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------