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

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

Alexandre E. Kopilovitch wrote:

> I'm not sure, though. Yes, Japanese is quite impressive in this regard,
> I have seen that in a raw reality (my daughter, being a linguist, had some
> correspondense by e-mail with several Japanese girls, and I was called for
> decoding and encoding those emails - well, it took some time and effort).
> But that is on the surface. When you go deep into real application problems,
> the situation may change: I know well that there are subtle and unpleasant
> problems with Russian encodings, and I know nothing about Japanese at that
> level.

Have you played the Minesweeper game that comes with Windows in expert 
mode?  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.

> 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.  You want to add implicit 
conversions between String and Unbounded_String, and presumably between 
Wide_String and Wide_Unbounded_String, and so on.

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.

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. 
  And of course, adding both that and implict conversions from String to 
Unbounded_String would be a disaster.

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


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