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

["Robert I. Eachus" <rieachus@comcast.net>]

Alexandre E. Kopilovitch wrote:

> 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.

No, the problem is not that the meanings of the characters are context 
dependent, although in several cases there are over a hundred Kanji that 
match a single Katakana or Hirigana syllable.  (Katakana and Hirigana 
are phonetic, and there are many more Kanji than phonetically different 
syllables.)  But that is not the problem.  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.

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


>>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?

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

In Ada a character type is any enumeration type where one or more of the 
enumeration values is a character literal.  A string type is a one 
dimensional array of characters. (The index type need not be Integer, or 
even an integer type.)
 >
 >   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. 
  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;

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?

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 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";

> 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.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig