Re: Is this expected behavior or not

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 8 Apr 2013 09:48:07 +0200, Stefan.Lucks@uni-weimar.de wrote:

> On Sun, 7 Apr 2013, Dmitry A. Kazakov wrote:
> 
>>> If you have mounted different filesystems using different encodings on
>>> your system, how on earth should Ada.Text_IO even "know" which encoding to
>>> apply?
>>
>> How is this relevant to the issue that encoding must a part of the type?
> 
> Because even if the implementation of Ada.Text_IO.Open would know the 
> encoding of the filename, it could do nothing useful with it.

??? It must know the encoding in order to handle the file properly.

>>> Yes, this is C-esque of the worst kine. However, what would you expect
>>> when making system calls with operation systems written in C?
>>
>> I expect the type system to handle equivalent types of different
>> representations such as UTF-8 and UCS-4 strings. As it already does in the
>> case Universal_Integer vs. Integer. Both are distinct types, both have
>> different representations, both are considered equivalent in certain cases.
> 
> Universal_Integer is a pseudo-type.

With pseudo-values and pseudo-operations used by pseudo-programmers? (:-))

> You cannot define an object O: 
> Universal_Integer, neither a function returning Universal_Integer ...

As if it were relevant. But you are wrong here. Universal types leak into
run time through attributes. I.e. you do have objects of universal types at
run time in expressions like

   Integer'Pos (X) * 2
 
> The only thing that Universal_Integer handles well is a neat way of 
> defining constants.

That is the whole point. It is already here, because it is needed.

> The mess with the different string types in Ada is not 
> just about string constants, it goes much beyond.

That is the reason why it should be fixed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de