Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation))

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.848352010@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Nope, I don't buy that for a moment. By that reasoning, A.3

A(3).

>3   The implementation shall ensure that each language defined subprogram is
>reentrant in the sense that concurrent calls on the same subprogram perform
>as specified, so long as all parameters that could be passed by reference
>denote nonoverlapping objects.
>
>
>would be entirely redundant, since according to you, it is implicit in the
>specs of the routines.

Actually, I think it *is* redundant, and I had a big argument about that
with Tucker.  (I think it should have been a NOTE or an
[bracketed-in-AARM] thing.)  The reason it's there is that some Ada 83
compilers failed to make things like Text_IO work properly.  And because
Tucker wanted it there.

This is like many real-life laws -- legislatures are continually passing
laws that are just special cases of existing laws, because somebody is
griping about a rash of some particular crime.  Legislatures don't
normally sit around thinking of every possible evil, and pass a law
against it.  RM authors, on the other hand, try to do something like
that.  ;-)

>In fact it is perfectly possible to do things with the defined procedures
>that definitely ARE erroneous, for example, surely you dont think that
>two tasks that modify the same string at the same time must work
>correctly. No of course not, that we would expect to be erroneousw.

Agreed.

>"behave as if they are really (varying length) strings"
>is meaningless, either we ignore the parenthetical remark, in which case
>it is nonsense, since these do not behave like Ada strings, or we include
>it, in which case we are talking about something not in the language and
>so are defining varying length string semantics in terms of varying
>length string semantics which is nonsense.

Whenever the RM uses a term that it doesn't define, which is quite
often, you have to take the most reasonable meaning you know from plain
English, or from general computer jargon.  Perhaps I interpret this
section using a "friendly reading".  I'm not going to worry about it
until some compiler vendor tries to get away with making things
erroneous that shouldn't be.

And you still haven't answered my main objection to your reading -- if
you read it that way, then why isn't practically everything in Annex A
erroneous?  And lots of other stuff.  E.g:

    X, Y: Calendar.Time := Clock;
    
    X := Y; -- Erroneous?

(No tasks here.)  How do we know that the implementer has not evilly
made the full type for Time controlled, with an Adjust routine that does
something erroneous?  Or raises GNAT.Evil_Exceptions.Whatever_Error?  Or
writes the value 17 into all integer variables in the program?  We know
that, because the correct way to interpret the RM is that if it doesn't
say any of those bad things happen, then they don't.  The same way we
know that 1+1 of Integers doesn't have side effects.

(Of course I know that two tasks modifying X at the same time would be
erroneous.  That's covered by 9.10.)

- Bob