Re: Is this expected behavior or not

[Stefan.Lucks@uni-weimar.de]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4534 bytes --]

On Fri, 5 Apr 2013, Dmitry A. Kazakov wrote:

> On Fri, 5 Apr 2013 17:16:59 +0200, Stefan.Lucks@uni-weimar.de wrote:

>> I agree with you that there is no reason to distinguish between them. The
>> entire distinction narrow, Wide_ and Wide_Wide_ Strings (and Characters)
>> is a historical artifact, no more, no less.
>>
>> But if there is no reason to disting between them -- there is no reason to
>> mix them either!
>
> Sorry, but it cannot be both.

No, if you mix them, you must distinguish them. At least, when 
implementing your own multi-method, such as

   function Longest_Common_Substring(S1, S2: Universal_String)
                                    return Universal_String;
                                              -- maybe "is abstract";

Either Universal_String is abstract, then so would be this multi-method, 
and you would to override it n^3 times, when supporting n different string 
types. Or you can actually have objects of type Universal_String, but then 
using this method without making explicit conversions means a whole new 
bunch of implicit conversions.

One problem with implicit conversions is that Strings don't "know" their 
encoding (Is it UTF-8? Or ISO-Latin-1? Or ...?), so you don't even have 
the information you need to perform the conversion. Which is why you need 
to make explicit conversions.

And then it is not a big leap to say "convert everything into my favourite 
kind of string, then call my method, and then convert the result back".

> Consider Ada.Text_IO.Create. It has name a string and content. You tell 
> us that it is not necessary to be able to open an UTF-8 file which name 
> is UTF-16? Blame Microsoft.

I know a lot of things to blame Microsoft for, but in the Unix world, all 
files are essentially sequences of bytes that you read or write, and it is 
your problem to know the semantic of these sequences. So this is not much 
better than in the Microsoft world.

In any case, Ada.Text_IO.Create is a good example.

As much as I understand you, if Name is of type Universal_String'Class and 
you call Ada.Text_IO.Create(File, Name) you expect the proper thing to 
happen, right?

I agree that this would be cool. But it just cannot work!

Right now, if the encoding of Name is, say, ISO-Latin-1 and the encoding 
the underlying filesystem expects is UTF-8, you can have really surprising 
results when calling Ada.Text_IO.Create(File, Name). It would be cool to 
solve this issue with some Universal_String type.

But firstly, the strings we have don't know their encoding. The 
application programmer knows (hopefully), but it is not part of String.

Secondly, even if we had some kind of enhanced string type with object 
Name storing its own encoding, in addition to the string itself, the 
library wouldn't know which encoding it to convert Name into, or if 
any conversion is needed at all!

The point is, you can mount different filesystems with different naming 
and encoding conventions, even on the same machine. (With Linux for 
sure, I guess that also works in the Microsoft world.)

No Universal_ type will solve this issue -- you just cannot get rid of 
explicit conversions. At the end of the day, something such as opening or 
creating a file is some kind of a low-level operation, alas.

>> I think, I agree with Randy here. The old bunch of strings are a mess,
>
> There is nothing wrong with them except for being not in the same class.
> [Literals could be done better]

> Furthermore what Randy proposes will actually be worse than pitiful
> Unbounded_String. For them you could at least do this:
>
>   type Relative_File_Path is new Unbounded_String;
>   type Absolute_File_Path is new Unbounded_String;
>
> You could not do that for tagged strings.

OK, here we agree. Whatever the "new" strings are, the ability to define 
incompatible types with the same representation, that you cannot mix 
(without explicit conversion) is important for a language supporting 
safety-critical stuff! I sometimes have types Tainted_String and 
Save_String, being both derived from [Wide_[Wide_]]String, and I am happy 
when the compiler stops me from messing up between variables of this type. 
Does Randy's proposal really not allow that?


------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--