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

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

Jeff C, wrote:
> "Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
> message
> news:slrnbnqekm.j6.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no...
> 
>>On 2003-10-02, amado.alves <amado.alves@netcabo.pt> wrote:
>>
>>>User-defined implicit conversion would solve this problem. Pragma
>>
> approach:
> 
>>>  function To_Unbounded (S : String) return Unbounded_String;
>>>  pragma Implicit_Conversion (To_Unbounded);
>>>  U : Unbounded_String := "bla bla bla";
>>
>>
>>NONONONONONONO
>>
>>Implicit conversion is the mother of all bugs. It is a nightmare in
>>FORTRAN 77 and you have to put a definistion turning it off.
>>
Jeff said:
> While I somewhat agree with your basic premise here, we already have
> implicit conversion in Ada for numeric literals.
> 
> e.g I can write
> 
> type My_Integer is range 0 .. 10;
> 
> a : my_integer := 10;
> 
> I dont have to write
> 
> A : my_integer := to_my_integer(10);
> 
> So I agree that fixing the string problems via an all powerful pragma might
> be a bad idea. 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.  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.  (Although we 
could have a facinating discussion of which mapping to use for the 
Japanese alphabet.)  As a trivial example, since I want something that 
all your terminals can reproduce:

type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M');

type Roman is array(Natural range <>) of Roman_Digit;

Year: constant Roman := "MMIII";

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.  Now look at that
declaration of Year above.  There is no IMPLICIT conversion from String 
to Roman, there is an implicit conversion from a string_literal to a 
string type.  If you said instead:

Bad_Year: constant Roman := "BAD"; -- Constraint_Error raised.

Now do you understand why you need for the conversions from String to 
Unbounded_String to be explicit?  There could be mappings involved, and 
you definitely don't want two implicit conversions, because the 
intermediate type could be just about anything.  This is also why, as I 
said, we were careful to limit the overloadings of "&" and assignment. 
If the (Latin1 based) types were too overloaded, then creating and using 
other character and string types would be extremely painful.

Note that most Ada programming, even in non-English speaking countries, 
is done by people who speak English.  But systems written in Ada support 
end-users who use lots of different languages.  Some Ada programs are 
even translators from one to another.  So support for non-ASCII (and 
even non-ISO 8859) languages was a major requirement for Ada 9X.

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