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

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

Robert I. Eachus wrote:

> In a single text you may see 
> the same word spelled in all three alphabets, or in a mixture of say 
> Hirigana and Kanji.  The alphabet chosen to write the word adds or 
> confirms contextual information.  The Hirigana alphabet was originally 
> designed for use by women, and is therefore often used to add a feminine 
> implication to a word.  The same goes for Katakana and foreign words or 
> things.  So you can spell "trousers" in three different alphabets to 
> mean men's pants, womens slacks, and blue jeans.

I consulted my home linguist once more, and this time a discussion became
slightly hot: although she confirmed genesis of Hiragana and Katakana, she
had a big trouble with understanding your final sentence in the paragraph.
After some discussion it appeared that she had two disagreements with your
thesis and example: first, she insisted that the thesis is far from generally
applicable, and actually may be true for borderline cases only; second, that
your particular example isn't good, at least for current state of Japanese:
if you want to write "trousers", you may write just that, not specializing a
particular kind (the word taken from French, naturally using Katakana), and
what is most important, all those words are different by themselves, without
regard to particular notation.

> And of course, using the "wrong" spelling in some contexts can be an 
> intentional nasty insult.  That is the Minesweeper problem.

Well, this is somehow true for perhaps every language. For example, there is
a classical "mine" for a foreigner trying to speak Russian: just shift the stress
in the word from the second syllable to first one, and you instantly convert
"to write" into "to urinate" (or, adding a short prefix, "to describe" into
"to urinate on [something]"); and note that a stress is almost never showed in
regular Russian written or printed texts.

> >
> >   U_S : Unbounded_String := "literal"; -- illegal (but I want it to be legal)
> >
> String literals are a universal type that can be implicitly converted to 
> any string type.  As I said it would be possible to make this case legal 
> by making Unbounded_String (and presumably similar types) string types. 

So the minimum, which I want, can be achieved (without much effort, if I
understand you properly).

>  But that would work against what you really want, since now, if you 
> also allow
>
>   Foo: String := "foo";
>   O_S : Unbounded_String := Foo; --implicit conversion
>   U_S : Unbounded_String := "literal"; -- Can't work now.
>                            ^ ambiguous could be:
>   function ""(L: string_literal) return Unbounded_String;
> or
>   function ""(L: string_literal) return String; followed by
>   function ""(L: String) return Unbounded_String;

Implicit conversions for literals is the most important case, both practically
and ideologically. So, if the choice is between "implicit conversions for
literals only" and "no implicit conversions at all, as it is now" then I
definitely choose first option.

> But as I said, if you overload unary "+" with the conversion from String 
> to Unbounded_String (and probably vice-versa), then everything works. 
> You write
>   U_S : Unbounded_String := +"literal";
> and it all works, you get one implicit conversion (to String) and one 
> explicit conversion (from String to Unbounded_String).
>
> How many years of those little plus signs do I need to match all the 
> verbiage we have exchanged on this subject?

These little plus signs constantly make a programmer remembering that String
and Unbounded_String are different types, which often is an inadequate view.
(And it is almost always inadequate view for literals.)

> Now if you want to recommend that in Ada 200X, package 
> Ada.Strings.Unbounded include:
>
>    function "+" (Source : in String) return Unbounded_String
>       renames To_Unbounded_String;
>    function "+" (Source : in Unbounded_String) return String
>       renames To_String;

I can tolerate the first of them, but I definitely dislike second one - "+"
here is certainly bad name (application programmers, unlike compiler writers,
will not associate this "+" with "additional conversion").

I recall that there was discussion in Ada-Comment on this issue (in think in
2002) and the name "@" was proposed (perhaps by Robert Dewar, but I may be
mistaken in that) for those conversions, or for some broader purpose, I don't
remember exactly. I think that if both above conversions will have the same
name then "@" is much better than "+" for them.

> I will certainly support that.  I don't really know why they were left 
> out of Ada.Strings.Unbounded while
>
>    function To_Unbounded_String (Length : in Natural)
>       return Unbounded_String;
>
>    function "*" (Left  : in Natural;
>                  Right : in String)
>       return Unbounded_String;
>
>    function "*" (Left  : in Natural;
>                  Right : in Unbounded_String)
>       return Unbounded_String;
>
> Although that does mean you can write our canonical example as:
>
>    U_S : Unbounded_String := 1 * "literal";

Yes, sometimes it is even slightly better than "+". Perhaps just because of
the presence of "1 *" that "+" was left out.

> > 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.
>
> Would be nice if it were true, but remember you can, if you feel like it 
>  overide one of the Translate functions with a different meaning.

Actually no, because one can override it for derived type only, but there is
no relation for derived type that can guarantee commutativity of the diagram.
In other words, a type derived by extension ("with" for tagged types) does not
inherit relations of this kind. Therefore, if you derive some type, say,
Decorated_Unbounded_String from Unbounded_String, there will be no implicit
conversion between String and Decorated_Unbounded_String, unless you re-establish
the appropriate relation between them, with all associated verification.



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