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

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

Robert I. Eachus wrote:

> Have you played the Minesweeper game that comes with Windows in expert
> mode?

Well, I almost never played computer games... there was single exception
about a decade ago, I played SimCity for half an hour. But I developed several
computer games for living, so I am not completely out of contact with that world -;) .
Right now I glanced on this Minesweeper game, trying to catch what you meant.

>  Working with Japanese text is like that when you have to deal
> with encodings.  They have three alphabets, and almost all words can be
> written using more than one.  But the RIGHT one to use often depends on
> context.

I consulted my home linguist on this matter, and she confirmed that there are
exactly 3 alphabets in Japanese: Hiragana, Katakana and a set of hierogliphs.
Then she went in the usage details, but unfortunately she knows nothing about
computer encodings. Anyway, she explicitly rejected the possibility of
context-dependent recognition of Japanese characters in writing or in print.
So, I still don't understand those specific problems your mentioned: do you
mean that not only encodings for these 3 alphabets overlap, but also that no
special "switching" characters are used? It seems highly unlikely to me - I
hardly can believe that Japanese really use some non-trivial context-dependent
encoding scheme instead of simple switching of alphabets (by special characters)
or using non-overlapped encodings for these alphabets. And excuse me, but I
will not believe in that until a native Japanese programmer confirm that...
and explain the reasons, however briefly.
  (Those problems with Japanese encodings that I met in emails were of entirely
another kind, they had no in common with context-dependent encodings.)

> > Oh, it seems that I see (at last!) what you mean: you assume that conversions
> > between encodings should be implicit! But this is far from desirable in real
> > applications!
> >
> > I understand perfectly that there should not be two competing kinds of implicit
> > conversions (one between encodings and another between String and Unbounded_String).
> > So we have to choose between them.
> >
> You assumed that implicit conversions between encodings are more natural and
> more desirable than implicit conversions between String and Unbounded_String.
>
> Agreed, but you miss the problem.  Right now you can implicitly convert
> between string literals and ANY string type.

Do you mean that, for example, an initialization

  S : String := "literal";

includes implicit conversion? That is, a string literal itself belongs to some
type other than String?

And I didn't catch what you mean by "ANY string type" - surely that "ANY"
can't include Unbounded_String type, as in

  U_S : Unbounded_String := "literal"; -- illegal (but I want it to be legal)

>  You want to add implicit
> conversions between String and Unbounded_String, and presumably between
> Wide_String and Wide_Unbounded_String, and so on.

Yes. But I'm ready to accept some restrictions... and the minimum which I want
is implicit conversions from string literals to Unbounded_String and Bounded_String.
Additionally, it will be very good to permit implicit conversions from non-literal
strings to other string types (I mean String to Unbounded_String and vice versa
etc.) in initializations. Regarding full-scale implicit conversions (in assignments
and expressions), I'm not sure... perhaps associated problems overweight the
gains there indeed, and in fact the gains in those cases are more doubtful.

> Now when you go to do explicit conversions between string types, the
> presence of two potential implicit conversions makes some simple seeming
> conversions hard or impossible to write unambiguously.  If you want to
> go and overload the (existing) explicit conversions on unary "+"
> everything works just fine.  The cases that would be ambiguous with two
> implicit conversions around are disambiguated by the presence and
> location of the "+" operators.

I think I understand this problem of ambiguity. For example, in

  S : String := ...
  U_S : Unbounded_String := ...
  ...
  U_S := Translate(S, ,,,);

is going to be ambiguous if we have Translate both from String to String and
from Unbounded_String to Unbounded_String -- there appears the diagram:

               conversion
           S --------------> Temp_1
           |                  |
           |                  |
 Translate |                  | Translate
           |                  |
           v   conversion     v
       Temp_2 -------------> U_S

with two possible paths - via Temp_1:Unbounded_String or via Temp_2:String .
But what I want to stress is that this diagram is always commutative, that is,
all possible paths from the source to the destination will always lead to the
same result. The crucial point is that this may be rigorously proven, so we
can safely pick either path.

I understand that value of statements about rigorous proofs is generally
doubtful as it pertains to real programming, and in particular, to compilers.
But fortunately in Ada we have a professional team specializing in this area
- I mean SPARK people, and I hope that they may provide sufficient support for
this method of disambiguation, if needed.

> And as I said, I think adding implicit conversion of string literals to
> and from Unbounded_String would work.  But that isn't the case you want.

Actually this is exactly the minimum which I want, as I just explained above.

>  And of course, adding both that and implict conversions from String to
> Unbounded_String would be a disaster.

I'm ready to admit that in general case, which includes assignments and
expressions. In fact, requirement of explicit conversions in assignments and
expressions not only brings some inconvenience, but also acts as a kind of
warning which sometimes may be useful, so there is much less desire for implicit
conversions in those cases. Probably there is only one common case where those
implicit conversions (in expression) are definitely desired:

  S1 : String := ...
  S2 : String := ...
  U_S : Unbounded_String := ...
  ...
  Text_IO.Put(S1 & U_S & S2);


> The rules in ARM 4.6, Type Conversions and 8.6 The Context of Overload
> Resolution are pretty complex just to make the language SEEM simple to
> use. ;-)

I believe that (I can't say that I *understand* that, though -;) .



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