Re: Flexible Strings (was Equality operator...)

[mheaney@ni.net (Matthew Heaney)]

In article <9704301422.AA07755@most>, "W. Wesley Groleau (Wes)"
<wwgrol@PSESERV3.FW.HAC.COM> wrote:

>I never had a problem implementing an Ada-83 equivalent of bounded strings
>so that no heap was required.  Did it pretty much as Matt Heaney suggested,
>after reviewing a couple of "free" dynamic_strings packages and finding
>that nearly every operation leaked heap.

Many people don't realize that Ada was more or less designed to that you
don't have to use heap.

The problem with Ada 83 is that when you do need it, memory leaks are bound
to happen, because clients often forget to clean up the data structure. 
Thankfully, this has been corrected in Ada 95.

And just to remind everyone, an access type (or even an array type) is a
low-level primitive.  Clients of a (high-level) abstraction shouldn't have
to manipulate access objects directly - use access types to implement an
(unbounded) abstraction.  Pointers are strictly an implementation feature
of the language, for use by the programmer to craft higher-level
abstractions.

>The one thing I really missed, however, is still not available in Ada 95:
>assigning string literals to these things.  I think that using unary "+"
>is a C-like solution (i.e., sacrificing "intuitive" readability to save
>keystrokes).  Defining a function that looked like a type conversion was
>better for the READER, but since you can't use the actual type name,
>it posed a memory inconvenience on the writer.

I often think that automatic type conversions such as are available in C++
would be useful.  You're right, it seems that

declare
   S : String_Buffer := "initial value of S";
begin
...

would be OK.  But I don't know.  Norm Cohen had a post once about how
difficult it is to reason about the correctness of software where automatic
conversions were taking place.  The bad thing is that what is happening at
run-time isn't obvious from reading the code, because conversion routines
are being invoked automatically.

Not being able to understand what's happening at run-time by reading the
static source text is what originally prompted Dijkstra to admonish against
the use of the goto.  It seems that Microsoft's Hungarian notation is a
desperate attempt to maintain intellectual control of when automatic
conversions are happening in C.

Where do you draw the line about syntactic difficultness vs semantic
correctness:

Automatic_Conversion:
declare
   SA : constant String_Buffer_Array := ("I'd", "gladly", "lose", "me",
"to", "find", "you");
begin

Explicit_Conversion:
declare
   SA : constant String_Buffer_Array :=  (
      To_String_Buffer ("I'd"), 
      To_String_Buffer ("gladly"), 
      To_String_Buffer ("lose"),
      To_String_Buffer ("me"),
      To_String_Buffer ("to"),
      To_String_Buffer ("find"),
      To_String_Buffer ("you"));
begin

A_Happy_Medium:
declare
   SA : constant String_Buffer_Array := (+"I'd", +"gladly", +"lose", +"me",
+"to", +"find", +"you")
begin

Yes, explicit conversion makes it obvious that conversion is happening, but
you tend to lost the forest through the trees with the middle approach
above.

I got the "+" idea from Barnes' book.  Don't think of it as a hack; think
of it as what it is: the identity operator.  It's a happy medium between
the 2 extremes.

There's probably a comprimise in there somewhere.  Everyone is still
realing from the heights of automatic conversions in Algol 68 - that vastly
complicated the language - and Ada 83's staticness was an (over)reaction to
that.  Things have been loosened up a bit in Ada 95, but there's probably
room for more loosening.  But how far do you go with syntactic ease before
you comprimise semantic characteristics?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271