Re: Access to strings and string subtypes?

[Tucker Taft <stt@averstar.com>]

Robert Dewar wrote:
> 
> In article <wcczorx1tkq.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> 
> > I don't think it was purely an efficiency issue.
> 
> I really think you are wrong here. I remember these discussions
> very well, since I was opposed to this kludge.
> 
> > I think we were
> > concerned that existing Ada 83 implementations were already
> > doing that optimization, and would have difficulty changing
> > the way they represent arrays.
> 
> If anyone was concerned about this, they never voiced this
> concern at any meeting I was at. Perhaps I have forgotten,
> but my memory was that this PURELY an efficiency concern.
> 
> Really I can't imagine any Ada 83 compiler making this
> distinction (the ones that I am familiar with certainly
> did not). You should at least be able to come up with one
> example to back up your conjecture :-)

The problem was not so much with the objects as it was with
the access values.  For many compilers, access-to-unconstrained
expects the object to have dope contiguous with the object,
whereas with access-to-constrained, there is no dope associated
with the object.  If the same type of access value could point
to either, then both would require contiguous dope.  This is
not much of a hardship for stand-alone objects.  However, for
record or array components, adding dope as a side effect of
adding the word "aliased" to the component seemed undesirable at the
time (at least to some of us).  So it was a space efficiency
issue primarily.  In retrospect, I guess having "aliased" cause
the addition of contiguous dope might have been the better approach,
but as usual, hindsight is 20-20 (or wears rose-colored glasses,
or something like that ;-).

These concerns all presume the "thin pointer" representation 
for access-to-unconstrained types.  For the "fat pointer" representation, 
where there is a separate pointer to the dope, this problem disappears.  
But of course that interacts in tricky ways with 
access-to-deferred-incomplete, etc.

> Part of the reason I remember is that there were VERY few cases
> where we compromised the language for the benefit of existing
> implementations in very specific terms (we did have some general
> concerns about scope of change).

As indicated above, it wasn't so much about difficulty of implementation,
as about space overhead.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA