Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...)

["Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>]

Robert I. Eachus wrote:

> > ... Establishing the idea of a Universal String might not be a bad
> > idea..... Although in reality once if we just really standardize on "+" doing
> > a conversion and being in the standard I think the extra syntax overhead is
> > pretty minimal.
>
>All I can say is this is language parochialism at its worst.  Not Ada
>parochialism, but ASCII parochialism.

It does not seem a proper attribution. In the issues like that, when you insist
on totally equal status, you are actually promoting not diversity, but entropy.
(It seems also that you have mostly remote view on other "parishes", and not
enough information about real-life problems with national encodings in those
other "parishes".)

>  In Ada, ASCII and Latin-1 have no
> particular magic status.  If you want to have a character type Cyrillic
> and a Cyrillic_String, Greek and Greek_String, or for that matter
> Japanese_Character and Japanese_String go right ahead.

I can't get how it is related to the issue of relation between Strings and
Unbounded_Strings, and to the implicit conversions between them. Those implicit
conversions should not change actual memory contents in any way, and they are
completely unrelated to any encodings.

BTW, when you mentioned Cyrillic_String you made me smiling grimly. Do you
know that there are 3 alive Cyrillic encodings? Do you know that, for example,
in Windows, the final effect of your Cyrillic encoding depends not only upon
encoding, but upon Regional Settings also? And there are plenty of more subtle
issues, which may easily hurt you when you deal with a Cyrillic encoding. So,
don't fancy that your Cyrillic_String will be of much help, especially if you
want to develop a robust product for actual field use.

> If you look in the Ada Reference Manual at sections 3.5.2 Character
> Types and 3.6.3 String Types, you would know all this.

I looked there, and I reread what said Cohen's book about all that stuff -
character sets, maps, and translation - and found nothing relevant to the
issue of implicit conversion between Strings and Unbounded_Strings.

> Now do you understand why you need for the conversions from String to
> Unbounded_String to be explicit?

No, I haven't even a slightest idea.

>  There could be mappings involved,

How they can be involved? From all I can see, there are no implicit mappings
(that is, implicit calls of Translate subroutine) in Ada 95 standard.

> and you definitely don't want two implicit conversions, because the
>intermediate type could be just about anything.

That could be bad indeed if the mappings were involved, but they don't.

I think that at this stage I should show my sketch proposition (which I sent
to Ada-Comment about a year ago). Here it is:

---------------------------------------------------------------------------

Generalizing the Strings/Unbounded_Strings issue, I would propose a new notion
of "enveloped" private type. That is, a private type Y may be declared as an
envelope (new keyword) of some base type X:

  type Y is private envelope of X;

Enveloping type (Y above) is required to have 2 private primitive operations:

  function Strip (Source : Y) return X;

and

  function Upgrade (Source : X) return Y;

which must be exact inverse of each other:

  Strip( Upgrade(V) ) = V  and Upgrade( Strip(W) ) = W

and their implementation is severely restricted so that compiler can verify
and guarantee these identities.

Then, a variable of enveloped type may be immediately initialized with a value
of enveloping type and vice versa, in all cases of initialization, which include:

1) declaration with initialization

   V : X := R;  -- where R is either a variable or constant of type Y
                -- or a function returning result of type Y

   W : Y := S;  -- where S is either a variable or constant of type X
                -- or a function returning result of type X

2) argument for "in" parameter of a subroutine call

   function F(A : in X; B : in Y)
   ...
   procedure P(A: in X; B : in Y)
   ...
   V : X;
   W : Y;
   ...
   ... := F(W, V);
   P(W, V);

3) argument for "out" parameter of a procedure call

   procedure P1(U : out X)
   ...
   procedure P2(U : in out X)
   ...
   W : Y;
   ...
   P1(W);
   P2(W);

In all these cases a compiler provides implicit conversions between types X
and Y using private operations Strip and Upgrade of Y.

Further, there may be several different envelopes for the same base type:

  type Y is private envelope of X;
  type Z is private envelope of X;

and one of those envelopes may be immediately used for an initialization of a
variable or parameter of another envelope type (as in the previous case above).
For example:

  procedure P(W : out Y)
  ...
  T : Z;
  ...
  P(T);

The compiler provides implicit conversions between types Y and Z using
compositions Z.Upgrade(Y.Strip(...)) and Y.Upgrade(Z.Strip(...)) .

I believe that the notion of enveloped type may be considered (to some extent)
as opposite to the notion of subtype.

---------------------------------------------------------------------------

As I said recently, I can't work out this proposition to a precise and complete
form - I'm not a language laywer. But I don't see why it may be fundamentally
wrong, and still nobody said me that.

Some today's comments for that 1-year-old text:

1) subroutine names "Strip" and "Upgrade" should be seen as "denonations",
and To_X, To_Y (To_String and To_Unbounded_String in the case of Strings)
may be actually used instead.

2) although this proposition is about implicit conversions, the latter are
essentially identities, and what is most important, they are applicable for
explicitly related types only.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia