Re: Ada.Strings.Bounded

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

Eric Hughes <eric.eh9@gmail.com> writes:

> On Apr 12, 3:09 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> So a comparable case would be Integer vs. BigNum. The latter
>> (arbitrary-precision arithmetic) plays same role for integers as
>> Unbounded_String does for strings.

The analogy is not perfect.  You can create arbitrarily large strings
(within the limits of available memory, and the bounds of Integer,
which is pretty big).  It's just that any particular string object
cannot change length.  Integers are much more restricted -- you can't
create an integer bigger than some implementation-defined limit,
such as 32 or 64 bits.

>...Now, if ARM had BigNum defined, we would
>> experience exactly same problems with both, as we have with Strings and
>> Unbounded_String.
>
> Well, yes; that's a good second example, although let's call it
> Unbounded_Integer.  The mechanisms are identical for dealing with
> universal_string/String/Unbounded_String and univeral_integer/Integer/
> Unbounded_Integer.  In the first case we have (0=absent,1=present)
> 0/1/1 and in the second we have 1/1/0.  In the first case we have
> endless type conversions to do ordinary work.  In the second we have
> an absence in the standard.

It's particularly annoying that Ada doesn't allow bignums,
because every Ada implementation must support a bignum package
-- compile-time arithmetic (static expressions) require it.
So every Ada implementer has to go to all that trouble,
but can't provide that functionality to users at run time -- at
least, not in a standard way.

> On Sat, 12 Apr 2008 11:50:56 -0700 (PDT), Eric Hughes wrote:
>> I believe many of the issues involving strings could be addressed by
>> introducing a predefined type universal_string.
>
> On Apr 12, 3:09 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> I don't see it this way.
>
> I have a strong counterclaim--I don't think it can be solved without
> introducing such a type.

> Here's the real rub: universal_integer and universal_string are each
> _unimplementable_ as executable types.  As abstract mathematical
> types, they're perfectly well-defined.  The origin of the difference
> is that universal types have no possible bound in size.  Since every
> computer type has such a bound, there's a fundamental disjunct between
> these two.  An unbounded type actually does have a bound--it throws an
> exception when its internal bounds are exceeded.  A hypothetical
> implementation of a universal type would be unable *in principle* to
> throw such an exception.  This is clearly contrary to fact, where
> every program can run out of memory.

Well, the limits on bignums are fundamentally different from the limits
on Ada's integer types.  In a language with bignums, the _language_
places no limit on the size of integers.  An implementation can
of course run out of memory, but that's not a limit on the size
of any particular integer type, and the "limit" depends not only
on how much memory you have, but also on how much you're using for
something else.

Unbounded strings would be similar, if they were indexed by bignums.

> If this sounds like my idea for partial type specification (one
> without code), it should.  These ideas come from the same perspective.
>
> There's no concept (except _ad hoc_ in the ARM) of what a universal,
> unimplementable type is; there's certainly no way of declaring one.
> So here's the very beginning of a proposal.  To declare and define
> such a type:
>
>     universal_type_definition ::= *universal* *type*
> defining_identifier [known_discriminant_part] *;*

I don't quite understand all this stuff about user-defined
universal types (you give syntax, but didn't fully explain
the semantics).  But anyway, you seem to be inventing something
like abstract types, and/or class-wide types.

Note that universal_integer is conceptually the same thing
as root_integer'Class.  The RM doesn't say that, but the
language designers had that analogy in mind.

>    universal type U ;
>    function op( U Object ) return U ;
>    type T1 is private and U ;
>    type T2 is private and U ;
>    overriding function op( T1 Object ) return T1 ;
>    overriding function op( T2 Object ) return T2 ;
>    function U( T2 Object ) return T1 ;
>    T2 x ;
>    T1 y1 := T1.op( U( x ) ) ;
>    T1 y2 := U( T2.op( x ) ) ;
>    T1 y := x.op ;

The above is an odd mixture of C-like syntax and Ada-like syntax.
Surely "is private and U" should be "is new U with private".
And "T2 x;" should be "X: T2;"

> The expressions for y1 and y2 should be interchangeable as
> implementations for the expression for y.  The point of the
> declarations is to give unambiguous semantics to the expression
> "x.op", so that it does not matter to the correctness of the program
> what implementation expression the compiler chooses.  If Usenet had
> better formatting, I'd draw a commutative diagram as an illustration.

I don't see any semantics, unambiguous or otherwise, in the above.
Sorry -- I just can't guess what it means.

> There's special meaning behind the conversion function U.  Its
> mandatory semantics is to convert an object of T2 to one of T1, such
> that their values are equal as universal values.

I don't know what "equal as universal values" means, either.

Anyway, the problem with Unbounded_Strings, as I see it,
is that Ada doesn't allow user-defined types to use all
the same notations as the built-in ones.  Literals,
indexing, etc.

- Bob